Software development is arguably one of the more contentious areas within Information Technology. No two developers will give you the same estimate and rates vary as much as there are atoms in the known universe. Why is that?
Regardless how much we desire otherwise, software development is not a canned commodity. There are many contributing factors. Most notably is the somewhat surprising fact that software developers are humans. Software developers have had different stimuli within their careers, their training, their experiences and even their personal lives. We have different skillsets and different strengths. We have different passions and driving forces. This is what makes software estimation and software development more of an art form than a science or commodity.
But we can’t blame it all on the human condition. That good old standby “communication” also plays a role. Businesses and Technologists often do not speak the same language which leaves a lot of room for (mis)interpretation. Requirements are often incomplete, because who can think of and anticipate everything far in advance of a software deliverable (and if you know someone who can, please connect with me, because that person has a truly remarkable gift of foresight that could be capitalized upon). Process knowledge is often fragmented across several functions and people.
Life happens. Sometimes work gets in the way of life, but invariably life gets in the way of work. Or more work gets in the way of work. People don’t have the luxury of single threading from one project or task to another. More often than not, we have more than one thing requiring our attention at the same time. Prioritizing, organizing, and managing our time and attention bears forth. Even the best laid project plans succumb to thwarting external influences such as unplanned time off, scope changes, unanticipated complications and so on. Change happens.
Software development is arguably more an art than a science, though we do our best to leverage scientific methods. If only humans were more predictable and skillsets and experience could be commoditized. Many different software development methodologies exist to address these various factors which will be the topic of my next blog post.
How to work with the human element:
1. Understand the background of the people you are working with; their skills, experience, and training
2. Ensure you have someone on your team who can bridge the communication gap between the client and IT
3. Outline communication expectations
a. Cadence: periodic interval
b. Vehicle: email, in person, conference calls, scrums or daily stand up
4. Include relevant people, such as affected process owners
5. Outline what is known ahead of time
6. Set key deliverables
7. Hold each other accountable, but be supportive of interruptions (other work demands or personal) outside of team member’s control