This month marks our 20th anniversary, and we’re celebrating by looking back on how we started Chariot, how we’ve grown and what we’ll do in the future. I’ve been with the company for 15 of those 20 years. Our founder, Mike Rappaport, recently posted a great history of the company that covers our overall philosophy, so I’ll avoid repeating any of that content.
In this article, I’m going to focus on how software engineering at Chariot has changed over the years. I’ll start us off by discussing the technology we started with, then I’ll give you my perspective on how we’ve adapted over the years.
I’ll include links to talks, blog articles and interviews we’ve given or curated over the past 20 years to help prove my points. You can watch every one of our videos on YouTube or read our blogs or listen to our podcasts to see how active we’ve been in our life-long learning and in adapting to the changes over the years.
What Were YOU Doing 20 Years Ago?
I’m going to paint you picture of the landscape we were in when Chariot started. In 2002, here’s what our consultants were doing:
We were writing a lot of Java 1.4 (or earlier) code, developing in IDEs such as JBuilder, NetBeans and Eclipse, deploying to proprietary application servers (Tomcat and open source was a luxury for companies that embraced the rapidly spreading open source movement), and using APIs like Hibernate and Struts when they could get them approved.
There was lots of proprietary software out there, from databases like Microsoft SQL Server and Oracle and Sybase, to expensive application servers such as 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.
CEO Mike Rappaport of this newly created company was listening to his hand-curated team: Java and open source were the future, and small, experienced teams would be able to keep up and outmaneuver large, commercially-funded software shops, doing the work the client needed, without favor to any specific vendor or ideology.
Remember:
- Java 2 Standard Edition 1.4 was recently released
- The Jakarta Commons and Tomcat were established and quite busy
- Hibernate was new, only one year old!
- OpenOffice 1.0 was released
- Mac OS 10.2 – Jaguar – just released
- Napster filed for Chapter 11
- Jira was just introduced
- LinkedIn appeared
- Amazon sold books online. AWS was four years away…
- People still tried to create Java GUIs, but web (and eventually mobile) applications made that irrelevant.
- The smartest phone available was the Handspring Treo – a Palm Pilot + Cell Phone monstrosity
…and this was the world in which Chariot was born.
What’s Changed in 20 Years?
Although this is an impossible thing to completely summarize, we’ve all done some reflecting about the big changes.
Project estimation and management
Most software engineering teams don’t run software development projects like 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 up front. You need to understand the requirements well enough to estimate the effort.
Small teams can develop more useful software by repeatedly releasing small updates by tackling smaller stories. As the project chips away at the larger requirements, a better understanding is reached, and the customer actually gets what they need.
Today, most organizations use some sort of iterative development process with lightweight methodologies like Kanban, Agile or Scrum. Estimation is still hard, but large-scale efforts don’t generally pick one final delivery date as much anymore, since teams that develop incrementally gain feedback and understanding along the way. That is a huge improvement.
For a quick study on how we’ve been tracking Agile and other methodologies, check out these resources from Philly ETE and our blog.
Open Source is now the norm. It didn’t use to be this way…
Back in 2002, we still had to justify open source on our projects. We even had a series of blogs and podcasts about it well into 2010. Open source was just gaining a foothold in some projects, and it only began replacing proprietary servers (remember WebSphere?) and APIs (I’m looking at you, WebLogic Integration) a few years later.
In Java, the Spring Framework accelerated open source adoption beginning in 2004 (for a brief history lesson, check out my interview in 2012 with Rod Johnson. Now, we don’t even blink when selecting an open source API over a commercial one. The main concern is picking one that is stable, and has enough support and usage that you won’t have to worry about it dying just after you begin using it.
Automate all the things (where possible!)
Most teams also automate builds, tests, application deployments and monitor platforms to scale based on load. The best engineering teams are multi-discipline, involving developers with a variety of skills, testers, business experts and stakeholders regularly. A great talk about being a pragmatic programmer was given at our Philly ETE 2017 by Pragmatic Programmer Andy Hunt (Pragmatic Programming Essentials) and it dives into the criticality of automation, testing and CI.
It’s a Polyglot language world
In 2002, most of the industry focused on Java and .NET.
Today, we have a proliferation of languages, frameworks, and platforms, with deployment on the cloud becoming de rigueur. Old-school Virtual Machines are common, but now containers in Docker/Kubernetes isolate software into services, rather than full virtual machines, making it easy to scale parts of your platform where needed. For a great rundown on some of the options at the time (since then Lambda performance has increased and cold starts can be mitigated a bit easier) check out Chariot’s Keith Gregory on Picking the Right AWS Computer Infrastructure from 2019.
The Serverless movement promises to take platforms out of the way and just allow you a place to deploy code without managing the platform itself. As an example of how we approach emerging technologies, we see value in places where it makes life easier on the developer or customer (services such as Serverless RDS on AWS is a great example), and with eye toward where it is most practical, not as a hammer to drive every nail (see my own skeptical view of Serverless for everything in my 2021 Suburban Philly DevOps meetup talk).
You can see we have a healthy diversity of opinions and backgrounds at Chariot, which is something that makes us so strong.
Oh, and interestingly, LISP isn’t dead. It’s still around, and the Clojure platform is running a LISP-inspired REPL in Java for those who want to use 50 year-old functional programming techniques that are relevant even today (check out the Philly ETE 2021 talk by the legendary David Nolen on ClojureScript).
Mobile applications didn’t even exist in 2002
Remember the callback of the Treo mobile phone at the beginning of this article? At that time, phones were mostly phones, and if anything they might have had an address book, calendar and todo list on them.
The iPhone, iOS and then Android blew the doors wide open when they arrived on the scene. Chariot jumped in early, with a team of developers who embraced, learned, and then ultimately consulted first with iOS, then Android, to produce applications for our customers. Our skills grew with the industry, and we’ve focused mainly on the superior experience of native Mobile applications while also building PWAs and mobile-first web applications.
We’ve been keeping track of non-native mobile web application platforms such as React Native and Flutter, and have used tools like PhoneGap and Ionic where lightweight, simple user interfaces needed to interact with specialized hardware.
The Internet of Things is a global network of deployed microcontrollers and sensors with a wide variety of purposes. Chariot’s Don Coleman was an early IoT pioneer, having developed a Bluetooth Low Energy plugin for Apache Cordova, teaching IoT to graduate students at NYU’s ITP. He’s also an AWS Community Hero.
What Hasn’t Changed?
So given all of those changes (and I could give more of them, with enough time), there are some things that simply stay the same.
Our people are our company
At the risk of paraphrasing CEO Mike Rappaport, good people who can work together to solve problems are priceless. So is the need to continuously learn new technologies, ways of working and communicating with each other. Nobody in 2002 would think we’d be chatting on Slack and meeting on Zoom to defeat the lack of productivity during the pandemic, but everyone figured it out by necessity.
It is very hard to find good people who are a fit for your organization. This can and should take time and effort. Consulting is a business where our people ARE the product. To replace people who leave really hurts. We value them, their individual interests and specialties and talents.
Estimation is still hard (in my estimation)
It is still impossible to accurately estimate anything. Even with 20 years behind us, I still can’t give you a 100% or even 80% accurate estimate on a complex effort from the get-go, and no estimate is delivered without some wiggle room on most projects. The unknowns outweigh the knowns. Is this a greenfield project? Are we fixing an existing project’s codebase? Adding new features? Troubleshooting a thorny problem? What is the current software code quality? Of course, many techniques have helped to give a better idea of progress, but the word estimate is leveraged too often as a bottom-line “final cost” too much in our industry.
Again, iterating with incremental releases and updating your estimates along the way, coupled with continual communication with your clients, will usually give you a much better result than tying your deliverables and deadlines to a SWAG (yes, that stands for Silly, Wild-A** Guess) at the beginning of a big effort. Learn, improve, adjust!
There is no “go faster” button
There is a natural tension between business and technical goals and the practical engineering of solutions that elaborate on and discover requirements based on those goals. “The art of the possible” is very much a key part of software engineering.
“The mythical man month,” a book that outlined how it’s impossible to scale just by adding people to a project, is still very much true today. Generally you can’t accelerate a project linearly just by adding people.
Chasing new and shiny
There is always a new framework and you’ll always find early adopters who will try to use it for everything. This is doubly true for front-ends, web or mobile platforms.
New can equal less proven, so it is wise to step back and evaluate new technologies on key axes such as quality, applicability, stability, adoption, availability of engineers who know it, etc… Even though we embrace open source software, open source projects vary wildly in terms of support, adoption, lifespan, stability and the quality and availability of their contributors.
Chariot engineers are passionate about a wide variety of technologies, some of which they can use on a project, others that don’t work out due to a number of reasons. In the end, the technology must fit the situation it’s being applied to.
Bringing the visionaries to us
We are all continually learning new things in this industry. That is why we created the Philadelphia Emerging Technologies for the Enterprise conference more than 15 years ago, asking open source contributors and practicing experts in software development to come to Philadelphia to speak to us and our community. The experience of creating, curating and running these conferences is priceless.
Well then, why has Chariot succeeded?
To sum this up, I’ll give you one consultant’s view on why we’ve continued to succeed as a software consultancy for 20 years.
- It hopefully is abundantly clear that we didn’t tie our horse to one wagon. Certainly, we are fans of proven technologies, but we have our eyes on emerging tech and apply it where it makes sense. To do that, we write a lot of throwaway code experiments, and we don’t treat anything we write as sacred.
- Because we aren’t driven by vendor relationships, our engineers inform and directly influence our path. Technologies that cross over into practical use generally get applied on our projects, and generally do not hit us blindsided. Time after time, new technologies are identified, researched, cultivated and ultimately used by our consultants.
- To be a servant to our customers, we will not only share the good news but also the bad. We’ll tell the customer when we feel something is wrong, and we’ll take steps to correct it.
- We accept that you can’t force every customer to use the same software or approach, that it’s critical to apply the right tool for the job. We have no sacred technology idols. We are transparent about our abilities and experience. You can’t fake expertise, it has to be hard-won.
- We realize the power of community, speaking at conferences, writing, podcasting and meeting others who we can learn from. And our conferences prove how we give back to the community. This helps us keep our eyes open for changes to technologies, the business climate and market forces.
In the end, to be successful in business repeatedly, you have to believe in and invest in your people. That’s what Chariot has done for 20 years, and will continue to do in the future.