When working on a project, the question comes up:
“How do I decide what to use?”
Now this can translate to what programming language, what persistent data storage, what framework, what third party tools or plugins to name a few. These questions sometimes get labeled under “architecture” or “design”, but really these are decisions we all have to make everyday.
So how do I decide?
Well there isn’t a simple answer. What? It’s simple you say? Use the best tool for the job? I’ve heard this before and it can technically be accurate, but I’m not sure people know how to determine this.
Consider existing expertise. Are you working on this alone or with a team? Is the “best tool for the job” already an existing expertise? If not, there is a risk associated with using the unknown, which could lead project delays or other delivery failures.
Consider the true requirements. Depending on the requirements, a specific tool or technology may be better suited. With frameworks do you need simple common components and methods or a robust MVC framework? With persistent data storage, do you need heavy relational queries or simple data storage?
Consider the project’s inherent risks. Is there a tight deadline? Is management really behind the project’s success? Is there a reasonably qualified team ready to make this happen? I don’t claim having to consider these things is ideal, however if your primary goal is to successfully launch (and it better be), then I suggest you take these things into consideration.
Consider maintenance. How long will this project be expected to run? What kind of functionality are they expecting in the future? What resources (manpower, expertise, money) will be available to work on this when it goes into maintenance mode? This can be a slippery slope, and could even be categorized as premature optimization, but keep in mind project success is not only defined by what launches on day one.
In the end, it is all about risk and what you can do to reduce chance of failure. Every one of the aspects I’ve asked you to consider can either make a project more or less risky. Now I’m not suggesting always play it safe, or always look for the easiest route. I am suggesting that you put thought into it and know how these decisions impact the project’s risk.
We’ve looked at some of the ways on HOW to decide, but one could spend as much effort asking WHEN. Maybe we will look at that next.
