Episode 2: You’re Building the Wrong (and probably buggy) Software
The Gap in Programming/Coding tutorials: A Software Development Series
Every software starts with a customer’s idea, requirements, or specifications 💡.
The term customer and client will be used interchangeably.
Clients have two major concerns
- How much it will cost (episode 7).
- How long it will take (episode 4).
After agreeing with the customer (or coming with an estimate) on time and cost, most programmers dash to code (without a plan).
Note from the editors:
Unless you are creating software for yourself, skip to episode 4. Otherwise, keep reading.
This big bang approach has risks
- building what you think the customer wants.
- there is no feedback until (or think that) you are finished.
Wait a minute 🤔,
The client has shared detailed requirements, the only problem is time and cost estimation.
True, it’s clear what to you have to do in such a situation, but how you do it is crucial. Many of us are (often) poor communicators, rarely keep the client updated, and do not follow a proven methodology.
You will start a project without a plan (a common rookie mistake) and end up with a lot of bugs. Other times, you might apply a methodology that you quickly realized will not result in what the client wants.
Ultimately, you have to restart. At this point, you’re afraid to inform the client of the (actual) status. You may end up giving vague progress indicators like, “I am progressing well” or “we are on track” while in truth you are not (the planning episode cannot come sooner).
The coder rarely shares incremental results or actual progress with the client until the end of the project when they deliver what they assume the client wanted.
Then Bang!
The customer does not like the results, or worse, you’re still debugging.
Debugging is the process of finding and resolving errors, or bugs, in a software system or code.
The customer (always) gets what they want
If the customer does not like what you’ve or are building, you’ll have to do some rework.
Sometimes, you might not like the change and have a lengthy explanation against change. Other times, the solution you have delivered works (well, from your perspective at least).
However, if the client wants the software done differently, good luck trying to change their mind. Eventually, you’ll end up doing what the client wants, even if you do not approve of it (Sigh if you have been here).
How do you know what the customer wants?
Simply ask 😏. If you’re not sure what they want, or if you think you’re sure, always ask for clarification.
Do not guess, think, or assume! You need to keep the customer in the loop to make sure you’re on the right path.
Great Software = What is needed + On time + on Budget
How do I deliver what is needed?
Iteration — asking questions and getting feedback from the customer through the development. You’ll have to normalize continuously (not every minute though) communicating with the client.
How to iterate you ask? Join me on the next episode!