With this article I try to answer some questions.
- The company wants to develop its know-how?
- What is killing many companies that deal with development?
The problems of large IT companies are often sought in the development sector, so that the larger the company and more is looking to outsource their development. In some cases they try to control all the know-how internalising the functional areas at the expense of development.
That said I do not think remotely that there may be a problem in IT due to lack of skills of excellence within the company, rather they are convinced that the development industry is just what brain focuses more interesting, those who devoted to development is almost always a passion for deepening knowledge.
For this reason I see the problem of development focused on how developers are put together in the company, how they are managed and why they are made and what the criteria are entrusted roles.
In the experience I had been able to see the results of international excellence and quality only in brief moments, only determate “happy islands” that the market was ready to absorb. These development groups are evaporated by the time many of the companies I’ve known.
The assumptions behind the recruiting developers.
To explain this situation I’m going to make explicit some of the tacit assumptions that often underlie a large company of recruiting a team of business development. This is a crucial point because, in most organizations, those who influence these decisions in most cases will never be held accountable.
Based on the ideas of Ash Moran, the assumptions of the organization in this question appear to be the following:
- Developers are fungible
- The productivity is proportional to the duration of development
- The requirements are all necessary
1. Developers are fungible
Tom de Marco, in his ” Slack:Getting Past Burnout, Busywork, and the Myth of Total Efficiency,” tell about “the myth of a fungible resource.”
Many jobs in the factory and warehouse are fully fungible in the sense that the time to bring someone up to full productivity is virtually irrelevant (hours or days). This is not true when it comes to software development, where even if a new hire knows the programming language, given the context, will take a long time to learn the basic code and business methods.
I do not think that developers are fungible (at least in most cases), but I have attended countless meetings in which decision makers were behaving as if this hypothesis is valid. Every time estimates in hand, the vast majority of managers acting as if a new developer can immediately increase the productivity of the team.
This assumption is in contradiction with what the developers think specifically about the nature of their work.
2. The productivity is proportional to the duration of development
There are two degenerative forms of thought to this hypothesis:
1) The idea that a developer who works 10 hours a day will be 25% more productive than one developer to work 8 hours a day
2) The belief that a team of 10 developers is 25% more productive than a team of 8.
I spoke of degeneration as we are convinced, like Ash, that the nature of software development is the creation of new knowledge, a concept that I described in a previous article.
The hypothesis-productive-time is based on the idea that productivity can be represented as a linear scale at right angles. This is not true in the development, for the simple reason that the complexity in managing a team is not necessarily related to the number of people involved, but the nature of involvement and communication is needed to accomplish a given task.
Just think that sometimes is easier to play a role in many people, rather than trying to put 4 people agree on the choice of which movie to go see after dinner.
Obviously depends on the job, as well as some major IT projects you can do better with a small team.
Inattention is the main cause of major bugs.
Let me point out an interesting article: Do You Suffer From Decision Fatigue? ; il cervello umano ha una capacità limitata di fare scelte, e una volta stanchi, ci trova spesso a ricercare scorciatoie.
3. The requirements are all necessary
In most large software companies, functional requirements are defined outside of the development team. Unless the development team is not writing software only for himself, the so-called “Functional Area” (Functionals) will be involved in drafting a document that describes the work to be done by the development industry. Then sometimes it happens that 30% of the functionality in the software will never be used or not needed, then at least 30% of development time becomes pure waste. However, many teams are contractually obliged to provide a specification (document functional) without reference to the value of the specific characteristics of the same, this can be a source of bugs hard to heal.
4. The engaged team
The increased capacity is not the only reason why you should hire people. A very good argument is the redundancy. The teams are very small vulnerable to Murphy’s law, if your sole developer gets hit by a bus, the project will be in grave danger. But it is also possible that a team of 10 people and devastated by a single incident in the same bus. Some questions about the size of various work teams are detailed in an article by Christopher Allen entitled The Dunbar number as a limit to the size of groups.
A small teams may be less risky than it appears, because the developers are very rarely hit by bus, as is true though that must be managed as I very rarely leave their jobs for paymet reasons.
Programmers frequently leave the team due to poor working conditions, conditions that are almost always caused by the decisions of managers.
There is also a situation where you do want to increase the size of your team: when the person you are adding has the knowledge and experience to help improve the effectiveness of all others. In this case, however, their responsibilities must extend well beyond the pure development.
The first thing is to step back and see if you are trying to solve a problem primarily caused by systematic futility in providing a greater effort to the team.
We know that if a Captain of a ship, which saw a flaw, order to all the sailors to empty the water rather than monitor the situation and call a single engineer to repair the leak, would be ineffective.
Fred Brooks gave Brooks’s Law more than thirty years ago: “Adding manpower to a late software project makes it later.”
Improving the productivity of a team that develops software is difficult. It is about understanding the business, the team, the story and the obstacles that block progress. They are facing a complex problem, context-sensitive.
We see the world filtered through the metaphors that we can express.