Should 'start-ups' give a rats-arse about quality

In start ups, getting your idea out there and used by your customers as quickly as possible is sometimes THE most important thing. However, at some point, your product, hopefully, becomes successful and ignoring code quality can come back to bite you.
I speak about this topic purely as an observer, not having been in the coding game for a long time now (apart from a bit of haggling with wordpress php but I’m told that doesn’t count ;) ). These are some of my observations from being a mediator between the ‘do it fast’, &  ‘do it right’ crowds.
I’ve lost count of the number of times I’ve heard someone say “Don’t worry, this is throwaway code, we’ll do it right next time”. That code is still out there, sometimes doing very well but giving engineers headaches every time they work in it.
The balancing act then is between the rush to market and the maintainability of your product years down the line. I’ve seen the impact of rushed code on productivity in a number of places I’ve worked. Obvious warning signs such as ‘comment tags’ that read: //Come back and clean this up later// littered through 10 year old stacks.
To many people, code quality is more than just < x number of bugs in the application. However, catching bugs is just part of the equation, in agile we measure quality a number of ways , These are the 3 I hear talked about a lot.
Well tested code: This doesn’t mean throwing over the wall to a team of QA’s once every X months. Rather, following some coding patterns like TDD (Test Driven Development), Unit Testing, Functional tests. A lot of start ups will drop these as they feel they add to development time of features. Whilst true, you have to understand the pay off you are making.
Some time down the track, when your product booms, you’re going to want to add more features. Code with good test coverage means your engineers have more confidence to make change.
Bug free: This is the most obvious one. We’d all like to have a bug free application, but, how free becomes a subjective decision. More important is to know where the bugs are and contain them if they aren’t possible to fix. The big trade off here is between getting your feature out versus impacting customer happiness.
Readability: This is one the agile guys talk about a lot. Making sure your various bits of code are going to be readable in 1 or even 5 years time. The next person to walk through the code will not have the context that the team had when it was first written.
We have learnt to accept over years of experience that we’re going to want to make changes to our code. Refactoring, changing your code to add features, is a standard practice in agile and well structured code, with meaningful naming conventions will make change far cheaper.
I’d love to hear other peoples experiences, advice etc on this topic. I’m still on the fence between the ‘do it right’ vs ‘do it fast’ debate. Fire away

Comments

Popular posts from this blog

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Using an agile storyboard as a scale of certainty

An idea for a release Retro