This is one of the hardest things to get right when we take on a new project: clearly distinguishing what it should do from how it should be done.
The “what” is about requirements, specifications, user stories—anything that helps us understand what the client wants and the problem that needs to be solved.
The “how” is about the technologies that will solve the problem the client has presented. In other words, the how covers everything from the technologies to use and the methodology to the evidence to deliver and where the finished project will be deployed.
There’s tremendous confusion around this distinction, to the point that people force or misuse technologies that are poorly suited to the purpose described in a straightforward specification (or tell a client, “That can’t be done”).
If it’s already difficult to elicit all the requirements at the outset and make sure they’re clearly and thoroughly documented, choosing the how based on all of that is even harder.
How this is managed and the decisions made at this point will largely determine the quality of the delivered project, its final cost, and how easy it is to maintain and evolve. Mistakes at this stage can cause the project to fail completely or force it to be discarded a few years later.
Worst of all, we often confuse objective requirements—whether stated by a client or an intermediary—with the technologies we’d like to use just because, or because they’re the only ones we know well and we don’t want to leave our natural comfort zone.
In software project development, this is a bit like putting the roof on before the foundations: if, before starting a new project of any kind, we’re already saying we’ll build it with a SQL Server database, we’ve started raising walls in the maze that will form during development. Put another way, instead of solving the problem, we’re putting obstacles in our own way.
This isn’t just another mistake—the confusion between what needs to be done and how to do it is a paradigmatic mistake in our profession, whether someone comes into it with one academic degree or another, or without formal training in the field (with no intention of belittling anyone; in the end, what matters is each person’s talent and doing good work).
This classic, textbook mistake is forcing a set of technologies into a solution without first doing the intellectual work of checking whether those technologies are suitable for that kind of project.
In my opinion, we repeatedly fall into this trap for reasons such as:
- Plain laziness: since I know technologies X, Y, or Z better, I won’t bother learning about or exploring other things that might be more appropriate for this project.
- The company’s policy is to use technologies X, no matter what, and that’s the end of the discussion.
- The effort estimate doesn’t allow for a learning curve for new technologies that may be better suited to the work.
- Or worse: I like technology X and want to play with it. Now I have the opportunity, whether or not it’s right for the project I’ve been assigned, so I can finally experiment with it at the expense of my work for the company, even if the result is poor.
In any case, the consequences of skipping this preliminary analysis before sending a development team off to build a new solution are bad, and sometimes catastrophic.
Just in the past year, I’ve seen an initial solution—already running at a large electric utility—thrown away and rebuilt completely with technologies better suited to the situation. This shows that failing to consider this software-related issue when starting a new project has an economic cost someone will have to pay: your own company or your clients (by making your services more expensive and therefore putting you at a competitive disadvantage).
This happens in small companies, but also in those we call large, with enough resources to carry out every risk assessment in the world…
We should always ask—and justify as thoroughly as possible—whether it’s appropriate to use ASP.NET MVC or another web UI framework in the context of a particular project; whether AngularJS or Backbone is a better choice; and whether a relational database (MySQL, SQL Server, and so on) or an unstructured data store (MongoDB, Cassandra, Amazon SimpleDB, Azure Table Storage, and so on) is needed.
Not every technology is right for every kind of project. That sounds obvious, but the way I sometimes see technologies chosen for projects gives me a lot to think about—especially when the motivation comes from the latest trend…
In my opinion, this should be the technical lead’s decision, if there is one, since you can only arrive at an appropriate solution if you have sufficient experience and some knowledge of all the available technologies that might solve a particular project’s needs.
I don’t know whether this is the right approach, but that’s why I like to encourage informal internal sessions within the team I lead. Each team member presents something they’re interested in, whether or not it relates to the projects we manage day to day. We prepare most of these sessions outside working hours, but the result is that we broaden our collective technology knowledge. When something completely new comes our way, we have—how can I put it—a clearer horizon because we’ve had more exposure to a wider range of technologies. Obviously, this takes effort that’s difficult to quantify, but I believe it brings extraordinary intangible value to our work.
In any case, a client will never pay for the learning curve you’d need when starting with a technology you don’t know. This is something that sharply distinguishes our profession from others: if we try to pass that cost on to the client, we’ll be more expensive and therefore less competitive.
All of this is somewhat subtle (because its consequences are hard to measure), but it’s something we have to deal with whether we like it or not. Perhaps if you work at a large company where someone tells you exactly what to do, how to do it, and when, this discussion is irrelevant. But most developers have to face these decisions all the time.