Not long ago, I read the following blunt and enlightening statement in a book about AngularJS:
“Software development is hard. As developers, we need to juggle customer requirements and pressure of deadlines, work effectively with other team members, and all this while being proficient with multitude of software development tools and programing languages. As the complexity of software rises so is the number of bugs. We are all human and we will make mistakes, tons of them. Lower-level, programming errors are only one type of defect that we need to constantly fight. Installation, configuration and integration issues will also plague any non-trivial project.”
(Mastering Web Application Development with AngularJS)
I couldn’t have put it better: while developing any project, one of our tasks is to develop new production code, but that’s only one task among many. At the same time, we carry out lots of other tasks related to the project that are just as important. Yet sometimes we trivialize the importance of those other tasks, thinking they have little to do with the project and actually get in the way of writing new code. Because the fun part, the thing software developers enjoy most, is “writing code,” right?
That’s what a naive mind might think, newly arrived in an industry where looking back a few years is like looking at prehistory, given the constant renewal of technologies, workflows, and, why not, even types of projects.
All those other tasks around the code are what make it possible to write quality code and work efficiently and productively. If we haven’t accepted this, we’re still several steps away from truly working as professionals. A project’s quality isn’t measured only by whether the client gets a useful software product, but also by whether the project itself can evolve, be maintained, and be improved. And, in my opinion, there’s another consideration that isn’t always obvious: developers should be able to work on it efficiently, productively, and with satisfaction.
We absolutely shouldn’t move straight to coding as the next step once the requirements are clear. When starting a new project, before typing the first line of code, we need to clearly define, among other things:
- The most appropriate technologies to use and the friction between them. As I mentioned in an earlier post, modern web application development, for example, can involve an explosion of libraries and frameworks that constantly makes you wonder whether you’re choosing the best option.
- The developers’ workflow and the project’s lifecycle.
- Everything that can be automated (automatic builds, final validation tests, and so on). This is an enormous force multiplier that isn’t always considered: any effort invested in this at the beginning will save us that effort many times over during the project’s life. My mantra is always: “anything we do manually several times a day in a project should be automated if possible.” This lets us focus, once we’re working on the project, primarily on implementing user stories and the requested functionality.
- The project’s structure: which folder the code will go in, where and how tests will be created, where the project’s assets will be included, and so on. Defining this prevents team members from putting these artifacts wherever they see fit, without any consistency.
- The production deployment from the very beginning, so that we can anticipate problems in the first release that would otherwise come up at the end.
All of this, I say, needs to be defined and put into practice before typing the first line of code. The temptation to jump straight into development so we’ll have something to show as soon as possible is a trap we set for ourselves: having all the above clearly defined will save us a tremendous amount of effort in the future and, consequently, improve the quality of the product we deliver.
This gives us a few simple rules we should always follow, such as one I often repeat: no activity should be carried out unless it has been planned in advance. For example:
- Don’t implement anything new unless it has been included in the current work phase with an estimated development time.
- Don’t consider anything finished until I’ve created the tests needed to prove (today, tomorrow, next week, and so on) that it works.
- Don’t create any new software artifact until we’ve established where and how it should be generated.
- …
Simple in principle, these rules are the foundation for a development team to work productively and in an orderly way.