Why software project management is like painting a Rembrandt (or, knowing when done is done)

August 4, 2010

Rembrandt Harmenszoon van Rijn (July 15, 1606 – October 4, 1669) was a Dutch painter.   When you see his paintings you can’t help but be amazed by their detail and lifelike nature.  The problem with paintings, especially the ones that are based on classical realism, is that there’s always one more stroke of the brush you can add. The painter is never finished. So too with software. There’s always one more test case to try, one more error scenario to trap, and one more use case to cover.   That’s why, left to their own devices, software projects never end.

Does everyone have a clear understanding, and does everyone have the same understanding of “done”? Ask around in your team  – I absolutely guarantee that in most organizations people do not!  

RED FLAG WARNING: Software developers love to say things are “basically done”.  The problem with “basically done” is that it usually translates to 90% ‘functionally’ done, but the last 10% of the work could take more than 50% of the time. As they say, the devil is in the details and the details are always in the final 10%.

Because there’s no such things as exhaustive development (and in particular, testing with full branch and code path coverage) one of the most important steps a software project manager can take in driving a high-efficiency team is to make sure that everyone in the organization understands the definition of “done” for the pieces they are working on. When is the code done? When is testing done?  It’s not as easy as it sounds, but it’s an effort well worthwhile. 

More on secrets of software project management in Chapter 15 of Making it Big in Software: Get the job. Work the org. Become great.

Previous post:

Next post: