When I started as a web developer back in 1998 (insert old man groan here), the technology available to us was limited. Most scripting was happening via CGI. Over time, other technologies became more mainstream, such as PHP, Linux, and Apache.
On the front-end side of things, there wasn’t much to choose from. HTML was the language of choice, CSS basically didn’t exist yet, and JavaScript was far from being anything notable. When we wanted to build complex applications, there weren’t many options at our disposal.
Fast forward to today. Core technologies similar to those mentioned above have been joined by literally hundreds of other languages, tools, and products. In addition, the waters are muddied by all types of new packages such as AngularJS and React, or software frameworks such as Symfony and Laravel.
The digital landscape is more convoluted than ever, making it harder and harder to know what technology to use to effectively run a business.
As an added layer of confusion, we are in the midst of the SaaS revolution. Licensed software housed on other people’s servers (AKA “the Cloud”) is now being considered by many CTOs and technologists as a core part of their infrastructure.
Speaking of infrastructure, I haven’t even mentioned cloud-based hosting and the many companies that provide products that manage those services.
Isn’t technology fun?
On one hand, it’s exciting to have so many options available when determining how to develop a website or application. But on the other hand, the overpopulated ecosystem of technological choices makes it difficult for the less experienced technologist or executive to decide on a pathway forward. And that is where the foundation for future troubles is laid: in deciding how to move forward with a technology decision.
Last week, I took an in-depth look at CaaS, or content as a service. CaaS is a cloud-based service that manages content for websites and applications. My argument against CaaS is mostly centered on the fact that such a new concept should not be the centerpiece of an entire digital ecosystem. It’s just too risky—the providers are all new companies in start-up mode, thus making them unreliable or, at best, unpredictable. A lack of ownership makes it impossible to control and difficult to predict the future of the software.
This argument occurs with many technologies available today. The reason that so many companies make bad technology decisions is because they base their decision not on tried-and-true methods, but rather on what is trendy today.
Whose Fault Is It Anyway?
First, I blame the developers.
To understand why they make these decisions, you have to understand how they operate—and trust me, I can tell you all about it, having been a developer before I focused on running this agency!
Developers at their core are not adept at making business decisions based on economic factors, nor are they adept at making calculated decisions about technology that is best used in a business scenario. They are early adopters who spend much of their time looking at and evaluating new solutions. This is why when you entertain the idea of hiring an agency, you should look for not just development talent, but a keen understanding of what it takes to run a business and translate those business requirements into technical requirements.
You’d be amazed how many freelance developers and agencies can’t do this.
However, the real guilt in making bad technology decisions shouldn’t fall on the developer. It should fall at a higher level: the CTO or project manager.
Of course, developers should be allowed to look into new solutions, learn new technologies, and report back on their efficacy. It’s then the project managers and the technology executives that need to make a determination of whether the software being chosen is a good solution for a technology problem at hand.
Sometimes, they have problems doing this. When that happens, trendy software sneaks into places it should almost never be considered.
Why It Matters
The fact is, technology comes and goes. If you look at the PHP framework space, you can see how fickle the technology community is.
In the early days, coders worked with PHP at its core, building applications from scratch. As time progressed, they worked harder to figure out ways to work faster. This resulted in the current PHP framework era, which began near or around 2004. You can find an article from every year since then along the lines of “Best PHP Framework for 20XX”, which is indicative of how frequently the technology preferences are still changing.
First, the Zend framework picked up steam, followed closely by CodeIgnitor, and then Symfony. Today, the most popular framework is Laravel. Next year, it could be something else. This is also happening in the front-end space, where Vue.JS, ReactJS, Ember.js, Meteor.js, and Angular.js are all competing for the position of most popular library.
So how do you make the proper technology decision and avoid a software choice that, in a few months or years, can be rendered unsupported by the community?
The key is to weigh what is important to you and your application.
As the business owner, longevity should be a major issue for you to consider. Technology moves fast. It’s not like when you invest in a roof for your house. You know that a roof today has a 30-year guarantee, and the technology that powers a roof (unless you get Tesla’s solar roof) doesn’t change that quickly, so it’s easy to make a long-term commitment.
Technology and development platforms move much faster. So if longevity is your most important factor, it’s best to not choose the trendy new approach, but rather one that has maintained popularity, functionality, and a strong community or corporate support.
Of course, another major concern should be about the capability of the software to do what you need it to do. Once you answer that question, then you can take a look at which platform will provide you the best support going forward, the utmost flexibility to control your own future, and the ability to scale to proportions you aim to achieve.
How to Compare Apples to Apples
Remember: Your project is being built with the purpose of growing or developing your business. It isn’t about building it with the technology of the day that most impresses other developers. End users won’t typically know what is being used under the hood, nor will most of them care.
If you’ve ever read a book about investing—either in securities or real estate—you know that the value upside in an investment is realized when you buy in, not just when you sell. If you can buy a property at the lowest cost possible, even under market prices, you have already locked in value. Technology works in a similar way: Making the proper technology decision today will pay dividends in the long run by avoiding unnecessary rebuilds, maintenance, and adjustments as those trendy software packages change or go out of style.
Now, I would wager that you are wondering how you can evaluate these platforms yourself.
The answer may be that you can’t, and that’s why you are looking at agencies.
In that case, you must vet the agencies themselves to ensure they have that mixture of skillsets that I mentioned before. Do they have a development team that is capable, a portfolio of successful past projects, and a clear understanding of the economics of running a business and translating business requirements into technology goals? Can they present you with businesses that are running on their software and have been for years? And can they show you case studies with each technology they are recommending?
If you can’t judge the platform, then judge the team.
I’ve written this post because I see so many prospective clients that go another way with their development needs, only to come back to us with projects that are pieced together with a variety of new technologies that never quite work well together. The other scenario we see often is a project that is completed and has only been operating for a short period of time before the software it’s based on becomes unsupported, or they outgrow its functionality.
I’ve seen these scenarios play out with organizations of various sizes, from small businesses all the way up to massive corporations, where the tech team builds huge applications on the backs of risky start-ups and unproven technologies. And in each case, proper planning and evaluation of the components could have prevented such outcomes.
Key Takeaways From This Post
- Developers are not adept at making technology choices in response to business requirements.
- Technology is changing quickly and platforms are coming and going every year.
- Never build your entire platform based off an unpredictable piece of software.
- You must evaluate software packages based on ability, longevity, and potential maintenance or upgrades.
- The best agency will translate your business logic into technology recommendations, and will have proven their capabilities in the past with a deep portfolio.
