Many of our customers are founders trying to make the best of a limited budget.
Others are businesses in established industries relying on our expertise to
improve their processes and implement complex business rules. We are able to
meet the needs of both by following
sound software development processes,
mostly around the principles of agile software development. One of the purposes
of this blog is to demystify some of the working practices that have almost become
buzzwords and explain why and how we do them. Some blog posts will be kept at a high
level and employ imprecise language, like this one, while others will describe some of
the interesting and highly technical issues we come across.
So, to start off, let's talk about one of the most powerful tools that's available to a software development team: test-driven development.
The core of test-driven development is a suite of automated tests. Why bother writing them at all?
If the change to the production code has been made before writing the test,
the developer can't be sure whether the test is passing because the production
code is correct or due to a defect in the test. Therefore it is critical that
the test is written first. Taking this further, if every change is driven by a
failing test, test coverage will naturally be high and the development team will
gain trust in the test suite and be able to deploy changes to customers quickly.
It also forces the developer to think about the actual business requirement. Writing a failing test requires absolute understanding of what needs to be done. This encourages the development team to clarify the requirements with the business to be sure that what we are developing is what they wanted. Failing tests focus developers’ attention and give a clear indication when a feature is done. From a business perspective, test-driven development enables changes to be made effectively and with confidence, being able to react to market changes, customer feedback, competition and regulatory changes quickly.
Having said all of the above, we do keep in mind that TDD is just a tool
and should be used when appropriate. There are instances when it's not a
good use of budget, for example when creating throwaway prototypes or
exploring and learning how to use unfamiliar tools.
From the perspective of our customers, it's a question of whether they'd like a product that's maintainable and robust, expecting it to have a long lifetime, or a prototype that they can show to investors in order to decide whether to pursue the idea further.