Image License: Public Domain
We went through the same discussions with continuous integration, or test driven
development. Now sure, not all software teams may be “test driven”, in the sense
they write tests before they write code, but most software teams consider using
some form of continuous testing a good practice and have adopted it. Even for
new projects, if they do not have decent automated tests, adding it soon is on
most team’s roadmap.
Tests too slow things down. Oftentimes a good test suite is almost as many lines
of code as the feature itself, often more. Every time someone has to refactor
code, they have to refactor or adjust tests as well. Every time the behaviour
of a piece of code changes, the tests have to be updated as well.
It may feel like tests are slowing things down. But the reason teams continue
with tests, increase test coverage etc despite all this is because the
confidence you get that everything is still working after you have made some
change, and it can go to production, allows you to actually move faster, instead
of pussyfooting around with every change.
Like tests give you confidence that you are not breaking the system, after you
have made a change, an up to date documentation of your product, technology
gives you confidence when you are about to make a change.
Good document can start helping even in the requirement step. If you understand
the current behaviour of the product, deciding to evolve it and add new
behaviour becomes easier. Without a good way to understand how current
functionality works, changing it to incorporate a customer request requires
either wading through the product, or speaking with people who understand how
the current product works.
What do you think? Do you like working on software that has good documentation?
Or do you think its a luxury or a crutch, and diving into code is the right way
to go for most people?