Over a million developers have joined DZone.

Walking in The Shoes of The Software Developer

DZone's Guide to

Walking in The Shoes of The Software Developer

Developing processes that are less predictive and more productive is the only healthy way to manage software developers.

· Agile Zone ·
Free Resource

[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.

I have a cousin that use to work in a factory. His job was to bend pipes. He was in a station as part of a production line. Some station before his station does a specific bending and some station after his station does another specific bending so at the end of the production line, the product was finished.

The task given to him reads something like this: "For client “X” for order number “N,” do bend “Y” on 300 pipes" (the number of pipes always is different). So, the industrial engineer's department provided the machinery, the tools needed to do that specific bending, a set of instructions on how to do the station setup and a set of instructions on the bending of the pipes. Usually, they do that once and then as the orders arrive the worker do the same bending over and over again. The engineer's department are the brains, the worker is the executioner of the job.

The industrial engineers can calculate quite accurately how much time a single pipe takes to be bend so they can predict how much time 300 pipes takes so the task can be complete. Also at any time a supervisor can come to the station and ask the worker how many pipes have been bent (let's say 75 pipes) to accurately calculate the percent of the task completed, in this case, 25%.

So, in regular project management it's almost a no brainer  to measure the status of the project because you can see physically the amount of work been done, no matter how complicated the product is to produce. (Still, you need proper training to do so and to learn things like “Earned Value.”)

When trying to manage software projects a lot of managers want to implement that factory kind of management. The results are so bad that most of them see the developers as a necessary evil, a company expense, something they must try to avoid at all costs. The failing project ratio is high among them or had a lot of problems and headaches, with projects that never seem to be completed.

When developing software, the developers are also in a workstation, they also have machinery (computer, monitors, keyboard, mouse, headphones, coffee mug), tools (Sublime, Visual Studio, Eclipse, Android Studio, Xcode, Robo 3T, SQL Studio, Git, Jenkins), they also develop skills (Python, C#, JavaScript, Ruby, PHP, Java, and SQL).

But the big difference is that on software development there is not possible to have an industrial engineer department that will study how to automate a task with a list of instructions you can execute to produce pieces of software like a production line by the developers. The software developer is provided with a description of the job the software must accomplish, the software requirement. These requirements are unique, they don’t share any properties among them. All of them must describe a single piece of software that has to be made/coded line-by-line and is not like any other piece of software in the rest of the project. It is like a tailor making a suit for the client-specific body measurements.

The process of the actual software development is a black box, there aren’t instructions on how you can do it. It cannot be measured, it cannot be predicted, it is done completely in the mind of the developer. Sometimes it cannot be determined if it is possible to do it. It's the software developer's job to figure out how the computer is going to help the user do his job and come out with a set of instructions in a programming language (the code) that the computer can understand so the user can perform the job described on the requirements. If you give the same task to two different developers, the code that they write will be completely different and even so, both can accomplish successfully the task.

When we are creating software, we think on a small portion of the task to be accomplished, come up with a solution, then write the code, usually a couple of lines of code only so we start over again until the entire requirement is fulfilled, so we complete the task little by little. We then test the code, we make corrections and enhancements, we make data validations, we prevent problems, we handle situations where the job takes more than one path and implement the handling for the exceptions, we improve the code to be readable, fast and easy to maintain. A lot of the times I sadly see that during a day (8 working hours) I only write no more than 100 lines of code. It doesn’t reflect the amount of work being done since the majority has been done by the mind and there is not physical proof of it.

Because of this, it's nonsense trying to measure the task assigned to a developer by a percent of the amount of the work being done and how much work is left to be done. In software development the task assigned to a developer has only the status “Not Started,” “In Process,” and “Done”; but you never will have a realistic percent measurement of the amount of work being done. It is a very common scenario where a developer who has spent 4 days in a task and says the task is 80% done, with that information we can assume that the other 20% only will take 1 more day, but maybe it ends up taking 4 more days instead. So it is very misleading.

It is possible to implement processes before and after the actual software development (the black box) and that processes can be properly executed and measure by using tools like Jira or Bootcamp, but usually most of the teams don’t implement any processes which easily can lead to a chaotic project. You can spot this because of the way the managers have control over the projects is by giving only orders, with no planning and everything being addressed only as it shows up.

The software developer also is not in a production line. I usually make the statement that developing software is not an art, we create tools for the users. A software developer's team will be creating and shaping a tool for the users so they can perform their job. A software developer only contributes with pieces (or modules) and they need to be very carefully crafted with a lot of precision so all the modules can fit. As you can see, the work of the software developer is more like that a craftsman making a unique and original piece, like the suit made especially for your body measurements by a tailor.

A lot of managers complain because of the poor quality of the job done by some developers. But a lot of it has to do more with the way they manage the team. You can hurry a guy who is bending pipes to do a faster job to recover time, but that is impossible to do when developing software since you need to figure out the instructions to be coded. That is why the managers that give preference to the schedule over the quality always get shot in the foot and they blindly blame the team over that poor decisions.

So, to better manage a software project you must be very involved with how the developers actually work and must implement processes. It doesn’t matter if they are simple processes.

In this day, everybody understands the importance of coding testing and they think this is Quality Assurance. But an old practice of Quality Assurance that has been forgotten is ensuring the quality of the development process. As Watts Humphrey says: "The quality of the software is directly proportional to the quality of the process."

But that will be a subject to another post.

[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.

software development ,production ,development process ,management ,agile

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}