– “There’s this feature X we should take on!”
– “Hmmm, we cannot deliver it now. We should refactor some parts of our app and deliver feature Y. Then it will be easy to add feature X and Z”
– “I guess we can wait. Feature Y is also interesting.”
I think the concept of incremental approach is somewhat missing here. There’re red warnings blinking when hear such conversation: features X, Y, Z may have different priorities among other features in the team’s backlog. Implementing them in one leap step means that we may not be working according to team’s priority queue.
To solve a problem the software engineer often has following alternatives:
- quick & dirty solution that causes maintenance headache and other problems down the road
- ultimate general solution that solves the particular problem… and a bunch or surrounding problems with varying level of priority
The first path is considered the easiest. The unethical and anti-craftsmanship way. The latter is much more respected in the engineering community. Nevertheless, it’s an easy path as well. The really challenging path, the one with the biggest potential value is the one that leads through the middle ground. It’s quite an engineering challenge to solve a particular problem without hacking, yet without embarking on solving too many problems at once. That’s the essence of incremental approach and that’s the software engineering skill of real importance.
Taking the incremental path does not mean that we want to avoid implementing the general solution. We still want the general solution, oh yeah. Yet, we want to get there step-by-step, maintaining the team’s capability to work according to priorities. I like to couple incremental approach with simple design. They both feed of each other. Simple design makes the code easy to change, refractor and accommodate new features incrementally. Simple design may mean some additional overhead down the road. Again, it’s an important engineering skill to keep this overhead minimal.
Finally, remember that context is king. There might be situations or working environments where going incremental may not be the best way to go. Nevertheless, if the team too often favor ultimate general solutions chance is they are not as effective as they could be.
Here’s my message for today: Architect your solutions so that it is possible to work according to priorities. Don’t let the the general solution get out of your sight. Reach it incrementally.
monkey island 
I’ve missed your entries :) Always to the point.
By the way: http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
Well put. I always find me in a battle where the other says that “you should not hack and we might as well get all this fixed first since we will do it anyway”. Like they knew…
Hi!
Re-twit you post: to my @vokvfqjt twitter
it is a excellent weblog and i like it very much!
Tom,I’m trying to do snemthiog similar but it’s adding 5 columns x 1 row (the opposite of the above).I have data for 5 days of the week and I want to sum it each week in a separate column.It really is basically the same thing as above but spred out for 52 weeks adding every 5 columns.I hope you can help. I am having a mind cramp on this one.TIA
My wife and I moved out west and began attending a neighborhood church. At a small group meeting last December, I asked our mid-30’s – early 40’s friends, “What kind of outreach do you do for Christmas?”One of the people, who is a leadership position, replied, “What do you mean by ‘outreach’?”This baffled my wife and I. We had just moved from a heavily missions-minded church.This incident became an indicator that this church was internally focused — building campaign, Christian education, etc.I am praying to see some improvement here. God has allowed me to have growing relationships with other church leaders, so the groundwork for influence is being laid.
Heartburn Foods – Uncover What’s Right And These To Avoid Like The Plague