Hint, it’s not the actual act of coding your application.
This may sound a little strange, but I’ve seen enough failed software projects (including my very own) to gain some insight as to why a lot of projects run by by very sharp and talented developers, go awry.
It really has nothing at all to do with the actual act of coding or the programming language or technical stack. Pretty much any modern day programming language these days has more than enough capability to let you tackle the most complex kind of software development you throw at it.
So if it’s not the technical side of software development that’s the most important, what is it?
UNDERSTANDING THE PROJECT REQUIREMENTS
It sounds simple enough, but you’d be surprised by how often this gets ignored by developers.
As a software developer, I can actually understand why this happens to a lot of other developers. We software coders CODE. We enjoy hunkering down in front of a computer, put on our favorite music playlists (I’m looking at you AC/DC!) and start pounding our fingers on the keyboard and watch the computer code fly onto the screen.
As a result, sometimes (I speak for myself, but I’m betting other developers share the same trait) we get a little OVEREAGER to code, even when we don’t have a proper understanding of what we’re trying to build!
There was this school exercise I still remember to this day, that illustrates the challenge of relaying information from one person to another.
My classroom teacher would whisper something to a student, who was supposed to relay everything, word for word, the teacher said, to the student next to him. The student next to him would listen to everything the first student thought he heard from the teacher, and then tell the student next to him what the first student had said. And the exercise would continue until the last student in the exercise would say out loud what he thought the teacher originally whispered to the first student.
What the teacher originally said and what the last student thought the teacher had said, were so different from each other, that it was actually laugh out loud funny to hear. And it didn’t take long for the original information from the teacher to morph into something way off base.
The lesson I learned is it can be very challenging to listen to what someone has to say.
There are many reasons why a software project can fail. Some factors can be completely outside the control of the software development team. The project can be yanked out from underneath you by upper management due to budget concerns. Or maybe the customer changes their mind about a major feature they need, and they have to go back to the drawing board and give you new requirements. These kinds of changes happen all the time.
But some software project failures happen because we software developers fail to understand the customer’s requirements.
It used to happen to myself a lot more when I was younger and had less patience about gathering software project requirements. I would impatiently want to get in front of my keyboard and start coding away.
If I had only remembered my class exercise about the importance of listening! It takes concentrated effort to truly listen and understand what your customer is trying to convey to you.
In the case of a software team practicing traditional waterfall development methodology, it means listening to what the project manager, business analyst and perhaps the actual customer, has to say.
In the case of agile/scrum, it’s about listening to your product owner’s needs and requirements.
Not only listen, but actively asking enough questions. Who is the intended audience of this application? WHY is this application important in the first place? Is it trying to replace an older application, or some painful manual work process that needs automation?
Sometimes even the customer is unsure about certain features and functionality they want in their application. It’s your job, as the developer, to coax the answers out of them.
During this process of project requirements gathering, it’s also important, as the developer to get as many answers as you can about how the business domain of the application works.
Sometimes inspiration can strike when you ferret out information about the business domain where your application will live. Perhaps you can find an opportunity to find some automation in some manual process, as the customer describes some business related workflow process.
These days, I often ask my customer for walkthroughs of their current business workflows. If the customer is asking for a new application that will automate some former manual process, such as manually entering sales order information on a sheet of paper, then sit down with the customer and ask them to show you exactly how that is done.
Then ask where that information goes. That is, does the customer send it to a salesperson? Or does it get reviewed first by management? What is the complete end to end workflow of that sales order? WHO else in the company is involved in that process?
Having a CLEAR UNDERSTANDING of the business workflow related to your application, is in my opinion, the number one most important aspect of software analysis.
The only way you’ll have any chance of success in delivering what your customer is asking for, is “walking in their shoes”. You need to think like the customer.
Keep in mind, all this analysis has NOTHING to do with actual coding. You haven’t yet written a single line of code. Code comes later. You may not even have decided on the particular mix of technology stack to go with. Or programming language(s). Or any of the other myriad of technological decisions you’ll have to make when you’re ready to actually start coding.
Is all this analysis really worth doing? I personally find that setting aside time for this research and analysis pays off in spades down the road when you’re actually ready to get into the actual implementation phase of your project.
I personally work in an agile scrum team and whenever our team comes across a new user story requirement that we don’t have much knowledge or experience in, we create a new “research spike” story. It’s basically a pure research and analysis task to gain more insight and knowledge about whatever piece of the project requirements we don’t know much about.
This can include conversations with subject matter experts, your product owner, software architects, any of the business folk that have a business stake in your project.
I also find it helpful to keep a wiki dedicated to hold the research and findings of our research spike user story.
When you have enough understanding of the business domain you are working in, the IMPLEMENTATION piece of the project becomes MUCH easier to handle. You can also create business oriented acceptance tests, which can help verify that whatever technical implementation you end up with, will deliver the original business requirements of your project.
Does a clear and firm understanding of the business requirements of your project guarantee success of your actual implementation?
Of course not. There’s still the other half of software development, which of course, is the actual coding! And lots of potential things can go wrong there. Perhaps choosing the wrong technology stack. Or flaws in the actual software code.
But without a firm foundation of understanding of the project requirements, you’ve already doomed the success of your project. And no amount of code debugging or code refactoring is worth a hill of beans until you you’ve got that foundation of understanding down first.