Maciej Kochan with a bookshelf in the background

Consultant’s Corner: How many Java programmers does it take to reproduce the works of Shakespeare?

Maciej Kochan writes about the transformation within his team, which started as a team of just programmers. Moreover, he reflects on how many programmers are needed to complete a project which requires much broader skills than just knowledge of Java and programming skills.

Welcome to the Consultant’s Corner series, a blog for IT freelancers. Here you can find out what fellow high-end IT consultants are up to in their current or recent projects. Read about trending technologies, and get inspiration from the freelance journey of other like-minded IT professionals.

By: Maciej Kochan

The question in the title references the famous theorem about monkeys being able to randomly write the entire works of Shakespeare (the “Infinite Monkey Theorem”).

The theory describes an exciting paradox whereby individuals who are unqualified and untrained in a given field (such as monkeys, which are unfamiliar with literature) could, with a large amount of luck, manage to write the entire works of Shakespeare.

{   ... There is a temptation to hire only programmers for project teams . ...   }

Where is the connection with IT?

Similarly, one can also wonder how many programmers are needed to complete a project which requires much broader skills than just knowledge of Java and programming skills. We can assume that the project will be completed, but will it be efficient?

Although this problem may sound somewhat absurd, experience shows that it does occur in practice.

There is a temptation to hire only programmers for project teams based on assumptions (but not necessarily correct) such as:

  • Programmers are intelligent people who can even handle tasks not necessarily related to programming.
  • Hiring another programmer is more manageable than opening a recruitment process for a different, often one-off, role. We already have the interview questions and tests for programmers, active job ads, job descriptions, management approval and the like.
  • It is easier to train a programmer to be a Scrum Master, for example, than turn a Scrum Master into a programmer.
  • There is not enough work for a Scrum Master or Product Owner to justify a full-time post in our project.
  • In crises, we will have more hands to write code and fix bugs.

Teams are usually created solely by programmers; some also perform the other roles necessary for the project. So, for example, one person is the “DevOps Developer”, someone else is the “Project Manager”, and a third person is the “Scrum Master”.

This article is about the transformation within our team, which started as a team of just programmers. 

{   The essence of the change was the addition of specialised roles such as a Scrum Master, Product Owner and Business Analyst.   }

The essence of the change was the addition of specialised roles such as a Scrum Master, Product Owner and Business Analyst. The change process was quick, taking just a few months, and it allowed us to compare how the same Java programmers worked on similar tasks but supported by the new process and the roles described above.

Maciej Kochan looking out of the piucture frame with a bookshelf in the background

Maciej Kochan: It is crucial to stress the importance of the client’s openness – the project’s de facto “owner”

The start of the project

Our project started; we explicitly defined the tasks, and the challenges facing us were mainly technical.

Over time, the requirements evolved as the project’s scope expanded significantly, and the number of external dependencies and the need to coordinate with others grew immeasurably. Broadening the scope led to conversations with the client about the future direction of the project and the team. Furthermore, it had led inevitably to the point that the programmers had less and less time for programming, and the clients did not have a good overview of the progress of the work.

It is crucial to stress the importance of the client’s openness – the project’s de facto “owner”. The client assumed that they were collaborating with consultants who understood the goal and issue well enough to suggest the most appropriate means to achieve it, including the composition and skills of the team.

So, by agreement with the client,

  • a Scrum Master,
  • a Product Owner,
  • and a Business Analyst

were added to the existing Java-only team.

Backlog

Programmers taking on projects based on their programming skills may not necessarily have the skills or desire to manage backlogs.

For this reason, our backlog grooming was carried out intermittently and only organised just enough not to get lost in it. It was poorly refined, however, with individual stories either being described briefly or not at all. Another aspect that we ignored was that the backlog was very technical and unreadable for the product recipients.

Introducing a Product Owner with both the experience and the time to take care of the backlog helped solve these problems and relieved the programmers of managing the backlog. Meanwhile, the Product Owner shared information about the progress of the work for stakeholders outside the team.

{   The presence of the Product Owner was beneficial for the project   }

Project scope and roadmap

The presence of the Product Owner was beneficial for the project by defining what we already have done, what still had to be done, when we planned to do it and whom we would have to involve in advance.

There was much coordination of that kind in our project.

If one burdened the developer with such tasks, they de facto ceased to be a developer since they then would not have enough time for the rest of their duties. Suppose we divide up the tasks of managing a complex project among several developers. Then the project elements may move at different speeds, some even being forgotten due to the dilution of responsibility.

It is like having lots of different crews build sections of railway lines – there is a risk that they will not meet in the same place.

Maciej Kochan's hands and a lap top

It may also be a truism to underline that an analyst is better in the analysis field due to their predisposition and experience.

Business analysis and documentation

We run the project in iterations.

From one side, they are similar, but they are never the same, and each one requires analysis and preparation. Repeatability affects how the analyst carrying out activities like a sprint is able, simply through routine and practice, to work more efficiently than a developer who occasionally does such tasks.

It may also be a truism to underline that an analyst is better in the analysis field due to their predisposition and experience.

The tasks were described with more refinement when the analyst started, with partial documentation for the development team and the end customer.

It is not difficult to imagine the delight of developers at not having to face writing the documentation from scratch but instead simply completing the technical aspects.

{   The impact on programmer productivity was enormous.   }

Test data

Part of the analysis and conversations with the clients involved discussion of use cases, test scenarios and test data. In practice, this could mean, for example, obtaining input and output data from surrounding systems and placing them in the project repository even before the programmers started their work.

The impact on programmer productivity was enormous. When we began working on a given story, the business and test scenarios were identified, together with the available examples of expected messages.

The presence of sample data indirectly documented the behaviour of the system and directly provided input for unit and integration tests. In the model without an analyst, the programmer often had to stop the work on functionality to do a partial business analysis of the section related to their story. Furthermore, they obtained data for testing and contacted people who knew the system in question to confirm the desired behaviour.

For example, following the changes, a story that previously required the programmer to work for two days and then wait for three could be completed in just one day.

{

The conclusion arising from our transformation is that specialisation and matching tasks to skills increase the efficiency of the work, the quality of the results and the level of job satisfaction.

}

Conclusion: everyone could do their best job

Summing up the effect of the changes by saying: everyone could do their best job. Programmers could deal with programming, analysts could analyse, Product Owners could manage the backlog, and Scrum Masters could implement agile processes.

The conclusion arising from our transformation is that specialisation and matching tasks with skills increases efficiency of the work, the quality of the results and the level of job satisfaction.

You can say that we are not exactly discovering America with such a statement. Interestingly, however, there is rarely an opportunity within the same project and environment ceteris paribus – all other things being equal – to compare different approaches within the space of a few months to observe the positive effects of changes.

We also received confirmation from the client that the team is now better perceived externally and more autonomous. We can define our plan, identify and resolve dependencies, and carry out the implementation – something that was difficult for a team comprised solely of programmers.

Maciej Kochan portrait

Consultant

Maciej Kochan

Lead Integration Developer and freelance IT consultant, Maciej Kochan has been on assignment via ProData Consult for over two years.

Kochan is a graduate of the Warsaw School of Computer Science and studied Economics at Warsaw University. He previously worked for the CitiBank Handlowy brand for several years.