If you are a team leader, a project manager or just a developer, you probably have got the following issues. Here’s how we could work around them.
Time Estimation Missteps
One of the most frequent difficulties in software development is task estimation. We could find many reasons of this fact but, in our opinion, the main one is that everyone lies to each other. However paradoxical it may sound. Developers multiply the estimate, which seems to them real, by three. Managers then double it on top. And later their leadership will increase the estimates three times, as well as the stakeholders won’t much hope to meet the deadlines.
There are a lot of attempts to formalize this process and to exclude the human factor, but by and large the task is still not solved and is being solved solely by the experience of managers who directly communicate with performers. The most efficient scheme uses conditional units of measure, also known as story points.
But even in this method there are drawbacks — here mutual lies are continued as well. The first thing that is told to a newcomer by old-timers is that their conditional chrono-parrot (or one story point) contains somewhere about five hours of development, and you should evaluate it that way — by dividing hour estimates by five. And that’s where the lies begin.
Everyone in his mind evaluates the task in hours, and then, using simple mathematical operations, turns it into story points. After that everybody attentively looks at the colleagues with a piercing gaze and thinks, whether the number of chrono-parrots turned out too small (or, conversely, large). And then it is changed to meet the expectations of colleagues and managers. This is repeated over and over again.
Code Evaluation Criteria
What is your position regarding the evaluation of the program code in your team? Do you support a regular code review or are you limited to the fact that it works as expected? Summarizing best practices in software development, we notice that all of them pay a great attention to the code cleanliness. But how to understand whether the program is good enough?
In routine everyday development process it becomes a great challenge to determine how good the code, which is currently being written, is. And this is not because the developer is not smart enough for this code. The simple fact is that the created code for the developer is, by definition, already the best one, otherwise he wouldn’t come up with it. Usually the rhetoric of adding crutches to the code base operates with concepts “there may be some not very beautiful parts of the code, but you just can not write here in another way”, and the consequences of such arguments we all know well.
There is a technique for self-checking written code, in which it is still impossible to detect all the shortcomings in your pull requests, nevertheless, most of them can be caught. This is a set of litmus papers (triggers, if you will), which you should always remember while writing the code. Here are some of them:
- Is it easy enough to test the resulting code? If there are problems with writing tests, then something here smells like a bad code.
- Can this code be scaled vertically well? And we are not about running several applications side by side, but about adding entities to the level above. Like ‘company_id’ or others.
- Is it simple to come up with a name for a certain method or a variable? If the naming is not very obvious or it is thought up hard, then most likely its content is not quite evident too.
- How many methods do you need to redefine? Are there many boundary conditions being processed? Or, in the general case: how are the rules, which your functionality is based on, formulated and how many exceptions to these rules do you have? It concerns not so much business logic, as a properly chosen architecture and code structure. If there is a bug found in the system and you can fix it, only by adding one more conditional branch, then this bug did not appear from scratch, but from the incorrectly organized code structure.
There are a lot of such criteria, some of them even can not be formulated just like these, and in each particular project the requirements may vary. Moreover, a good developer already has a set of such criteria somewhere in his subconscious and defines a badly smelling piece of code precisely by them. Try to formulate these criteria for yourself in writing and constantly improve this list. In addition to the clear formulation of the shitcode, you will also get a great self-test tool, because after six months of writing your code seems not so good, and the reason of that can be seen by the new criteria that have appeared.
Say No to Temporary Solutions
There are solutions that are preferred to more successful ones at the moment for different reasons: less time required, simpler code, simplified design and so on. Some developers tend to use such a trick just to evade a particular task complete implementation or to meet up deadlines. But the decision that is being realized here and now can exist for years without changes and intertwine with other parts of the application so closely that it will be extremely difficult to replace it. So it turns out that we postpone a task for an uncertain future and forget about it. And the number of such crutches increases with time.
Of course, sometimes it is necessary to compromise and we have to do that all the time, but don’t comfort yourself with the thought that such a solution is temporary indeed and so you can slightly give up your principles here.
Remember: there is no such thing as temporary code. Reviewing and adding some part of code to your application, consider that it can stay there forever. And then the number of permanent temporary hacks will suddenly decrease significantly that will make your code much clearer and more evident for other team members.
Recruiting Good Team Players
When gathering a team for joint work on a project, you should determine whether a particular person is a good team member or not and whether his skills and personal qualities are appropriate enough for the productive work. Knowing how to distinguish a perspective candidate from an unsuitable one can be crucial to your project management success. Each company’s HR has its own ways and tricks to deal with the goal, but is there an unified algorithm to avoid mistakes in hiring employees?
In the army there is a wonderful, in our opinion, criterion, by which it is not difficult to distinguish a good soldier from a bad one. It is about the expression: “I would not go in exploration with him”.
Indeed, when it’s asked about the consistency of the combat comrade, the criteria can differ a lot, and each of these criteria vary depending on the advantages and experience got. For someone it is important whether the partner shoots well and runs fast. Another one is looking for somebody who is silent and cooks tasty. And the third one needs a person who isn’t afraid of snakes and is able to control a combat helicopter. Trying to create any more or less universal list of required qualities and properties of a fighter, we very soon skip to the listing of characteristics of some kind of RPG like “Fallout” or “Skyrim”. And it will be extremely difficult to distinguish a good fighter from a bad one.
But the following subjective assessment of a comrade-in-arms will very easily make it clear whether this javascript developer is a good fighter or not very good. Ask yourself two questions:
- Would you agree to work in a project where he is a team lead?
- Could you trust him with a task which you are responsible for?
If both answers are “no”, then such a fighter needs to be urgently sent to the building battalion and kept away from the production.
What to read next:
- Proper Task Management: what to do if you get few tasks from your project manager.
- Developers vs Managers Confrontation
You could stay aware of the latest posts and tips on project management and software development from our team by following us on Facebook and Twitter.
