Taking Software Infrastructure Seriously

Keith Adams, the chief architect at Slack published an interesting article: "Taking PHP Seriously". You should invest time in reading it (along with the discussion). In this article, Keith explains about the advantages of PHP and tries to attack the common anti-PHP attitude.

I think that while any language and environment has pros and cons, there is no such thing as "bad" language and eco system. Languages can go obsolete, their communities dwindle and die, but there is no "bad" one. Yes, some languages are better than other in solving different types of problems. I would not use PHP (for example) to create MS Windows monitor system and I would not node.js for heavy weight calculating stuff. But I don't think that you can really say that a language is a bad one or extremely incompetent one.

While there is no bad language, there is BAD software and BAD development habits that can drive any product to oblivion and any company for destruction. Creating bulletproof development, integration and deployment is much more important than choosing the language. A lot of developers invests a lot of effort in choosing the language or the environment but neglects thinking about the development\QA infrastructure of the project. What is the infrastructure? It is everything that surround the language itself: from the actual deployment, the development, the continuous integration and development process. Failing to invest time & effort from the start in those infrastructure can cause horrible consequences.

I will elaborate a little bit about several parts of the development\QA infrastructure:

Unit testing\ E2E testing\ Integration testing

The unit testing environment. Is it easy to write testing? Is there enough documentation for it? Is there any build process that measures the coverage of the tests and the quality? Can anyone run the tests easily? Does any member of the team, regardless of his technical knowledge, can review the coverage of the tests? I've seen enough projects that lacked of any unit testing and I've seen their outcome. It is not pretty. Good, solid, testing infrastructure will allow you to create robust and reliable products. Even when in the start you will not have time to achieve high code coverage or elaborate E2E tests, implementing tests infrastructure from the start will allow you to cope with the tests technical debt later on. Start to develop test infrastructure to existing products is very costly\ virtually impossible.

an example of slack CI bot that report on the exact state of the code coverage.

local deployment

Deployment is not the famous (or infamous) continuous deployment process, but a local deployment process done by the developers. Does the development version of your product can be deployed easily? on every platform? If I am a new team member, can I deploy and start contributing to the code base with ease or will I need to invest couple of weeks in creating the environment suitable for the product? I've worked on PHP products that took me 1 hour from getting the git access to actually coding and I've worked on PHP products that their deployment was so messed up, that it took experienced dev-op guy two weeks to install them. If your product is almost impossible to be deployed, you will have serious issues integrating more developers in your team or to allow other teams to contribute.

Other processes

Static analysis tool for back end and front end code is extremely important. Especially when there are more than 3 programmers in your team. With static code analysis implemented locally and in the build process, The code will be much easier to maintain. Documentation process and even strict rules regarding the Git repository contribution. Pushing straight to the master, will pass if it is one man show and will cause havoc in larger team.

Conclusion

There is no bad language, there is a neglected\bad infrastructure. You can use the brightest, newest and the most exciting, cutting edge software, but if you neglected planning and creating the CI infrastructure, you are doomed to fail. You might achieve time to market, especially with small products, but for big one (Not Demo project that can handle couple of thousands of users, but a real one), you will fail. and by failing I mean performance issues, UI issues, maintainability issues, huge technical debt and failing to achieve customers and users satisfactions.

There are a lot of excuses from programmers, even experienced ones, regarding the lack of this infrastructure. Most of those excuses are about "We needed to achieve time to market". You can cut corners around some of the processes, but you should never neglect it completely. Do not think that by choosing the brightest and the shiniest software you will be able to avoid investing time and effort in your development and QA process.