When we take on a new kind of project that uses technologies we don’t fully understand—or that we’re using for the first time in a professional project—it’s often a mistake to make our first project with those technologies the very one we’re delivering to a client. Without knowing it, the client becomes the provider’s guinea pig while the provider decides, wisely or not, which frameworks and libraries are best for that kind of project, assuming that evaluation has even taken place.
The worst case is when someone chooses a particular technology stack not because it objectively suits that specific project and its nature, but simply on a whim, or because it seems like a wonderful opportunity to learn on the job what they don’t have time to learn outside of it… I’ve seen this several times, and it’s too tempting not to talk about. Someone who gives in to that temptation may call themselves a software developer, but certainly not a professional one. Sometimes software developers seem to play at work instead of trying to do their jobs as professionally as possible.
The important thing is to be able to select the best technologies for a project based on its nature and requirements. We need to be completely objective about this and not let trends or personal preferences sway us.
Not long ago, I saw a client have to throw away—literally—a device-communications front-end that had initially been built with a popular, professional CMS (which, by the way, I like a lot and which this website is built with…), but which was completely unsuitable for that project. I suspect that choice was driven either by the developer’s personal preference (without assessing future risks or considering whether it was appropriate for the project) or by a decision to force the use of that CMS out of sheer reluctance to learn more suitable technologies. Making this choice takes considerable experience and some familiarity with a variety of tools and technologies—enough to make an informed decision, without veering into technological dilettantism, the subject of one of the chapters in The Programmer’s Black Book.
If we’ve chosen a stack of libraries and technologies that we don’t know in depth but need to use for a new project, we may make the mistake of simply starting the project right away. If we do, every mistake we make as newcomers to those technologies will happen in a client’s project!
It’s easy to miss the best practices associated with libraries or frameworks we haven’t used enough before, to be unaware of their tips and tricks, and to lack the skills to handle even the most basic scenarios with those new technologies. That will create technical debt in the project, and it will most certainly come back to haunt us.
So what should we do?
Before we start writing production code, we should spend some time building a prototype that tackles—or lets us learn about—the project’s most important and critical elements. Once we’ve worked those elements out, we’ll know how to structure and integrate them better into the final project we deliver to the client.
In the end, we learn through a great deal of trial and error. That’s why we can’t afford to make rookie mistakes in a final project for a client: first, we need to know the chosen technologies well enough. The best way to do that is to build a simple prototype that clears up our fundamental questions.
Reading a selection of books about those technologies is equally essential: reading a book means learning from other people’s experience. There’s nothing worse than learning something new by Googling and browsing forums to solve isolated problems; that keeps us from understanding a framework or library as a whole, including its particular design philosophy—which we need to understand in order to use it properly.
The time spent both learning and prototyping the solution isn’t an expense, but a genuine investment. The final solution for the client will be delivered faster because we know the technologies well enough. And if we use that time to learn from quality books and resources, we’ll also deepen our professional knowledge for the future.