So why is it so important? We rarely understand the code itself, it’s in-depth functionality and correlations. We just give the Developer Lead information on what we need accomplishing and a deadline. Then, usually, if the Dev Lead is quick and steady on his feet, he will force a discussion, if not, well, then that, unfortunately, might mean a cute error screen during your presentation. Does that make you worried?
GOOD CODE QUALITY MEANS LESS ERRORS AND LESS UNPAID HOURS FOR FIXING IT
IF DEVELOPERS ARE ALLOWED ENOUGH TIME, THE CODE WILL BE MADE MORE MAINTAINABLE
PUSHING ON CONTRADICTING FUNCTIONALITIES, MAKES DEVELOPERS FEEL UNHEARD AND, THEREFORE, NOT DO THEIR BEST
DELIVERING WITHOUT ANALYZING WILL MAKE YOU LOOK UNPROFESSIONAL
The Problem
When I started IT Project Management, I had a lot of advisers from more senior positions, who would tell me that developers are lazy slackers, who need to be managed with an iron fist. Before my first project had even started, I already had preprogrammed fear, that I would not finish the project on time, because of the developers and that the management would provide me with clear guidelines, that developers will not honor.
This confidence, with which they spoke, made me a bit suspicious, so I made a conscious decision to express my doubts to one of the developers. Of course, I heard the same about the management – they push contradicting features, don’t care about timelines or testing, change their mind constantly and half of the functionality the developers have made, is not even being used, because the original functional requirements were not accurate. So why should they bother? No one listens to them anyways.
The result is that developers stop caring and give into shipping bad code within unrealistic deadlines, that works based on magic – this is the code that gives you a big beautiful error screen right in the middle of your presentation for potential investors.
The Solution
First of all, as an IT Project Manager, you are not Team Management and you are not Team Developers. Sorry, but you, my friend, are on your own. You need to understand that these teams exist and that both will shift responsibility on one another. It’s just how it works. But the reason why you are there is to manage their communication. A valuable lesson I have learned is to drop my ego and to listen. To put it on paper, and research, and analyze.
A project manager needs to be willing to learn about management principles and business requirements, and what makes and brakes profit. Also, an IT project manager must possess an interest in learning about software development principles, version control, testing tools and so on.
If a project manager can be able to hear both parties and deduct the unimportant, he can, with time, develop decent interpretation skills from business needs to functional requirements, and therefore, if working closely in a team, predict an accurate timeline for deployment and not rush development team and your product into disaster just to exceed business expectations in uneducatedly set deadlines.
The Results
In the problem or the solution overview, I talk more about teams, than code quality. This is because code quality is something that arises from this interaction.
With good knowledge, it is possible to know that one shouldn’t necessarily listen to the one who screams the loudest or pushes the most, but to the one who is most relevant and right.
If the project manager can listen and interpret, he will know when to listen to the developers and know that something cannot be done in a certain deadline or is contradicting with existing functionality. This is a way to escape rushing developers into writing cheats and not leaving enough time for testing, that would later take ages to fix and maintain, and further worsen the relationship between project owners and developers.
As project managers, we don’t talk about this often enough, but it is frequently one of the key factors in making a well marketable product with high value and life expectancy.