Rails in the Large: How Agility Allows Us to Build One Of the World's Biggest Rails Apps
Neal Ford shows what ThoughtWorks learned from scaling Rails development: infrastructure, testing, messaging, optimization, performance.
News
26 Hints for Successful Agile Development
Posted by Vikas Hazrati on Oct 27, 2009
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.
RelatedVendorContent
Learning to be a Good Product Owner: Foundation Skills
Lean development governance whitepaper by Scott Ambler and Per Kroll
Related Sponsor
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Why not premature optimization?
by
Ran Jun
Posted
Oct 28, 2009 3:40 AM
Re: Why not premature optimization?
by
Vikas Hazrati
Posted
Oct 28, 2009 6:21 AM
Re: Why not premature optimization?
by
Wouter Klouwen
Posted
Oct 28, 2009 10:25 AM
Re: Why not premature optimization?
by
totoro cat
Posted
Oct 30, 2009 6:25 PM
Re: Why not premature optimization?
by
Robert Berger
Posted
Nov 2, 2009 3:28 AM
Re: Why not premature optimization?
by
Dave LeBlanc
Posted
Nov 9, 2009 9:16 PM
Get case 1 fully working before starting case 2
by
John Harby
Posted
Oct 28, 2009 7:42 AM
Re: Get case 1 fully working before starting case 2
by
Assaf Stone
Posted
Nov 4, 2009 12:15 AM
-
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? -
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.
-
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.
-
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... -
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... -
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 -
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. -
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.
8 comments
Watch Thread Reply