More than 20 years ago my team and I were working with my client on a web application. It was still 1999, so the dot-com bubble had not yet burst, but it would begin to weaken only five months or so into Y2K. And to think that everyone was concerned about worldwide computer failures at midnight on January 1, 2000 or shortly thereafter! There was still no widespread concern about the continuously swelling stock market full of valueless tech startups that quickly gained huge wealth on paper; that is, white paper, not inked in green. Yet, Alan Greenspan was chipping away at market confidence, predicting the imminent demise of the bubble.
During that time there were a lot of stories about enormous successes, mostly involving companies that earned no revenue. Headlines such as the following were not uncommon.
Excite@Home will pay up to $1 billion to acquire Bluemountain.com, a privately held electronic greeting card company with little revenue but millions of loyal users.
Electronic greeting cards. Little revenue. Acquired for $1 billion. There was a lot of head shaking when that story resurfaced every few weeks. I wasn’t sure whether Excite.com, which acquired some other dot-com named @Home and became Excite@Home, which acquired Bluemountain.com, lasted another year. It actually managed to survive until 2002. I am pretty sure if you navigate to Excite.com and Bluemountain.com you’ll get a good chuckle out of what were once red-hot dot-com boomers.
One of the engineers on my team had a similar story about a startup that he had worked for a few years earlier. The engineer was hired by a young entrepreneur and founder to deliver a financial solution, fast. Using an early release of Java, the engineer worked hard to deliver clean, tested code. In short order the youthful founder got impatient, tired of seeing code roll out one class at a time. He confronted the engineer with heavy criticism, and began to hack together a solution of his own. The founder knew little about software development. What he knew well was that the timeline he was up against wouldn’t budge. Nothing was going to stand in his way of gaining the wealth he could see sitting just ahead.
So the founder’s confrontation soon turned to action when he began slapping components together, resulting in a system that was quick, but quite dirty. The components that were being composed weren’t custom Java or even Visual Basic or ColdFusion code. It was C and C++ based, which probably sounds suitable for 1999. But how could someone with little knowledge of software development deliver the much more bug prone C/C++, when a Java solution was already deemed to be delivered too slowly? He didn’t write the C/C++ code. It was written by Microsoft while implementing Excel and Word.
Correct, this young entrepreneur slapped together spreadsheets and documents using formulas, macros, and some Visual Basic for Applications (VBA). There were a few custom file exports and ad hoc processing to generate HTML documents. These kinds of hack-o-riffic solutions continued all the way to selling subscriptions to the data hosted by the startup’s website.
The engineer was appalled. He didn’t understand how this unconventional way of delivering a solution in exchange for customer subscriptions that cost real money would ever survive a public-facing release. Yet, it did. The final outcome was that the young entrepreneur became a very wealthy person, and the engineer went packing to find his next job.
When this engineer told me the story he did so to make one simple point. He said, “I learned a very important lesson. I learned that speed matters.” He lamented, “here I am still writing for loops in Java, and this kid already had a successful exit.”
At least a decade before… I began to realize that code was an obstacle to a product.
An experience like that never leaves you, and even though I didn’t live that experience myself, it hasn’t left me. Speed matters. At least a decade before I heard that experience, I began to realize that code was an obstacle to a product. Don’t get me wrong, I love to write code. Even so, as an entrepreneur the code stood in my way, denying me a product before every line of code was hand written. I didn’t need code alone. The code must have near zero defects, or at least near zero along the common code paths.
I didn’t need code alone. The code must have near zero defects, or at least near zero defects along the common code paths.
Do you know what the young entrepreneur invented, besides a working financial system that earned him wealth? Possibly unknown to himself, he prototyped Airtable, Bubble, Honeycode, AppSheet, and the like. Yes, the young entrepreneur integrated some existing components to deliver one of the early no-code tools, or at worst case a really, really low-code tool, along with the system he created using it.
I will admit that I, and probably none of you readers, would like to have been the software development team on the acquiring end of the deal. Most likely, or hopefully, the acquirer found a way to keep the system running until it could create a replacement system. Yet, even with this scrappy system the acquirer was earning revenue and growing its customer base. This provided clear requirements and hints toward further innovation, along with a time buffer, that made it possible to develop a system that could be maintained and scaled to meet increasing demands.
Still, we would all choose to trade the cardboard-and-bailing-wire, hack-o-riffic approach, in exchange for a real, quality architecture and domain model implementation. Wouldn’t it be outstanding if we could deliver a system in record time, using an industry leading programming language and platform, with Bounded Contexts and accompanying domain model, using an Event-Driven, Reactive, Microservices Architecture with along with best-in-class databases, message bus/broker, and web user interface?
That’s exactly why we’ve invested heavily in the development of XOOM. The XOOM Designer delivers fully tested, bug-free, working domain models, reinforced by a compressed architecture that is responsive, scalable, resilient, and fully executable immediately. You focus on the delivery of innovative domain models that reflect true business solutions to complex business problems, and you get the leading-edge architectures and best-in-class architectural mechanisms. Within minutes—not days, weeks, or months—you get an advanced Event-Driven, Reactive Microservices Architecture housing a carefully crafted domain model that uses both the strategic and tactical patterns of Domain-Driven Design.
Sadly I have heard software developers resist the possibility of using software development acceleration tools. They do so, not because the code produced is bug-free and “perfectly written.” They resist because they consider the tool a threat to their jobs, because their work won’t require years of effort, which means they make less money on each new project. Clearly this viewpoint is upside down. Delivering higher-quality software faster frees developers to focus on innovation rather than endless tweaks, and implementing nonessential architecture, and then refactoring it when dissatisfied, many times over. This mindset must change, and it will. Businesses will demand innovation faster and with clean, simple code.
XOOM delivers integrated solutions so rapidly that teams can now consider complete system replacement, potentially without going through any significant rework of your legacy Big Ball of Mud. Try our low-code delivery that easily transitions to a full-code software development life cycle.
Sorry-not-sorry if I burst your bubble. Learn an important lesson. Speed matters.
