Over the past two decades, the technology and choices available to us as developers have evolved very rapidly.
It’s mind-boggling to reflect on the dramatic changes in software engineering at Trolley Solutions, founded in 2002, as well as in the entire industry at that time. At the start of the new millennium, smartphones were just a twinkle in the eyes of engineers.
What has changed in 20 years?
Consider the landscape when Chariot began. Our team was writing a lot of Java 1.4 (or earlier) code, developing in IDEs like JBuilder, NetBeans, and Eclipse, deploying to proprietary application servers (Tomcat and open source were a luxury for companies embracing the open source that was spreading rapidly), and using APIs like Hibernate and Struts when we could get them approved.
There was plenty of proprietary software, from databases like Microsoft SQL Server, Oracle, and Sybase, to expensive application servers like WebSphere and WebLogic, to commercial version control systems like ClearCase, PVCS, and Source (un)Safe. Books and manuals were everywhere. There was no Stack Overflow. In short, you had to do a lot of reading and experimenting to level up.
A few highlights to remember:
- Java 2 Standard Edition 1.4 was recently released
- The Jakarta Commons and Tomcat were established and very busy
- Hibernate was new – it was only a year old!
- Mac OS 10.2, aka Jaguar, was just released
- Jira has just been introduced
- Amazon sold books online; AWS was still four years old
- People were always trying to create Java GUIs, but web (and eventually mobile) apps made that unnecessary
- The smartest phone available was the Handspring Treo – a PalmPilot and cell phone monstrosity!
I’ve been with Chariot for 15 of the last 20 years, and while it’s impossible to sum it up completely, my time has allowed me to reflect on the big changes.
Estimate and project management
Most software engineering teams don’t run software development projects the way they did in 2002. They don’t use Microsoft Project GANTT charts much anymore, because it’s very hard to know how long individual tasks will take. upstream. You have to understand the requirements well enough to estimate the effort, and that’s rarely possible, so you’re constantly updating a very detailed Microsoft project plan, and it quickly deviates from reality, to the point of being useless .
Small teams can develop more useful software by repeatedly releasing small updates to tackle smaller stories. As the project narrows down the larger requirements, we come to a better understanding and the customers actually get what they need.
Most organizations today use some sort of iterative development process with lightweight methodologies like Kanban, Agile, or Scrum. Estimating is still difficult, but large-scale efforts typically don’t pick a final delivery date as much anymore, as incrementally growing teams get feedback and understanding along the way. It’s a huge improvement.
Open source is now the norm. It wasn’t always like this
In 2002, we still had to justify open source on our projects. We even had a series of blogs and podcasts for that matter, way back in 2010. Open source was just beginning to take hold in some projects, and it only began to replace proprietary servers (remember WebSphere?) and APIs (I’m looking at you, WebLogic Integration) only a few years later.
In Java, Spring Framework accelerated the adoption of open source from 2004 (for context, check a brief Spring Framework history lesson with Rod Johnson and his work on Scala in 2012). These days, we don’t even blink an eye when selecting an open source API over a commercial one. The main concern is choosing the right ones. (Look at this podcast with Joel Confino in 2010 on the selection of an open source project. Some things never change.) It’s important to find one that’s stable and has enough support and use that you don’t have to worry about it dying right after you start using it.
Automate everything (if possible!)
The best engineering teams are multidisciplinary, regularly involving developers with varied skills, testers, subject matter experts and stakeholders. Most teams also automate builds, testing, application deployments, and monitor platforms to scale with load. A nice discussion about being a pragmatic programmer was given to our Philadelphia SUMMER 2017 by Andy Hunt and he dives into the criticality of automation, testing and CI.
It’s a polyglot world
In 2002, most of the industry was focused on Java and .NET.
Today, we have a proliferation of languages, frameworks, and platforms, with cloud deployment becoming de rigueur. Old-school VMs used to be common, but now Docker/Kubernetes containers isolate software into services, rather than full VMs, making it easier to scale parts of your platform. shape if needed. For a good look at some of the options back then – since then Lambda’s performance has increased and cold starts can be mitigated a little easier – check out Chariot’s Keith Gregory on choosing the right AWS IT infrastructure from 2019.
The serverless movement promises to do away with platforms and just allow you to deploy code without managing the platform itself. As an example of how we approach emerging technologies, we see value where it makes life easier for the developer or customer (services such as Serverless database with Aurora Data API2021 Serverless RDS on AWS is a great example), and with an eye to where it’s most practical, not like a hammer to drive every nail in (see my own Without server, without Schmerver skeptical view of serverless for everything in my 2021 Suburban Philadelphia DevOps dating chat).
Oh, and oddly enough, LISP isn’t dead. The language lives on, but has been redesigned by rich hickey as a Clojure platform: a LISP-inspired language and platform that runs in the Java Virtual Machine (among other things). For those who want to use functional programming techniques that are 50 years old and still relevant today, check out ClojureScript in the typescript eraa Philly SUMMER 2021 conference by the legendary David Nolan on ClojureScript.
Mobile apps didn’t even exist in 2002
In 2002, phones were mostly phones, and they could have an address book, calendar, and to-do list.
The iPhone, iOS and then Android smashed through the doors upon arriving at the scene. Chariot jumped in early, with a team of developers who adopted, learned, and then eventually consulted with first iOS, then Android, to produce apps for our customers.
These platforms have evolved tremendously over the years, changing languages (iOS from Objective-C to Swift, Android from Java to Kotlin), undergoing many changes in their design language, tools, SDKs and features. ), which has kept our mobile team on their toes for over a decade now.
We monitor non-native mobile web application platforms such as React Native and Flutter, and have used tools such as PhoneGap and Ionic where lightweight and simple user interfaces are required to interact with specialized hardware.
The next 20 years…
This brief look back can help today’s developers and the companies they serve understand the landscape of software development in the past, present, and future. Whether you’re a developer or helping your developers make technical decisions, change happens at high speed. As Steve Jobs said in his Stanford commencement address, “You can’t connect the dots looking to the future; you can only connect them looking backwards.