26 Hints for Successful Agile Development

Posted by Vikas Hazrati on Oct 27, 2009

Sections

Process & Practices

Topics

Agile ,

Agile Techniques

Tags

Best Practices

Keith Swenson, recently compiled a list of 26 hints for Agile software development. Keith suggested that he frequently collects nuggets of wisdom on various topics and the list is a distilled set of hints which really matter for Agile software development.

A comment on his post suggested that most of these hints may not be Agile specific and would be true for better software development and design. Keith responded that, for seasoned Agile practitioners many of these hints might sound routine but there is a larger audience out there who are agnostic to these practices. He added,

I am working with some teams in Japan that use a very strict waterfall model for development. To that team, about half of these are “surprising” and possibly even radical pieces of advice. Things like “write the test before the code” and “never implement before needed” are radical concepts to them. They pride themselves on “completeness” of implementation, to the point of inventing use cases which are not customer driven. The result is overbuilt code, another kind of waste. They wait 6 months sometimes to implement the tests. To those implementing in strict waterfall, the test is a “crutch” that should not be needed by developers doing their job correct. Surprising?

Some of the 'not so common', interesting hints suggested by Keith were,

• Get case 1 fully working before starting case 2. One of the big problems of software development is to start multiple things in parallel, which would inevitably lead to some work which needs to be discarded and hence wasted. The kitchen metaphor is : “Serve the current meal before starting to cook the next“.
• Don’t be afraid to make a decision; don’t be afraid to change an earlier decision. Delay the decision as much as possible and make it when necessary. As soon as new information arrives, don't be afraid to change an earlier decision.
• Measure, measure, measure. Agile development is help address the problem of uncertainty about the future, but there should be no uncertainty about the past.
• Design around people, not systems. Too often developers get sidetracked into designing for technical opportunities. Ultimate success of a software depends upon getting the people to collaborate effectively and add business value.
• Premature optimization is the root of all evil. Intuition of what is important for overall performance is almost always wrong when based only on a static understanding of the code. Instead, measure the behavior of the complete system and then identify the performance issues.
• Never overgeneralize functionality. This is also know as “YAGNI – You Aren’t Going to Need It” .
• Never ever measure code by counting lines. The number of lines needed to do a particular task varies greatly from programmer to programmer, and from style to style. Count the functional use cases
• Software is Plastic. Unlike physical manufacturing, software can be changed in significant ways very easily.
• Don’t invent new languages. The advent of XML is driving an unending chain of specialized custom “scripting languages” which are supposedly making the software development generic. The flaw in this reasoning is that the precise definition of the behavior of the operations almost never well defined outside of the context of a particular implementation

Read more through the complete list of hints and leave a note if you feel that an important one is missing.

1. Back to top

   Why not premature optimization?

   by Jun Ran

   I'm not very sure about "Premature optimization is the root of all evil.", can somebody explain this?
   
   Is this something similar with Lean principle - Systemic Optimization?

   Reply

2. Back to top

   Re: Why not premature optimization?

   by Vikas Hazrati

   I guess a lot of time is spent in trying to optimize code etc which actually might not be an issue when the system is functioning. This is seen a lot when endless time is spent on optimizing the method and once into production you realise that main cost of the functionality is spent in interfacing with external systems like databases, web services, legacy systems etc etc and excessive code optmization upfront may not be of any help.

   Reply

3. Back to top

   Get case 1 fully working before starting case 2

   by John Harby

   I'm not sure this always applies although in most cases is probably good advice. One counterexample I think applies is where the project functionality crosses tiers. For example, suppose my project requires some number of stored procedures or SQL database coding in conjunction with a .Net web app. It might make sense to go ahead and work on the database code along with the app in conjunction.

   Reply

4. Back to top

   Re: Why not premature optimization?

   by Wouter Klouwen

   This is actually advice from Donald Knuth originating on the Art of Computer Programming. It means that you need to complete your program before you optimise it. Humans are very bad at guessing where a computer spends most of the time, so if you prematurely optimise, you will just waste time.
   
   See en.wikipedia.org/wiki/Program_optimization#When...

   Reply

5. Back to top

   Re: Why not premature optimization?

   by totoro cat

   The key is the word "premature". It implies that you've started to 'optimize' before having a concrete requirement to optimize towards. Optimization should always move you closer to some required goal.
   
   The "root of all evil" part is in regards to the lack of awareness of the project's true requirements. What happens when you are lose awareness/consciousness of the project's true requirements? You spend all your time shaving yaks [1] instead of doing something truly useful (to your customers).
   
   ~~~
   [1] The Productive Programmer, Chapter 4. Automation > Don't Shave Yaks, Pg. 67:
   my.safaribooksonline.com/9780596519780/I_sect13...

   Reply

6. Back to top

   Re: Why not premature optimization?

   by Robert Berger

   As others already said it's about optimizing before you actually know what needs to be optimized and Don Knuth (www-cs-faculty.stanford.edu/~knuth/) said it.
   
   You should always gather some data by utilizing profiling, tracing, code overage tools and the like to find the hot spots in your code which need to be optimized and after optimizing it measure again to see what changed.
   
   Unfortunately many developers just "think they feel" the right place to optimize and spend too much time optimizing the wrong thing.
   
   Regards,
   
   Robert
   
   --
   Robert Berger
   Embedded Software Specialist
   
   Reliable Embedded Systems
   Consulting Training Engineering
   Tel.: (+30) 697 593 3428
   Fax.:(+30) 210 684 7881
   URL: www.reliableembeddedsystems.com

   Reply

7. Back to top

   Re: Get case 1 fully working before starting case 2

   by Assaf Stone

   Getting case #1 working before starting case #2 doesn't mean that you're supposed to finish working on one component of the system before the other. It means getting a business case done, before moving on to the next.
   
   In fact, in the example you stated, it is a good idea to build the .NET app and the database in step, in order to fulfill the 1st business case before moving on to writing the .NET code, and the stored procedure required for the next case.

   Reply

8. Back to top

   Re: Why not premature optimization?

   by Dave LeBlanc

   I think it's not just that you're optimizing the wrong spot, that's wasteful - but I think it points at a bigger problem.
   
   When you optimize a program, you almost always limit it's flexibility, and make major tradeoffs in readability and generality.
   
   When you do those things prematurely, you're making your code far less adaptable (read: more expensive) to change. And having things be easy to change is what agile is all about. That's one of the reasons we tend to write so many tests - make things resilient to change.

   Reply

• Older >