This is the last part of the 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.
5th Recommendation: Don’t let a civil engineer do your heart surgery
Software development is a demanding field requiring talent, a good university education, and lifelong professional development. It is a field comparable to medicine. Despite this, many people think that anyone who has completed a one-week course in HTML is a programmer. Certainly, even a small kid can cobble up a webpage. But the difference between a simple webpage and software that does money transfers for a bank is about the same as that between applying a skin patch and doing cardiac surgery.
Do not underestimate the complexity of the software or the education necessary for developers. Five years of university education in software engineering is just as necessary for any developer as the completion of medical school is for a doctor. Ask you suppliers about what education is required of their people. Be demanding and uncompromising regarding the education of your in-house developers. Our experience unequivocally shows that quality professional education is more important than years of experience at a company where software is just “thrown together”.
6th Recommendation: Look at costs, not man-day price
When dealing with procurement departments in large organizations, we often notice that their only objective is to push down the man-day price. Unfortunately, in many tenders the man-day price appears to be the only hard value that matters. But the cost of software development is a much more complex variable. Apart from man-days, one must take into account the difficult to measure productivity of a developer, and even more difficult to quantify, the long-term capability of the supplier to keep it up and ensure it is increasing in the team. What metrics do you or your suppliers use to measure productivity? Are they suitable for your specific situation, or only the textbook kind? Or do you not measure it at all? How do you or your supplier ensure continuous improvement in productivity? Do you know how much time is spent writing new code and how much time is spent correcting errors? Do you know how many lines of code your developers produce per day? Do you use the function points method?
I have observed that in the last two or three years the situation on the software market has changed dramatically, and in software development it will be more and more difficult to manage by deliverables. By which I mean that within the given time and budget, I want to implement a set of functional and non-functional requirements without worrying about what happened before and what happens after such a project. I believe that we will get much better results when we start to manage by team capacity, meaning that in the long run I allocate stable funding and then I only keep optimizing how many requirements can be accommodated with the money available. If we can accept this market change as a new paradigm and adjust to it, I believe it will help us to make software more efficiently and with more pleasure and satisfaction, and that’s what I genuinely wish for both customers and developers.