Code Craft

Agile Software Development

Definition of Ready (User Story Definition of Readiness)

Definition of Ready

  • The story has a clear order in the backlog
  • Acceptance criteria for each user story
  • The story is clear to all l developers &  testers
  • The story has clear business value
  • The story is testable within the sprint
  •  The story is feasible & copmletable in one sprint
  • The story is written in classic format: As a <some class of user> I want <some enhancement or feature> So that I derive <some form of value>.
  • New features are assessed for architectural impact & documents are evolved
  • The story has been estimated or is estimable by the team
  • A description of the demo for the story is written
  • The story has been sliced to provide value and be small in size
  • The story is as small as possible
  • The story can be done in 3 days or less
  • The story is deployable when done
  • Environmental impacts have been assessed

Links:

ALE 2011

Links:

The first day. I came at 8:00 am. There is a small preparation bustle. I got a participant’s package (a big bag with a few things). Unfortunately I have not found a notebook for notes :) After observation of conference rooms and taking some pictures I put pins on the map, got a badgeand made a final decision about topics.

There were 3 track of speakers. The first step is to understand what kind of topics I’m interested in. So…. some planning insights will be good and high-level project behavior models with practical examples. I noticed that I need to look presentation or agenda before… It was difficult to select. As I was said latter the tracks were recorded. It’s good.

ALE is an UN-conference. And it’s true. This is an open space to share knowledge and experience. How is it possible:

  • Any activities are focused on building relations: open sessions, time breaks with food, evening with stranger, light talks.
  • 30 mins presentation about topics are not presentation. It’s an invitation for open space about extremely important challenges and breakthroughs.
  • Approximately 25 open session per day it’s huge and focused sharing experience exercise.

My program for the first day:

  • Offshore outsourcing with Scrum – we have distributed teams. Experience from our colleagues will be extremely valuable.
  • Estimation waste - interesting topic. I went to this topic to prove my understanding that we must spend as less as possible time for supporting tasks (management, estimation, planning and etc). And our focus should be on something that produce value. Result: 100% matches with my expectations. Just do it.
  • A mental model for agile adaptation – the most difficult thing is our habits. Using agile is a challenge for the people because we need to change our behavior and get out from our comfort zone. This topic was selected to learn the last ideas from agile leading company “ThoughtWorks” (my one of the favorite authors and author of Agile Manifesto works there).

The next section is a list of buzzwords and ideas from different speakers:

  • Buzzword midnset: work together (DEV+QA+PO), empowering by delegating make decision and responsibility awareness.
  • Agile templates (ex: user storiy) are tools to support conversation. I recall CCC model here
  • Agile discipline is to support continuously delivery to support business goals. Simple quote , but another way to think about development.
  • Responsibility model – http://christopheravery.com – how to coach the team to take responsibility. It’s more detailed model and step-by-step guide to make my favorite mindset “It’s MY project”
  • Estimation is waste. Angel Medinilla reached all my expectation in his contract. Yehoo! I’m not alone here.
  • Offshore strategy is based on assumptions and expectations. Our goals in high diversity world is to be focused to build these components.

Open session notes:

  • The amazing practice for engineering improvement was found : coderetreat
  • Legacy visualization. I noticed that it’s not so popular topic here. Maybe because it requires more knowledge that only management buzz-words. Visualization metrics: complexity and another staff. Interesting idea to visualize bugs areas in dynamics… or class/method changes in dynamics.
  • KPI discussion: KPI is bad and waste. Team KPI <> Management KPI. Several people with extremely wide experience could not find here any value for agile teams :) My suggestion was to give team to define KPI and challenge them how they could improve it the next sprint. But the main question is to use KPI to improve performance and consider it as mindset for reflection.

I was so excited with talks and topics that decide to contribute as much as possible. So I decide to reanimate my twitter, blog and linked activities to learn and share experience.

Also I had a chance to give a light talk. Here is my corrected light talk speech:

“… (15 sec ond silence… Stop…. Thinking…. Feeling…. Think about your feeling…. Take a snapshot of your feeling and reflect…. Think about your project budget…. Our budget is money and hours…. We consider it as resource…. Hours, money, story points… Is it our resource that make a difference? What about another resources? How many trust points in your team? What about empathy points? Integrity points? Feeling points and what kind of feeling you have in your team? Amazing products are created by passion and engagement…. Try to consider it in your budget! What will your budget be? Could you meet your deadline with such budget?”

Useful resources

Books

See full my wish list / my linkedIn book list :)

The last thing that I noticed during open space sessions . I considered my ideas as extremely exciting ideas in the world. But not so many people react on it. I thought a little about it and noticed that the same problem with ideas others! I did a little thinking. Maybe open space should be more moderatable or have some agenda, or it should be focus brainstorming. I have not seen 100% involvement: 99%, 95%, 40%… But not 100%. If we are here. We must take 100% of the event.

