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.
Community comments
Why not premature optimization?
by Jun Ran,
Re: Why not premature optimization?
by Vikas Hazrati,
Re: Why not premature optimization?
by Wouter Klouwen,
Re: Why not premature optimization?
by totoro cat,
Re: Why not premature optimization?
by Robert Berger,
Re: Why not premature optimization?
by Dave LeBlanc,
Re: Get case 1 fully working before starting case 2
by Assaf Stone,
Why not premature optimization?
by Jun Ran,
Your message is awaiting moderation. Thank you for participating in the discussion.
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?
Re: Why not premature optimization?
by Vikas Hazrati,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Why not premature optimization?
by Wouter Klouwen,
Your message is awaiting moderation. Thank you for participating in the discussion.
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...
Re: Why not premature optimization?
by totoro cat,
Your message is awaiting moderation. Thank you for participating in the discussion.
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...
Re: Why not premature optimization?
by Robert Berger,
Your message is awaiting moderation. Thank you for participating in the discussion.
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
Re: Get case 1 fully working before starting case 2
by Assaf Stone,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Why not premature optimization?
by Dave LeBlanc,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.