The project is accepted, the requirements are clear; but where to start to carry out our development?
A natural reflex is to prepare everything in advance to be able to program without meeting obstacles relative to the technological environments. So it’s at this moment that the team organizes a round table and makes decisions according to its knowledge and its level of comfort with the tools. A choice is made for each of the architectural components (database, server, etc.) and we even have a more experienced member proposing libraries that will allow us to develop quicker. Why use this or that tool? Because we might need it later in the project…
We seem to have a complete toolbox that will help us face anything coming our way! But will a mechanic need the same tools as a carpenter? Let’s push the analogy further by asking ourselves : does a carpenter building of a house needs the same tools as his colleague creating a high-end table with intricate patterns?
Unfortunately, in software development, it’s often only at a late stage of the project that the team realizes that the tools or libraries chosen in the beginning can cover many more features than needed. The price to pay? A heaviness (and even sometimes slowness) of the application that can sometimes require an important investment of time in order to remove what’s unnecessary.
We have learned from our mistakes, so let’s choose the components of our application according to the need.
The mentality of choosing according to the need is very widespread and taught during Agile transitions. We will therefore wait until we need to save our data before choosing the database. There might be an important detail to take into account that will have us choose an option rather than another.
Since versatility is important to our team, every task can be done by any member of the team. A less experienced colleague might have to make this technological choice. We count on collaboration and take for granted that he will ask for help if need be. But this person has taken time to read the documentation. He feels confident that he can do the job alone. The result? At the end of the sprint, the new technology is integrated to the source code of our application in a way that does not please everyone!
If we realize it quickly and confront the problem in a short time, the impact is minimal and this colleague might get important knowledge out of it. But the technological choices are not always visible or obvious, so a bad choice can be overlooked and cause peculiar development practices to be able to write compatible code.
Once again, the consequence is an investment of time than can sometimes remain unseen for a long time. We will need a developer with a rather critical mind to question the initial decision before realizing that hours of work have been spent trying to circumvent a problem that was simply considered a given. The more the project advances, the more this number of hours can be important. What will the Product Owner think, he who manages the budget?
Let’s decide as a team and optimize our environment
So what’s the recipe for a development environment that will allow us to complete this project in optimal fashion? We need to:
- Benefit from the knowledge of all the team members;
- Eliminate manual and repetitive tasks (as much as possible);
- Take for granted that all might not have the same configuration;
- Document the development while thinking of future developers or about the possible production of the application.
Let’s address each point one at the time…
Benefit from the knowledge of all the team members
If we are responsible for choosing a tool or a component, it’s primordial that we put our egos aside and openly talk about our path toward the final decision. Inversely, the rest of the team has to question the choices made to make sure a trap that will engulf precious hours of work throughout the project is not setting itself up. So everybody needs to take responsibility for this integration, even if everyone will not part of it.
This point is especially important not to fall into a dynamic of pointing the finger that can divide the team and have some people feel incompetent. We all work together to help each other out!
Furthermore, it’s possible that a colleague has extensive knowledge about the technology that we chose. Sharing information is then a crucial step that will not only allow global skill improvement for everyone to know what they are getting into for the duration of the project, but also knowledge of how to work optimally with this new piece of the puzzle that is our product in development.
Tips and tricks taken from past experiences can be exchanged in discussions, which is much more useful and quick than an extensive study of the documentation. It’s by talking together that we will then be able to avoid traps and who knows, maybe even work in pairing with the one that already knows the technology. The benefits are important: an optimal development process, an information exchange and clarifications on the most obscure points; without forgetting a better quality of the final product. It should be taken into account if people external to the project question the relevance of having two people working on the same task.
While one of us works on the integration, the other can take this opportunity to write a page documenting a few leads that will allow the rest of the team to know where to start building with this new technology.
Eliminate manual and repetitive tasks
Talking about traps, how many times does a programmer need to deploy a version of the application on the test environment to make sure that the bugs are fixed? Once the application is stabilized, the Product Owner will undoubtedly want to present it to the project’s stakeholders by staging a demonstration. The application will then need to be deployed in another environement. Oh! We forgot something and the configuration from the wrong environment is being used. The demo is not functioning and this hour scheduled in the agenda of possibly overloaded people has been lost, undermining the morale of the Product Owner and the rest of the team.
However, deployments are frequently made and the process should be mastered by everyone! It’s only one example of a disastrous situation that can arise during a development project, but that could have been avoided by addressing a simple but repetitive task from the beginning.
That is why these manual tasks that may seem mundane, but entail their share of risks, should not be taken lightly. It would be better to invest more time in the beginning to put automated processes in place. Of course, that implies more efforts initially, considering the development tasks added to what could have only been the configuration of the infrastructure. The direct benefits are easily measured when noticing the hours saved on manual tasks, but the door is also open to other advantages we do not always think about.
For example, a script that will run every night can simply call one of the automated processes, or a user interface can be created quickly (for internal use, so it’s not necessary to linger on aesthetics) to enable some people who are not involved in the development to deploy the software in the environement they are using. There are a lot of possibilities that do not require a lot of development efforts, but that can seem insurmountable if we did not build our little internal tools iteratively.
Take for granted that all might not have the same configuration
How many times will programmers hear the following sentence during their career?
“Yes but it does not work on my computer, and only on my computer…”
Every time a software component is integrated to the project, this reality absolutely needs to be part of the first hypothesis. If we decide to use a tool that’s hard to configure, we inevitably have to expect to face a development environment that does not have the same configuration (or version) as the others. It is then that investigating can occupy a developer, maybe even two, for several hours, or even days.
The best approach to avoid this type of problem is to properly define, from the beginning, the different environments that will need to be supported by the software. In the case of a Web-based application, the automated tests suite may be built to be executed on several browsers. The tests will not only allow us to avoid regression problems as we add new features, but the team will also be confident that problems won’t arise on browsers that are not being used as frequently during the development process.
In the context of client-server applications, the server part of the software should not be neglected. Since the completed application needs to be executed on the developers’ workstations, the different configurations can bring twice as many problems. Unless you reset the developers’ computers after every project, you only need to have developed a few apps to have the past come back and haunt you. A tool we forgot to update, or a special configuration that was necessary not so long ago can cause their share of problems. And the cause is not always easy to find…
The arrival of containers and tools like Docker can greatly help avoid this type of situation. Instead of having a complete image of the computer that forces the developer to lose his customization after each reset, it is now possible to build a file that defines a container image from several preconfigured software.
Usage of this file by the rest of the team enables us to guarantee that all are using the same environment, without interfering with everyone’s customization. Once the project is over, we will simply be able to delete it from our computer. And if we had modifications to make a few months later? It suffices to rebuild the image from this file and we will find the same environment that we had, without installing and uninstalling our development tools.
You only need to invest a little time to learn it, but your developer’s life becomes so much easier!
Document for the future
Documentation is often the bugbear of the team’s tasks. Obviously, we need to find a balance in order to not document too much and to do that, we need to think of the future.
When a new member joins the team, what are the steps (not already automated) that he will need to pass to be ready to code? Each of these should be documented in a centralized spot to avoid having to assist his installation and always having the same problems.
The same strategy applies for the moment our software will go into production and be accessible to all its users. If it’s not us, the programmers, that will be part of this crucial step; we have to make sure that the person responsible is comfortable enough with the tasks to be achieved.
It’s by having documented here and there throughout the project that we can avoid having to put ourselves in the shoes of an external person and write during long hours, risking to forget important points. Do you prefer improving the documentation a little at every sprint and make a final revision at the end of the project, or being wakened up at 3 AM because the system admin does not know what to do anymore with his deployment process?
The recipe is simple…
The secret for a perfect development environment? You only need not to make it too complicated! Don’t hesitate to involve the rest of the team in the implementation and also to actively be part of it when others are in charge. Anyways, you will be able to benefit from an important learning and will make sure that the next weeks (or months) will be without hitches.
Need help?
If you have any questions, please do not hesitate to contact us. The expertise of our multidisciplinary teams allows us to support companies that wish to develop the skills of their development teams. To learn more about training and technical coaching, click here.
Good project!