My follow up:

  • To read agenda of topics in details and try to find presentation up-front
  • My open space must be a brainstorming game to make 100% involvement
  • I should ask people for their favorite books.
  • I should find follow-up in each speech and open space session
  • Post clever messages into twitter and avoid spam
  • Reanimate blog, twitter and podcasts. Rethink outcome from Study Group community: we have exciting discussion about legacy code, agile practices, patterns and other staff. We must be more available for the people.
  • I need to buy Mac. Joke :) A small netbook will be enough.
  • I need to prepare speech for the next ALE: EQ budget, Scrum optimization or any hot topic about team dynamics or engineering excellence.
  • I need to drill down coreretreat and support this amazing community in our city (Copenhagen). Hope our company (ScanJour) will support me with it :)
  • I need to drill down such resources mentioned before resources
  • I need to improve my englisth, learn danish and german :)

The first day was finished. From 8am to 8pm. Hm…. 12 hours… Overtime :)

Refactoring is not for agile team

After introducing Development DoD I got a suggestion about switching refactoring into a code quality statement.

Refactoring should not be a requirement, as that promotes a sense of immutability contrary to agility. The sentiment is better expressed as a focus on code quality. Supported by a list of “code smells” to avoid.

Code quality is a result of refactoring. So I prefer to stay original intention. I believe that refactoring (cleaning code of changes) is a most critical part of agile development discipline. If we want to exclude this we should not apply “agile” word to our process. We could say we have “flexible” process or “adaptive” process, but not “agile”. Based on picture there are three approaches came to my mind:
  • Agile approach (Standard agile development cycle): TEST ->CODING -> REFACTORING
  • Agile imitatoin (we have no tests usually, so we have only): CODING-> REFACTORING
  • Code and Fix (we get rid of refactoring):  CODING
But maybe we have some different understanding of refactoring. Refactoring is cleaning process before/after changes to produce code with the best code quality.
Avoiding refactoring phase before/after changes we introduce technical debts and creating opportunities for bugs.
My definition of refactoring based on these classical resources about this requirement of development standards:
Refactoring is a tool before making changes (or after changes) to make code maintainable and easy to read/fix. It’s as a code-washing mechanism. Of cause somebody insists that we should avoid it. Let’s postpone it, let’s do hack and maybe somebody will make it more better some later. We must add more and more code, because client asks for it! But why? Imagine you were a doctor and you had a patient who demanded that you have to stop all the silly hand-washing in preparation for surgery because it was taking too much time.  Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient. So too it is unprofessional for programmers to bend to the will of somebody who don’t understand the risks of making messes.
So. What do you think? Could we say that refactoring is a mandatory rule for an agile team?Kirill Selyak refered to original definition:

“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior…”
Martin Fowler

My comment: restructuring = process.

And it’s absolutly practical obesrvation. But I have theory about it based on cognetive psycology, brain process. If somebody wants to lissten boring lecture about our cognetive brain processes please ping me :)

