Why Is Software So Difficult?
Software development projects are one of the most notoriously mis-understood and incorrectly managed of all the common processes used throughout the business world.
There are a number of reasons for software projects being classified as a disastor so often. Software often is solving a complex problem that unfortunately can’t be seen.
Perhaps the worst problem with software projects are the diverging expectations between developers and users.
Software is Not Regulated
Another reason software projects are capable of running so far amok is the fact that the software industry is not regulated (nor do I think it should be).
Please note, I am not in favor of external regulation, I am, however a huge advocate of transparency, education, communication and following industry Best Practices.
For people that do not really understand how software works, it can be a nightmare trying to figure out what needs to be, who the best people for the job are, etc.
After all, who can you trust?
There are no laws or regulations that will ensure that the outcome of your software project will be what you wanted.
As developers, managers and users, we all want:
To Develop the Correct Software, Correctly.
There Are Many ways to Skin a Cat
While it is true that there is no single correct way to do software, it is also true there are many ways to do software incorrectly.
Software development is largely a collection of Best Practices which are heavily influenced by the application you are building, the “tech stack(s)” being used and the specific culture of your organization.
We are here, to identify the good practices and renounce the bad practices.
The lessons and processes captured here are meant to be timeless and translate well across industries, development styles and “tech stacks”.
Bottom line: we want to employ Just Enough Process to learn to run stress free, successful software development projects. Software projects that I like to call
Predictable.
The lack of predictability can be quickly identified with a disconnect between the expectations of the user and the activities of the development team. The worst enemy of predictability is a …
Communication Breakdown
Most of these problems are rooted in mis-understanding, mis-communications or just missed assumptions.
For example, let’s say a user asks a developer for a “Database of Shoes”. Many conflicting ideas of what exactly does a Database mean anyway?
What the User Thinks
The user likely think they are going to get an entire usable Database with typical functionality like entering data with forms, being able to perform complex searches and apply sophisticated filters to present only the shoe data they need.
What the Developer Thinks
The developer on the otherhand may be interpreting the task more literally.
She may be thinking: I’ll give the user a JSON file with a bunch of shoes for the database. We can add things like entry forms and search filters in the future.
Who is Right?
In reality, both of these parties have a legitimate definition of a Database depending on the context and the community you are talking to.
There lie’s the rub, we have two communities: users and developers, who have two different mindsets (I want …) and (I can just …) which start to diverge and the conflict begins.
When does resolution come?
Projects that start to diverge can be put back on path as soon as the divergence has been identified. When there is regular, meaningful communication between all parties divergences are small and resetting is quick.
If there are large gaps in communication between interested parties, then the divergence between what is developed vs. what was wanted can grow large, even beyond the point of recovery.
Agile software development, in it’s truest form provides the means to detect and stop a software project that is about to take a left turn before it actually does.
Death Signs of a Software Project
Here are three of the biggest signs a Software Project is headed for disastor:
- Developers Hording Code - not letting users see it
- Users not committed to the succuss of the project - developers get no feedback from actually running code.
- Feature creep - Users don’t engage and developers don’t expose
Feature creep is really a combination of 1&2 above. Users avoid the work of actually using the software. Developers avoid the work of making it regularly available for use, testing and scrutiny.
Developers must be ready release software changes frequently an rapidly to a user base that will provide prompt and useful feedback about the new software being release.
If these two things happen, chances of a successful and predictable software project increase significantly.
Best Practices
Let start this journey and figure out how to manage predictable software projects. Whatever the application, technology and industry is, we can be sure
Communication is the foundation of predictability and success.
So, where to start ?