“Dirt Mode” Software Development for SaaS / internet startups

Dirt Mode

Here is my 6 point definition of  “Dirt Mode” software development which suits developing new SAAS based  products. This is a practical software development style  and in some way supports the lean software development principles.

Dirt Mode
(thanks to http://www.dirtrider.com for the image)
  1. Use a pluggable and adaptive design (adaptable to alternatives in technology). Dont integrate with any one particular technology too deeply.
  2. Don’t try to create a “sophisticated”  design / architecture.  Keep it simple and lean. Assume that you are going to throw it away the next quarter.
  3. Build no automation tests and write bare minimum UTs just for your own confidence on the code. You know that you may end up throwing the technology you are using, and adopt a completely new one.  Take a look at one of my earlier posts to see why it makes sense.
  4. Use Test Driven Development like technique – don’t write automated tests, but create a detailed test plan before writing code.  Spend time review these test plans more than the code. This would ensure that the code delivered in the first go is high quality with few surprises.   You would save a lot of time in code reviews.
  5. Be crazy about measuring software quality and success after launch.  You know that there would be surprises. If you get to see issues in the way it works today, be more than ready to throw away  / re-factor any of your components and do a quick re-write (instead of trying to hammer the same thing too much).  If you miss this one, it would be too late for you to do a re-write / throw away when your customers start telling you how buggy your product is.  So you should know how you plan to check if you software is working as it is expected to in the live environment before it becomes a big issue for your customers and your business.
  6. Be very careful about what technology you choose for your product. Relying on the latest may seem cool and fashionable but in my experience its a very risky thing to do un-less 1) you are developing this product just for the fun of it and you mean to make no serious impact OR 2) You are doing it for experimentation mostly for RnD. Try to use more mature technologies which have plenty of adoption and support.

Once you get a feeling that the design and technology choices you had  made are reasonably right which would happen after a few iterations depending on your initial attempt(s) , you can then start putting in the the heavy-weight stuff like automated tests, extensive UTs, hardening the design by integrating with the technology capabilities more deeply.

Also, the point #6 only makes sense when you have a variety of choices. If you are building something that depends on the latest technology that was released yesterday,  you have no choice.  Take the plunge !

These are my thoughts, I would love to hear yours. Please share your opinions in the comments section.

3 thoughts on ““Dirt Mode” Software Development for SaaS / internet startups

  1. I’d disagree with #3, especially if you are doing SaaS: you want to make sure that your public interfaces/endpoints/APIs are absolutely rock solid, and there is nothing better than automated testing to guarantee that. If you don’t have tests, you may break something without knowing it. Test IS code, don’t think of it as being separate activities. Some code will be thrown away, and its test will as well. It’s not waste, it’s part of the process.

    With regards to #4: from my experience, test plans have been fairly useless. Usually you don’t know what you are building until it’s built, and you want to have the freedom to adapt to what you find as you are building. Writing software is closer to finding a new drug than building a house: you don’t know what you are creating until you have created it! Your test plan will be obsolete as soon as you’re done writing it. Write automated tests that evolve along with the code.

    Everything else makes sense to me. Thanks for sharing your thoughts 🙂

    1. First of all, thanks for your comments Yan!
      Agree with you partially on #3; I certainly see value in protecting the public interfaces with automated tests. And thats what you would use in your monitoring system after launch as well ! But what I really meant by not spending time on automation is a comprehensive suite / system. There are many scenarios, especially in startups, where there is no real automated tests ‘system’ or developer tools per se. And given that, maintaining the tests is relatively high overhead.

      With regards to #4, when you say “Writing software is closer to finding a new drug than building a house” I guess you are referring to the product discovery process. That is usually a much bigger cycle than delivering one iteration within that end to end process of discovery that drug. Writing test plan for something you are about to discover does not make sense, but it adds a huge amount of value for that single iteration that you are going to write code for and deploy on a QA stack. When a project technical lead / Product Manager sits with a developer to explain what needs to be delivered in the next 3 days, test plans help like anything. You spend few hours detailing what is expected (at a granular level), review and agree on something. The developers keeps that plan on his table while coding and at the end of 3 days what you get is fairly close to what you wanted. Code reviews then become really smooth and quick.


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