Over the course of the last couple of years, I’ve been working on a lot of different projects where we initially had to make some technology decisions on what development ecosystem to use. By development ecosystem I refer to the sum of programming language, IDE and API (libraries) needed. In most of the discussions it was typically a debate based on the individuals personal preferences and what they’ve used to work with, rather than a non-biased discussion based on what problem we’re trying to solve.
Personally I don’t think the best approach to select any specific implementation technology is to let it be based on personal preferences, albeit I do concur, that sometimes that will get you there faster. There’s a lot of factors that needs to be taken into consideration prior to selecting specific technologies. One of the more important things to take into consideration is the preferences of your customer base. E.g. trying to shove a Java based solution down the throat of a .NET fixated customer base or vice versa – isn’t the most sensible thing to do, or at least not the smartest. It may be easier to chose technology based on the preferences of your customer base. From a selling perspective, by doing so, you remove one obstacle in the sales or adoption cycle, whatever commercial model you’re using.
The next problem in the personal-bias-decision-process (PBDP) is that the decision process becomes based on the individual decisions makers personal bias and technology comfort zone. So rather than evaluating tools and technology in the context of the task, I’ve encountered and witnessed a fair amount, or more precise, I’ve predominately seen people doing it the other way around. They evaluate in the context of their comfort zone when it comes to technology and tools.
Personally I find this approach somewhat disturbing, as there’s a risk you end up utilizing the wrong tools for the wrong tasks – like a carpenter trying to use a chainsaw to create a replica of a renaissance chair. But what really throws me off, is that we as software engineers are obligated to propose the best tooling for the task to facilitate speed to market, customer adoption and fast feature turnaround.
We as engineers should always be looking for new and better ways to develop software, researching new technologies, tools and languages to keep track of what’s going on in our field, to be able to recommend the appropriate tools and technology for a given task. We should see an opportunity to use new tools as a way to broaden our experience rather than being hampered by our comfort zone.
#programming #tools
Claus Jepsen 
Good to see you posting. Very good points, it’s always difficult to deliver the best available product to the customers when you have tight time constraints. But it can also be a challenge to train people on a new system, a lot of times they are resistant to change when they’re so accustomed to their old ways. That makes the transition all that much harder. Especially for small companies, one small business owner abandoned the software saying that he didn’t have time to use it. His process flow was not the best though, so it was a personal thing, I think. At the time I was not the developer, I was working more on the administrative side. Business politics also play a part sometimes too. I was in management and we were trying to merge two companies together and start a new system, and the other company was fighting the change all the way through. I think our jobs would be easier if people were more open to change.
Hello D,
You’re spot on with your last comment, ability to change. Anything discussed is down to a of for change, which is a very human thing. It’s about what you’re comfortable doing, to retain your value. The fear is that if you need to learn new stuff, you may lose value, as there good be others out there better at this new “stuff”. Also people like to think they invest in themselves when piling on experience within the same are. That’s old world thinking. New world is the ability to transition between different technologies, different domains and be able to pick up fast. And you show that by learning new technologies and tools. When I hire I don’t look for people that’s been doing the same for 10+ years using the same technologies, I look for people that shows ability to change and grasp new technologies and tools.
That’s a really good point, that we all need to stay progressive. I am following your advice of learning new programming languages. It’s funny how CMMI levels two to three is developing a mature process and level five is about optimizing that process. I think that transition to five can be difficult and may not happen for quite a few companies. In business there is a life cylcle, and once a mature company is stagnant it won’t be long before it’s demise. But there are companies that never get past year one, it’s just a matter of a balancing act establish processes and remain in constant evolution.
I’m really glad when you post, I get to think more about development.
Abandoning my usual meandering writing style, here are a few bullet points on the subject:
– It is more important to know how to do many things in a single language than how to do the same thing in many languages.
– If someone claims to have experience with many languages and/or technologies, the figure of speech “Jack of all trades, master of none” comes to mind.
– Knowing languages and technologies at different abstraction levels is more important than knowing different languages and technologies at the same abstraction level. The value of knowing what goes on at the level just below the one you are normally working at cannot be overestimated.
– You can lead a horse to water, but you cannot make it drink: A developer switching to a new language might still try to use the new language as if it was his or her old language.
– Languages are becoming less important compared to frameworks. There is plenty of scope for learning new things every day or week, even when staying with the same framework for years. In fact, these days it can be hard even to keep up. Staying with the same ecosystem for a long time is not necessarily an indication of stagnation, but having been tasked with maintaining a limited set of functions in a highly specialized domain could be.
– Being willing to switch to a different language/technology is not the same as being able to.
– Yes, there are those who like to stay within their comfort zone, but that does not automatically mean that they wrong when advocating their favorite tools. On the other side of the coin, we find those developers who just like to play with new toys – and those can be just as dangerous as the ones who like to stick with the tried and true.
– If the question is between having a product or not, everything else is irrelevant.
– Pick the right tool for the task – and pick the right developer for the tool. The same developer who is competent in one ecosystem might be a total disaster in another. Does that mean this developer should abandon what he does best and start driving a truck instead?
– Any developer who is any good will pull in any peripheral technologies as required to do a particular job if the core framework falls short, but will not necessarily list these technologies to inflate his or her CV.
– Change is important, even just for change’s sake, if nothing else but to increase the capacity for change. But do not underestimate the value of in-depth knowledge.
…
Have I used the same ecosystem for years? Sure!
Am I resistant to change? As long as I feel that I am learning new things every day, I do not really think that I am.
I agree with most of what is said in this blog post, but there are nuances to every topic.