Marcin Biegała

3 minute read

The pace in IT is unbelievable.
Sometimes I have a feeling that not reading my RSS/twitter/any other feed over the weekend would make me miss 2 new languages, 4 acronyms, 14 new javascript libraries and a lot of drama.
But that pace is not reflected in actual projects being run in IT.
We left simple html webpages and js applets long behind us. Software development is serious stuff now. And it became a vital point of many companies. I know projects planned for years ahead. Those that have version 1.0 six months forward and then plans for features that would need another 2 years of development.
If that would be a javascript project, 6 months means about 2 new package managers and 4 view rendering libraries that go ‘mainstream’.
Does it mean we need to use those package managers or rendering libs?
Would you do that in your project? Would you rewrite 4 months of work just because there is a new library?
I guess not. Otherwise no web app would ever be finished.
But….
As a developer, especially one that looks for new job/project most probably you’re on the opposite side of the deal. You want the newest tech, newest libraries, languages, versions. Now everything else gets this magic ‘legacy’ label. You won’t touch anything that’s not hot on Reddit or was posted to HackerNews more than a month ago. And that makes me cringe a bit.
Don’t get me wrong, I like new and shiny too. I try new languages, new libraries, experiment with patterns. But I do that where I can. In my private code, doing some small projects or trying to do a proof of concept if my customer is interested in results. But I don’t force my clients to use bleeding edge technologies. I like to think about software developers as problem solvers rather than code monkeys. I believe people paying for my time are more keen on results, implemented features and stable software than buzzwords and high version numbers.
People paying us have a problem to solve and trust us to solve it in the most effective way. Does it mean we should all stay on Windows2000 and write apps using WinForms and classic ASP? Definitely not.
What I mean is as developers we need to be ‘partners’ with our customers or product owners. If you really think changing some technology in a project will make a huge impact - tell your product owner, discuss that with your architect, I believe you will be heard. But if you want to change your project’s plans and timelines just because a new version of X came out, I don’t predict success there.
Just to picture this.
If you’re working with Silverlight right now, there are lots of reasons to change tech right away with a benefit for the project (because Silverlight is not being supported by M$ or modern browsers). But let’s take Angular 1.x for example. Do I need to force my customer to upgrade to Angular2(4)? Will benefits justify all the work needed to be done here? I guess not.

So be a partner for whoever pays you.
Don’t force technology choices because ‘there is new version’. Try to understand what would be the impact on the project. Do you want this X tech because it’s good for the project or because you find it cool?

comments powered by Disqus