The following article is written by:
Roberto Martínez Medina, Android Developer At Umvel.
“Good morning guys, just to inform you that the project to be carried out on this occasion was committed for next month. Even though this wasn’t consulted with you, we’re asking you to show your commitment with the company and support us to make the delivery.
I’ll go take care of other things and be back with you just in time for the presentation. Good luck!” — Project Manager
Ok, I may have exaggerated the case a bit. However, similar circumstances may occur in the day-to-day life of many IT development companies, where the relationship with clients matters more than the well-being of the employees. From a developer’s perspective, this article takes a look at the internal process of these situations and offers some recommendations to avoid falling into this trap.
Zombies are not good developers
As a project manager, maybe you think that working 16 hours a day from Monday to Sunday is the best option to get the app out on time. As a developer, you may think that your performance during the first week will continue throughout the next three. Here’s a look of what actually happens in these situations for developers.
(The following is a slightly exaggerated depiction of what a typical developer may go through.)
Week 1
The first week starts very well, we advance in the development in a ‘human way’. You might think: “this project doesn’t seem so complicated, and were delivering new features as if they were enchiladas…”
Week 2
The second week we start to feel the ravages of sleep deprivation and a poor diet, but we don’t mind. We can continue to work as we “normally” do, even though we no longer look like that indestructible team from just a few days ago.
Week 3
By the third week caffeine no longer works, it just makes us feel physically ill. We have back pain and a headache that plague us all day long. We light one more cigarette and continue working.
By this point it’s evident that the objectives are no longer being met, and not only that, but the tedious QA team is breaking our application. How dare they! If it’s so easy, let them do it!
Week 4
The fourth week is the delivery week, but we can’t even get out of bed. The physical and emotional pain is at its peak. The project has urgent bugs and the last thing we want to do is write one more line of code.
The project could not conclude satisfactorily and it’s all our fault. We didn’t hang in there long enough, we didn’t show enough commitment and maybe we’re not such good developers after all.
Ouch! After reading this, you might get a subtle taste of an energy drink in your palate, reminding you of a similar story that maybe happened to you.
In the Migala podcast, the Hobbit, SrSanto and David share their perspective on today’s job culture and encourage us to question ourselves how we want to live day to day. They also have other episodes where they talk about the importance of physical health in this process.
If you ever see someone going through this situation, help them. Talk to them, offer technical support if possible or just remind them that it’s time for lunch. Invite them to go out for some air, to take a break. Tiredness is not only physical, it is also mental, and emotional support is greatly appreciated. But more importantly, the support must come from the project leaders, who have the responsibility to generate efficient methodologies in taking requirements to avoid these situations. This brings me to the next point.
Think twice and develop it once.
If you and your team have never developed a similar platform, chances are that you will start throwing out code as soon as possible, either because of lack of knowledge, or the pressure from time and the obligation to deliver results. However, this will work against you sooner or later, for one simple reason:
We cannot create a product, if we do not know exactly what is expected of it.
If we start developing blindly, chances are that a large part of the project will go straight into the trash, either because we misunderstood business rules, or because we were unaware of the existence of another.
In his book, The Clean Coder, Uncle Bob presents several scenarios in which he explains that time pressures can be unnecessary. If you analyze the requirements, estimate the time and structure and document the business rules correctly, the project will run by itself.
Here’s some advice to facilitate this:
- Requirements meeting
To understand the real need of users in each flow, ask the right questions. The important thing is to find a way to make the development process as simple as possible. We came up with a questionnaire that may be useful. Check it out here!
2. Technical review with the team
Ask all the questions that arise about the project. This can be the overall scope, all possible error cases and what to do about them. Analyze the needs based on their urgency and importance and review them with your team to corroborate that it is the most appropriate solution.
3. Final structuring
The most important thing is that all team members understand the project and what everyone is doing to build it, even the QA team. Provide information to your team, make sure that the timing makes sense according to the difficulty of each task, and you’ll see that problems that arise will be easily solved.
When everyone involved understands from start to finish all the business rules, all the flows and how users will behave with the platform, the margin of error is significantly reduced. To achieve this level of understanding, it’s necessary that the requirements are understood and simplified to the most essential. It’s easier to build anything from the bare essentials, but generating code that then has to be thrown away can break the strength and morale of an entire team.
At Umvel, we push our people to adopt a mindset like described above, and help each other when we need it most. It’s only this way, that we succeed and thrive as business, and as an emphatic, productive team.
Check out https://umvel.com for more about our work, methods, and how we can work with you (as a colleague, or partner).
