Develop incrementally!

– “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.