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

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.


One response to “Why software project management is like painting a Rebrandt (or, knowing when done is done)

  1. To the topic of this post, my father was an excellent painter and would always say that it took both him and my mother to complete a painting – he would paint and she would tell him when to stop. In software development, that external view is also important; it’s key to have an formal internal user acceptance group – usually product management – to be the front-line customer and determine “deliverable” (the ultimate measure of doneness). Product management always want to get it out to the customer so they tend to be picky but not to the point where nothing is ever finished – and they have more of the customer’s perspective than engineering. If you are an Agile team, getting the product team in the SCRUM reviews to check that their user stories are being delivered on, and providing a customer-centric take on the results of each sprint is key to getting to a deliverable product – and that’s way more important than searching for just one more theoretical way to break the software. In the world of SaaS development, the right approach is not to obsess over perfection, but to focus on avoiding show-stoppers and getting to code that can go live; if some obscure corner case slips through, simply fix it on the next sprint. This way you get velocity in development and actually deliver the product to the customer.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s