I like shiny new things.

It’s pretty universal that we humans are attracted to what is new, the latest-and-greatest, whether out of the likes of curiosity, restlessness, or envy. On top of this is layered a positive feedback cycle – our desire to be part of the group and be in on the topics of conversation – that reinforces the shiniest and most popular objects out there. These can be called fads or trends, and at times they are rightfully the center of attention, but when the reality can’t live up to the expectation then we’ve entered the world of hype.

It has been very clear right from my first days at university that ongoing professional development is essential to maintaining employability, and few industries move as fast software development. Learning about new technologies by playing with them a little is both healthy and important, and gives us an ability to make better choices about them in our professional careers. What I want to focus on, however, is when businesses succumb to the hype.

A business becomes a victim of hype when it adopts a new technology for the sake of adopting it rather than considering whether it adds business value. Lest I sound like a stuck-in-the-mud, there are a myriad of ways that new technologies add business value: they make development faster, more flexible, or interact more smoothly with other enabling products; they may simply have lower costs, whether by virtue of licensing, labour, or lifetime/support costs; they may make the company more attractive to potential employees.

But a new technology also comes with costs: time for individuals to come up to speed with the technology and ecosystem; reduced ability to deliver product and therefore respond to organization needs and competitive threats (Joel Spolsky described rewriting your codebase as the “single worst strategic mistake that any software company can make”); staff turnover as specialists opt to take their existing expertise elsewhere, and replacements require extensive training in the organization’s domain.

Failing to evaluate the costs and benefits of adopting new technology, and/or planning how it is adopted, can seriously damage a business. And yet it still happens, and I posit this is partially to do with our pursuit of the new and shiny, but equally important is the ‘resume factor’, which brings us to the next section…


Hype is driven by recruitment. This is more so in IT than many other industries where professional standards or outright experience tend to carry far more weight. In IT, there remains a prejudice that, because the industry moves so fast, existing practitioners are more likely to be lagging behind the forefront of the industry.

Firstly, this is a poor assumption. Whilst I have seen some individuals flat-line their professional development, the vast majority of people I’ve worked with are doing what they can to keep up with the changes and trends in the industry, both in their work and spare time. Secondly, with experience comes wisdom, and we need that to grow as an industry or we will keep making the same mistakes.

Finally, what behaviour is this going to drive in a mature developer? They’re going to put their weight behind adopting the new technology. As altruistic as we like to try and be, there is always a tension between career needs and business needs, and if there is an opportunity to improve career needs employees are likely to favor that over overall business value because they can move on more easily.

Is Newer Better?

In situations where you’re talking about replacing some part of an existing codebase, then a cost-benefit analysis has to compare the existing technology with the new option(s). And the first question that should come up is, is it better?

I know that sounds both obvious and a little stupid, but hype has a way of making the decision-making process turn a bit stupid at times. Perhaps I should clarify by adding the implied rest of the sentence: is it better for your organization?

At present my web framework of choice is Aurelia. Whilst it isn’t the best known, it has solid support, ongoing development, and just makes things easy. But I need to keep up with what is going on in the industry so I had a play with React, and have subsequently met it more (reading rather than writing) in my current job. Based on my needs, I feel like React is hype. Why (in my eyes)?… The way state and event management works is a big step back from the fairly seamless data-binding of Aurelia or Angular or most non-web UI frameworks, and it requires quite particular data flows for props. Whilst it doesn’t require Redux, I’m not sure I’ve ever seen a job ad for React that doesn’t include Redux, and Redux is massive overkill. I’m not sure I’ve ever needed to centralize state like that in a single page application, nor manage it in a pseudo-CQRS style. If I was building something as interactive as a spreadsheet then Redux might be handy, but the majority of web applications are still focused on one UI element at a time and can fetch data on demand without it really interrupting the UX. What React does very well is componentize – it certainly feels more natural to make components in React than Aurelia.

In short, my cost-benefit analysis says that Aurelia is better for my purposes than React. Decisions are always made with limited information, and people with more knowledge of React would certainly disagree with my assessment. And this is the point – my environment, background, and needs are different from theirs, so we should reach different conclusions.


I want to work with things that are new because I like to learn things, but I also work for a business that needs sound decision making that considers far more than ‘what’s cool’. As software professionals we have to keep on learning so we can provide and evaluate all the options to the businesses that we are involved with, but we also have to be able to step back from the hype and make sound technology decisions based on our environment and the good of the business.

Rate Limited Async Loop







public class RateLimitedTaskProperties
    public bool IgnoreRateLimit { get; set; }

    int periodMs = 1000 / perSec;
    var tasks = new List();
    foreach(T item in enumerable)
        T capture = item;
        Task task = action(capture);

        if (task.IsCompleted && task.Result.IgnoreRateLimit)


    await Task.WhenAll(tasks);



const int tokenReqsPerSec = 5;
    bool requiredFetch = await item.MyOperation();
    return new RateLimitedTaskProperties { IgnoreRateLimit = !requiredFetch };