Restructuing is a process. And this process contains such steps:

  • Step 0. Trigger (to start refactoring process): coding is done (we changed something according our functional oriented intention).
  • Step 1. Identify anti-patterns (smell) in my task/recent changes/or potential chnges
  • Step 2. Apply refactoring techniques (based on http://refactoring.com catalog)
  • Step 3. Prove that changes are safe (external behavior was not changed. How to vereify it’s another question).

Result stated: CODE WAS REFACTORED. There is no code quality discussion, review or design decision. Only small steps based on refactoring catalog.

This process is part of TDD cycle (see above).  And this process is part of another process. Development task = Set of test / Set of increments

  • Step 1. Implement task 1.
  • Step 2. Implement task 2.
  • Step 3. Implement task 3.
  • Step 4. Implement ….
And this process is part of another process
User Story = Define requirement + Define test cases + Development + Documentation + …
Conclusion, “code quality” is more abstract level and we don’t know scope of it, so “refactoring” step is well-defined and very measurable.

Development Definition of Done (DDoD) and Code Complete

Today we had an amazing discussion about DEFINITION OF DONE for development tasks. I would like to introduce our draft agreement. We have User Story DoD and decided to specify DoD for development level.

Development DoD: Code Complete

  1. A development task was coded
  2. The code was executed by the developer
  3. Unit tests are written and passed
  4. Code is refactored
  5. Reviewed (or produced with pair programming)
  6. Checked-in (passed a gate)
  7. Developer integration tests are passed

Code complete poster: download

 

Anti-pattern (smell): avoid using var | var or not var arguments

There are a lot of discussion around it. I would like to use var everywhere because I have strong arguments that it makes code more readable. But before sharing my experience and conclusion let’s take a look some notes:

“Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.” C# Reference, MSDN

Vladimir Kelman said

“C# documentation generally uses var only when it is required”This is a bit obsolete approach intended for people who are completely new and unaware of ideas of functional programming, type inference, etc. After reading some books on F#, Scala, etc. (one of my favorites ishttp://www.functional-programming.net/) it becomes clear when to use and when not to use var. With constructors and type casting operators it doesn’t make sense to use explicit types – just makes code less readable. Var also makes sense to use in all cases when type is clear from a context, when type is automatically generated and/or very complicated.

Good starting point was given by Ilya’sUsing var keyword can significantly improve your code, not just save you some typing. However, it may require discipline to apply good practices when using implicitly typed variables. Here is my list:

  • It removes code noise.
  • There are a lot of cases, when implicitly typed local will reduce amount of text developer needs to read, or rather skip. Declaring local variable from new object expression or cast expression requires specifying type twice, if we don’t use “var”. With generics it can lead to a lot of otherwise redundant code. Another example would be iteration variable in foreach over Dictionary<TKey,TValue>.

  • It is required to express variables of anonymous type
  • . This is pretty obvious – you cannot declare local variable of anonymous type without using var.

  • It induces better naming for local variables
  • . When you read local variable declaration with explicit type, you have more information at that moment and something like “IUnitTestElement current” makes sense. However, when this local variable is used later, you read “current” which takes some time to figure out the meaning. Using “var currentElement” makes it easier to read at any place.

  • It induces better API.
  • When you let compiler deduce type from method return type or property type, you have to have good types in the first place. When you don’t have explicit type in the initialization expression, you have to have best names for members.

  • It induces variable initialization.
  • It is generally a good practice to initialize variable in the declaration, and compiler needs initializer to infer type for local variable declared with “var” keyword.

  • It doesn’t require using directive
    . With var, you don’t have explicit reference to type, as compiler infers type for you, so you don’t need to import namespace when you need a temporary variable.
      To summarize the list above, by actively using

var keyword and refactoring your code as needed you improve the way your code speaks for itself.

Pretty nice thoughts, but I have another experience and another arguments.

I believe evertime I tried to specify type I have a smell in my code. Extra argument from me: we are talking about “easy to read”. Why do we discuss it only for declaration line?

var cat = shop.GetAnimal();
Do I care in this line about type? NO. Because I have absolutely a beauty variable name. But it’s not good example! Good example is to show that we don’t care about type at all and focus on our habit to see type on left side… Let’s see how we using this variable:

var cat = shop.GetAnimal();

cat.Meow();

Do I really believe that during reading cat.Meow() I care about type? Why do I need type during the reading? ”Readiness” is defined not by initialization of the variable, it’s defined by using variable. If you eager about using concrete type you MUST write like this:

Cat cat = shop.GetAnimal(); (1)

(Cat)cat.Meow(); (2)

(2) Be honest! If you need a type for understanding use it everywhere. Here (2) is a type as you like :o ) Please be honest, it’s not logical to use type in (1) and avoid in (2). My conclusion, we want to see code without var due to our habits, rather than to make code readable.

And the last bullet point. Try to ask your-self are you business developer or technical programmer?  For me it’s important to read business logic of the function and focus on business domain/behaviour rather than get stuck with technical implementation forced by concrete programm language.
As for me implementation of internal DSL using concrete language should follow such rules
  • simplify as much as possible (var is an example of simplification communication interface for a reader)
  • close to domain – avoid thinking about technical details and focus on business domain and behaviour; and object communication, rather than types and interfaces

Another point is. Let’s think about argument for avoiding using var. “I want to know type”. Please pronounce several types and think about it. Doesn’t it remaind well-known reincarnation Hungarian notation? Of coursee we don’t hide type inside variable, but we hide type inside declaration. Why as a reader do I need type in declaration? What are the problems to understand further code? Why should I as a reader care about type in this line of code: cat.Meow()? It means I need type only in one place in declaration. And I don’t use type and knowledge about object type further. Let’s get read of dead code.

My conclusion. Using concrete type is anti-pattern as comments, long methond, god class, high coupling and etc. And if you don’t understand nature of the object and want to comment it by using type you must apply refactorings.

If you disagree, please don’t explain why and make assumption that I know a lot of traditional arguments about the topic. I don’t like discuss theoretical assumptions and personal habits. Give me your real case where we could not avoid using concrete type. But be aware I will challange your code with refactorings technics before a deep discussion :) I prefer to learn by real examples and real cases.

Welcome!

Hi!

My name is Denis. I work Agile team and owner of this site! I created this blog to share insights about agile, scrum, xp, design patterns, refactoring, tdd and all intresting staff.

Some details about me you could find in linked.

Areas of my interests are:

  • team performance and motivation
  • cross-group and team collaborations
  • improving visibility and transparency of the software development process
  • product and code quality issues
  • challenge myself and others :)

I proud to work in my current team. I hope I will be allowed to share my experience in ScanJour and insights as Team Lead, Agile Coach and .Net Developer!