In the last couple of years I've given countless lectures and talks focused around the topics of development practices, software architecture, technologies, and the software development life cycle. Furthermore, I've joined discussions on popular network such as Hacker News or contributed to open-source project mainly via GitHub. All these experiences resulted in a clear image how software development should look like and how good projects need to be executed.
Generally, there are quite some steps for a successful software project. Most importantly, one needs a vision and a plan for this vision. The plan involves certain milestones and required features (+ optional features). I am not talking about the business perspective right now, just on the software development side. Once all the requirements are known and agreed, one needs a concept and a solution + software architecture. Now its up to the implementation. And here we need to see the following:
- A developer documentation in form of a README
- Documentation of high-level changes in form of a CHANGELOG
- The best tool(s) for the job, i.e., suitable programming language, frameworks, ...
- Proper unit test coverage, i.e., TDD at best
- A build system that also works locally, e.g., Gulp or Cake depending on the kind of project
- Static code analysis
- Conventions and coding rules / styles that are simple and documented
- Documentation generation
- Artefact / package definitions
- A publication process that's included in the build system
- A central hub to coordinate the development
- A decentralized version control system
- A proper branching model that follows the development coordination
- A CI system that's automatically triggering the global build once certain branches are about to be modified
- Automatic deployments with a staging character (hand-over to integration tests, then to manual testing if necessary)
That's quite an extensive list, but I think that nearly all of these points are required for any kind of project where a certain level of professionalism is apparent.
So far so good, but where is my message? In the recent years I did consulting for many companies. I also had a look at the work flow from different companies during interviews or in discussions at conferences. Finally, I've also seen how large IT service providers work. And frankly, I can't believe that really important bullet points from the list above are not on their radar. Not even close.
Let's start with the topic unit tests. Unit tests are important. Any kind of bug that has been seen needs to evolve to a new unit test. Apparently, it was a missing unit test before the bug was spotted. If the bug does not transform to a unit test, then we will face the ultimate fear of regression in any upcoming release. Furthermore, the unit test will already help us in finding the bug. One of the strongest arguments against unit test is that the bug only happens in production. How can that be? If the bug is on some other component - then yes. But usually the bug is within our system. So we need to be able to provide mocks to trigger the behavior seen by the production environment. If we cannot use such mocks, then there is something wrong with the software design or implementation.
There is yet another story that is mostly happening in the JavaScript / web world. Here, I was surprised that most teams still use plain JavaScript (even though the world is definitely moving towards TypeScript for larger projects). They don't want to use typings in their code, even though a team of 25+ developers are working on it. How can that be? If someone decides one day (wisely) to so refactoring, then there will be bugs. These bugs can only be prevented (in plain JavaScript) by writing enough unit tests. But we remember the first story. Unit tests are not written very often, and if so then only mediocre ones are supplied. Coming up with the minimal amount of typing would therefore not only generate beautiful .d.ts files, but also reduce the number of required unit tests.
There are many more similar stories, but the bottom line is that due to fixed price contracts and feature centered business guys, the software development usually suffers. Quality is not regarded as the highest good. And then the same people who centered around features instead of quality wonder why the software has too many bugs and is too bulky to be extended / modified in short time.