When I started out in my professional software development career, I naively thought computer programming was all about the programming. That is, the actual act of hunkering down in front of a keyboard and typing away furiously until you ended up with gobs and gobs of source code on the screen.
After all, the more code you write, the more productive you are, right? Isn’t a novelist more productive when she writes more words for her novel? Words, source code, what’s the difference, it’s all essentially the same, correct?
My first software manager even half-joked that he measured our productivity by the number of lines of code we wrote a day! Come to think of it, maybe he wasn’t joking at all!
I think that most, if not all software developers who start out in their career, share the same sort of sentiment … when i first started out, EVERYTHING was a brand new learning experience.
Just seeing your code running and doing what you wanted it to do, was a head rush in of itself. It was exciting seeing something you created out of thin air, actually doing exactly what you wanted it do!
And boy, oh boy, did I get positively excited about writing code! Mountains and mountains and reams and reams of code! I naively did believe that just jumping onto the keyboard and start coding away to solve a particular problem was the best way at attacking a problem.
My very first professional programming job title was “Programmer/Analyst”, but I never understood at the time why they tacked on the word “Analyst” at the end … after all, I was a bona fide software programmer and my job was to write as much code as I could to get the job done, correct?
Oh the salad days of my youth!
I tackled my early projects with the gusto of an undisciplined developer. I didn’t put much effort into actually analyzing the requirements of a new project.
Sure, I would have an initial meeting with the customer of the project. But I didn’t really ask for follow up meetings, to get more detailed information about the requirements.
Hey, I was the expert on all the technical stuff! Why would I need to waste time and effort trying to understand what the customer wanted? After all, the customer typically doesn’t know a lick about computer code! That’s MY job! Shouldn’t I be the one calling the shots?
I wrote lots of lots of code for my early customers. And I was having a ball doing what I loved.
That is, until I noticed I had to REDO a lot of the work for those same early projects. Not by choice, mind you.
But the customers I served, would either come back to me, or let my manager know that what I implemented, didn’t really give the customers what they really wanted.
I did a lot of INTERPRETATION of the customer’s project requirements, by making lots of assumptions and educated guesses on what I thought the customer really wanted in their application.
Unfortunately, a lot of those assumptions and educated guesses turned out to be dead wrong. As a professional software developer, your success depends on the success of the customers you serve, whether they’re internal customers of the company you work for, or the external customers that drive revenue and profit for your company.
You simply can’t hide underneath a rock and hope a program fixes itself. Or rely on the technical support team to resolve any issues that originated from your software code.
Even if customer issues are first dealt with by a customer service or tech support team, if they can’t immediately resolved the issue at their level, they will continue to escalate the issue at a higher and higher level until it will eventually come back to YOU, the original developer.
I can’t stress enough just how tough it is to go back to an application and try to find a bug or refactor some original functionality.
As strange as it may sound, even if you’re the original software developer who’s expected to go back to your original program to fix a bug or add an enhancement, it’s still very difficult to remember what you originally did. Even if you liberally commented your source code and created great wiki documentation that describes what the application does, it’s still going to take time for you to get back up to speed.
Computer source code is not easy to read. Even if you’re a seasoned developer. Source code is the language that computers can easily understand. Humans are another matter.
Software developers are essentially “language translators” between a computer and the customer which the software program is supposed to serve.
Believe me when I say it can even be difficult to remember how a particular set of source code for an application works, if only a day or two has gone by since the last time you’ve worked with it!
I mention this because in the context of being a software developer responsible for finding and fixing bugs in an application, it’s tough enough trying to recall how to fix your OWN application, but doubly hard trying to figure out how someone else’s application works to fix their software defects and bugs.
With this in mind, it pays to put far more effort into being the “analyst” part of a programmer/analyst.
After years of hard won experience and learning things the hard way, I’ve finally gotten to the point where I’ve concluded that jumping into coding while early on in a project, is a recipe for project failure.
I almost fell into my same old mistakes with a “simple enhancement” to an existing software application which my development team has owned and maintained over a significant number of years.
Based on a single conversation and initial e-mail from my development manager to assign me to an enhancement to the application I was responsible for, I went back to my old bad habits and almost jumped into immediately coding the enhancement my manager desired.
Fortunately, my memories of all the early pains and suffering I went though in my early professional career suddenly flooded back … all the rework, the struggle with figuring out how the current functionality of the application behaved.
And most importantly, not putting enough ANALYSIS WORK into the PROJECT REQUIREMENTS.
I went back to the original e-mail from my manager, and thought about his initial description of the enhancement.
There were a lot of unknowns I still didn’t understand. Like what additional back end services would this new enhancement require. What about changes, if any, to the user interface layer that the customer actually interacts with? And any new external APIs and library components I would need to hook into, to provide this enhanced functionality?
It’s easy to fall into the trap of immediately getting into coding a solution to a problem. Especially when you’re under deadline, your manager is begging you to get the job done as soon as possible, and you have the impression it’s not a very big enhancement.
But spending the extra time and effort to truly understand what you are really trying to accomplish will pay itself off in spades. The more knowledge and understanding you acquire about the requirements of a project, the better the chance that what you will ultimately provide as a software deliverable, actually does what the customer originally wants.
This may sound overly simplistic and obvious to some, but in fact, the analysis phase of a project can be the most difficult and prone to misinterpretation.
In my home town city of Portland, Oregon, the city government has been suffering through some bad publicity trying to come up with a new software system to upgrade a formerly paper based permit system, into a modern digital system that different city departments could use and easily share information.
It was supposed to save the city millions of dollars in the long run by automating former manual processes and speeding up the process of serving up permits in a faster and more efficient way.
Unfortunately, the project has been mired down by late schedules and underestimation of budget costs for completing the project. The project will require additional tax funded monies and additional people and technical resources in order to provide the original desired functionality.
The article is an interesting read that ultimately reveals that not enough time and effort was put early on in the early phase of the project to nail down project requirements. Or even UNDERSTAND what was expected in the project.
No amount of technology and whiz bang software will help a project, if the requirements are not clearly understood. Obviously not enough analysis was performed. It’s far cheaper spending the extra time and effort to understanding the project requirements, versus realizing you didn’t understand the project requirements and implemented something that will far more time and resources to correct by the software development team.
If I had my way, I think I would want all official “programmer analyst” job titles to read “analyst programmers”.