Don’t Just Code, Solve Problems
If you’ve been involved with software projects for some time, some of these scenarios may seem familiar to you:
- Scenario 1: Your team is writing a piece of software for a client. The client decides they want a new feature included. The client talks to you about it and it’s obviously a complex and expensive new feature, but they absolutely want it. You agree to do it and your team gets to work. It gets done on time and within budget, your client is thrilled.
But a few months later it turns out that nobody in your client’s team is actually using that new feature. Instead, they achieve the same task using another process, which is much faster for them.
- Scenario 2: Your team is working on a specific module that’s exposing some tabular data through an API. It’s a fairly simple and straightforward project — you take some Excel files from a network share, parse them, store the data and expose it in a certain way. Your team uses the latest development tools and they are all keen on development best practices. The code is tested, reviewed, validated and continuously integrated — it’s the simplest, most robust, secure and efficient solution you can deliver and the whole team is proud of it.
But after it’s delivered, it turns out nobody in your client’s team is actually using the API. Instead, they were simply going for the Excel files, because those files didn’t need them to enter a username and a password, whereas your API did.
- Scenario 3: Your team is contracted to develop a batch automation module. Your team is strong in Linux and, since batch scripts are perfect for automation, you know what you have to do. Several batch scripts and a few cryptic cron expressions later, you have a working solution. It’s delivered, installed and configured. Everything looks good.
But one thing that wasn’t on your radar is that the client’s entire IT Infrastructure is based on Windows. Which means their tech team is trained in Windows. Which means none of them can actually maintain the scripts you delivered. They only agreed to it after you told them that it can also run on Windows, using cygwin. So they treat your automation module as a black box. A few months later they stop using it and create their own solution using Powershell and Windows Scheduled Tasks, because they’re more familiar with those.
Now, all these projects were delivered on time and according to spec. But were they really successful?
You could argue that yes they were. Someone was hired to do a job and they did it.
But if you look at it from the client’s perspective, these projects didn’t actually solve their problem. In fact, it cost them time and money and in the end, they still had the original problem on their hands.
Do you think these clients would contact the same team for other projects they have? Do you think they’d give them recommendations or testimonials?
Whose fault is it?
Ok so what exactly happened here? And why? And whose fault is it?
I came up with these example scenarios to highlight the flawed dynamics in communication that often cause software rollouts to flop.
As a business minded developer who has just experienced such a flop, the instinct is to blame the client, while the client will be inclined to blame the developers.
Ultimately, the client has to be very communicative and open about what they really need, and not just dream up some project requirements and then look for the cheapest vendor who can deliver them.
At the same time, the developer needs to be sensitive to the real needs and circumstances of the client while explaining the scope of the new systems they could potentially create.
It takes two to tango. A truly successful project is team work.
Perhaps instead of “whose fault it is?” a more useful question is — How can such a problem be avoided? What can I do to avoid this happening in my projects?
What they want vs. what they need
Before we look into that, it’s good to remember one thing.
What your client wants and what they need can often be different things.
What they need is a real solution they can use to solve a real problem they have.
What they want is usually the way they imagine they can meet their need. This is influenced by many things, including their personal preferences, business constraints, company culture, project timeline, budget, legal compliance, data protection laws, and so on.
And what they want is what typically ends up in the project spec, burying what they need under several layers of constraints and requirements, some of which are actually being counter-productive to their original goal.
For a truly successful project, you have to give them what they want, but also what they need.
Understand the problem you’re solving first
This brings us to the solution for these kinds of problems.
It’s a way of approaching your work that is completely in your control. It has nothing to do with your role in the team, in fact you may be far away from a decision making role, and still benefit from integrating this approach in your day to day work.
It comes down to this:
Before you jump into the details, strive to understand the problem you’re solving.
- In programmer-speak: Don’t just code, solve problems.
- In designer-speak: Don’t just design, solve problems.
If your goal is to just “implement the interface”, or come up with a solution for the spec you’re given, you may be putting yourself at risk of creating disposable solutions for whoever is giving you those specs. In a way, you are commoditizing yourself.
In reality, however, because you are immersed in your subject matter, working everyday with it and being constantly exposed to it, you likely have a good sense of what’s possible, what’s a good idea (good design, easy to maintain, robust, etc) and what’s a bad idea (pitfalls, unintended side-effects, etc) of a particular implementation.
By simply implementing what they ask of you with no questions asked, you may be depriving your team or your client of your expert opinion and insights about the best way to move forward.
If your goal is to solve a problem with your work, you will first want to understand the problem. Once it’s understood, you are then in a better position to choose the best way to tackle it, or at least in a position to recommend alternatives, if you see any better ones.
Worst case, you will have gained a deeper understanding of the project and can make more meaningful contributions in future design and architecture discussions. And who knows maybe by looking at the problem, you can come up with a few better solutions which the Project Manager or even the client have completely overlooked.
High quality clients who know how to appreciate this will recognize the extra value you’re bringing and will know that they won’t get it if they go for the cheapest vendor possible. And even if they don’t recognize this, you will have played your role in making the project truly successful.
Now, I’m not arguing that “just coding the spec” is bad, or that you should avoid it. I’m not saying “never trust the client, because they don’t know what they’re asking for”. I’m not saying “whoever designed the specs doesn’t really understand what’s going on”. I am not saying there is no value in trusting others to do their job and you focusing on yours.
On the contrary, start by assuming they did a great job and that the specs or requirements are solid. But at the same time, cultivate a sense of curiosity about the bigger picture. When it’s possible and reasonable, aim to understand more of the problem you’re supposed to be solving with your work, before you dive into the nitty gritty.
How to do it
Now that we know what the “don’t just code, solve problems” mindset is and what it can do for our project, let’s look at a few ways this might look like in practice.
Here are a few questions you can try to ask yourself the next time you get an assignment or a project:
- What is the requestor trying to achieve?
- Are there other ways to achieve their end that are perhaps faster / cheaper / more effective?
- Is the solution they asked for really the best solution there is, given the circumstances? (Project constraints, etc)
- How are they currently dealing with their problem?
- If we’d go with a specific approach, what side-effects are there? What is impacted by the approach? Are they aware of the potential impacts?
- Would going for a given solution negatively affect any other ongoing request from the client? (e.g. Is it working against other things they requested)
- Is the client aware of how the proposed changes would look like in real life? Are they aware of any drawbacks of the solution?
Depending on your role in the team, you may not get access to the people who can give you these answers.
No problem. There are probably others in your team who have thought of this already. So simply talk to your colleagues about this, or to your Project Manager, when you get the chance.
Engage in open discussion with your team about your misgivings. If you have any reservation about your team's current approach, share your thoughts and give them alternatives. If you see better ways to do it, again, share the other ways that you see. It might turn out there are good reasons to not go for those alternatives — or perhaps they might like and support your ideas.
Systemic obstacles to be aware of
Once you start adopting this mindset in practice, you may notice there are a few dynamics working against you.
Let’s look at two of them, so you get an idea what to expect.
- First one: Understanding the bigger picture may not be what you are paid to do.
Depending on the project setup and on your role, you may be expected to do what’s asked of you, and nothing more. No asking questions, no open discussions with your team.
This means that if you want to do it, you may have to do this on your own time (for example during lunch break). This is probably non-billable work.
- Second one: Depending on your role, people may not expect this of you.
Unless you’re in a leadership or a senior role, it’s likely that nobody will expect this from you, which means it’s easy to get complacent.
Solutions over code
Now, with this in mind, use your best judgement to decide when it makes sense to invest time in focusing on solutions before code.
One the one hand, it may be too difficult and unrealistic to understand what problem the client is trying to solve with your company’s main project.
Whatever your real opinion about the JS library situation, set it aside for a moment and assume your team lead made a good decision. At the same time, just out of curiosity, ask someone in your team why they think you haven’t made the switch yet, because as far as you can tell the new framework has benefits A B C. Are there hidden downsides? Are there other good reasons behind this?
No matter what role you have in your team, this approach will bring your project closer to being truly successful.
All it takes is a willingness to ask questions and understand the reason the spec is the way it is. By understanding why it is the way it is, you put yourself in a better position to deliver what your customer truly needs.
In the end, you need to understand the problem you’re solving, before jumping into the details.