Many times I’ve heard clients or peer developers saying “Let’s use x framework” or “we will need to apply x technology”. The problem most of the times is that there is no prior analysis for the decision its being proposed. It is just because it’s something trendy (and cool) and that’s it. As one of my prior managers frequently said, “Hype and buzzwords are dangerous friends”.
The main question we need to ask is “What’s the problem we are trying to solve?”. It is surprising how frequently we come up with solutions for problems we barely know. We are eager to jump into the fight without knowing the size of the opponent before hand. What if it ends up being a monster instead of the small thingy we thought? Or just the opposite?
When a developer sees a chance of applying in a real project a new technology he likes, it is predictable that he will propose it straightforward. It is something normal, we are always biased. We want a resume with shiny things. But, you won’t create a hole to hang a painting using an industrial drill, will you? This why it is important to know your tools. Using something without knowing the implications just because is cool or new may add some potential problems. Even though they might be small, they need to be at least disclosed so everybody it’s on the same page.
For example let’s say I want to create a small web page to submit something. The client may ask it to be responsive, or maybe I prefer to do it that way because I think it is the best option. But, first we need to know if there will be really different resolutions where the end-users will access from. Maybe the app I’m creating will be used in the standard-size computers of a corporate office, so using Bootstrap won’t add much. Remember that technology is a tool intended to deliver value to the users; if something will make it more complex, slower, etc. it shouldn’t be added/considered.
If you are the one responsible of making the call, there should be always a reason behind. Always ask yourself why. Five times. Also ask, is there an easier way?. As Jason Fried and David Heinemeir Hansson say in their book Rework, “Find a judo solution, one that delivers maximum efficiency with minimum effort”.
All decisions come at a cost, so it is important to make the proper considerations. There is also always a why not; you need to have a clear picture of when something (technology, language, framework, etc) it’s not a good fit. Otherwise you might look like a junior enthusiast instead of a professional software developer.
Be agile, again, focus on the problem and the value you need to provide first. I’ve seen (and participated in) endless discussions about which technology is better and most of the times there is no clear winner out of personal preferences.
[blogoma_blockquote ]
“We need to architect systems first and then decide which standards can support desired system requirements and qualities”
Grace Lewis
[/blogoma_blockquote]
It is not that you can’t use any technology for any problem, but most of the times it is the less important choice. Now, we don’t want to also fall into the so called analysis-parallysis; but first you need to think on what are the tactics and strategy you will follow.
Technology, frameworks, languages are important, but they should be the last part and be identified and selected based on the other goals you want to achieve, unless they are constraints already set. First define (or ask for) your architectural principles, quality attributes, constraints and then make your technology choice.
After that you can decide if it is better to use AngularJS or jQuery, Java or Python, SQLServer or Oracle, ….. you know what I’m talking about.