The Next Best Greatest Thing Ever
Solving business problems, that is what I have felt my job has been over the past 30 years.
It started with creating better images for more effective advertising, then expanded to cover every aspect of advertising and marketing. In the past twenty years, it has been technology and technical solutions.
The only constant is change, and change is good when applied for improvement and not just in chasing the latest thing. Back when I was in photography there were trends that used new gadgets to create those better images. I remember the “light hose” which allowed you to “paint with light.” Then came the transition to digital and lots of Photoshop layers. In my first foray into graphic design, I found people who could use lots of fonts in their layouts because, well they could.
In 20+ years of web development, the technology is always changing, usually getting better.For some, the better is not important, it's being able to use the latest, the newest. I have a saying that "developers want to develop." Which means, many developers are not interested in solving business problems, but they like to tinker with the "latest and greatest."
This is usually driven by The Next Greatest Best Thing Ever, which might be a code library, a platform, or a new development language. Developers are pack animals, so they usually look for the developer running way ahead of the pack and chase them. Where they are going, they don’t often know, just where the pack is headed.
Don’t get me wrong, I think developers are a smart, capable bunch. I consider myself one of them.
Here is the problem with developers: they want to develop.
This is a great example: in looking to create a new website, a client was seeking help from my company. They needed consulting to implement the software and integrate it with their existing system. Without going deep into the technical details, let's just say there were two methods for going forward.
"Method One" was something that both their internal team and our team had vast experience with, we had existing code and integrations ready to roll. "Method Two" was brand new to everyone, but was the latest and greatest. This would meet the needs of the project, but take about two to three times as long.The justification was that this was the direction the "industry" was headed and the project would have a longer lifespan.
Here is the problem with that thinking: the life of either of these projects will be about the same, as the pace of change usually determine the life of these projects. The updating of related systems, company branding and marketing efforts and overall business needs will shift enough to justify the site being replaced in 3-5 years.
In addition, the "bleeding edge" stuff was outside the competencies of many of their team, so chances were that not only did the timeline extend, but the risk associated with the implementation was increased.The Next Best Greatest Thing Ever now was going to become the worst implementation which didn’t meet the business goals.
So how do you avoid the trap laid by the pack of developers chasing The Next Best Greatest Thing Ever? Make sure you:
have an independent voice weighing the Total Cost of Ownership.
understand the risks involved in each choice.
don’t have an alternate path that might meet the business needs at a lower cost, with faster delivery and better overall results.
We actually recommended using some of the "older" technology for the initial implementation to improve the overall project success, but we did it in such a way that we could move toward the new technology over time. Likely in time for the developers to catch up, and the business to really extend the life of their investment.
Sometimes The Good Old Stuff That Got Us Here is better.