This is the first segment of a three-part series where Profinit’s CEO, Tomas Pavlik, offers recommendations on how to avoid serious mistakes when searching for developers for your team or when shopping for custom software development when there is a serious shortage of qualified software professionals in Europe.
Over the last two or three years, we have seen a new trend emerge among developers on social networks. Everyone laughs at ludicrous meetings with incompetent recruiters, hopeless offers of head-hunters, and companies trying with all their might to lure the last programmer available in the empty job market. Some compete on the number of interview invitations they get per month, who gets a job offer in the most remote location, or who gets more dates with HR girls.
Notwithstanding this raging battle for each and every qualified individual, I see every day how wastefully these precious resources are treated. The lack of resources has not reduced the number of projects that end in total failure or that require unplanned “stabilization phases” capable of inflating by multiple times the original budget and schedule. And there are no fewer people working on software projects who feel like they are being overworked, their talent is being wasted, or that their work has no purpose and will likely be shelved.
In this series, I make 6 key recommendations whose application I believe has brought about both increased developer satisfaction and a much higher success rate on projects for customers.
1st Recommendation: Respect known facts
Practically all the large projects I have come across in the last 25 years have been affected by the ignorance of one absolutely essential fact that has been known in software engineering from its dawn, which either the entire professional community still feels ashamed to reveal to customers or customers refuse to consider. I am talking about the fact that the inaccuracy of labor/cost/time estimates, at the time when these projections for projects are typically made, is hundreds of percent. It is as if you made a budget for your family housing before finding a wife.
Some projects mitigate this risk by using preliminary analysis or prescribed architectural patterns. This could reduce the inaccuracy to higher tens but never to single digit percent. Despite all the experience accumulated, this area is ruled by enormous naivety resulting in stress and pressure to catch up on things when it is physically impossible, even with overtime. All this causes immense frustration for everyone working on the project.
The inaccuracy of estimates must be regarded as a natural feature of software projects, entirely logical and not the fault of developers or contractors. As a contractor, if I want to start a software project, I must understand that before I can get an exact estimate the precise construction of the entire software system must be devised. It’s the same as building a house – I will not know the exact budget until I have decided on the colour of the very last tile in the bathroom and have selected the last switch for the basement. But just getting to this stage takes time and costs a considerable amount of money that must be budgeted for. There is also the opposite approach – to fix the budget and gradually alter the scope. In other words, to deliver the maximum scope that can be obtained for a fixed price. But then there is a risk that instead of getting a house you will only get a garden shed.