There is some logic behind using ‘quick and dirty’ development methodology in early stage startups. You have to be ‘quick’ to beat or stay ahead of competition. That part is a given. But do you have to live with ‘dirty’?

Acceptance of the ‘dirty’ part is often driven by the following logic.
- we dont know whether the market will really use this feature or module
- money saved on software development can be better used else where
- we’ll fix the dirty part when we get next round of funding

It’s obvious that the logic works for companies who dont get the next round of funding.

But often companies who get the next round dont get time to fix the ‘dirty’ part and it comes back to haunt them at some time in the future.

So it may be a good idea to figure out a way to develop software ‘Quick and Clean’. I know that it can be done because I have done it a few times. Here are my suggestions on how to do it:
- be determined and commit to ‘Quick and Clean’ methodology
- as a leader in product or engineering, set an example by doing things quck and clean yourself - often it takes just a little more time to do a clean job versus a dirty job
- engineers will buy into this - they dont actually like to develop ‘dirty’ software but compromise to please their bosses

Makes sense?

 
 Email This Post
Sphere: Related Content

Tags: Technology //