ACME systems – evolution phase 1.0

ACME started out with a couple of things in common with the many thousands of small software businesses scattered around the globe: it had some good ideas and a saw gap in the market that it could exploit to make its fortune. It had a relatively small amount of cash so it needed to move fast to be able to survive and it needed to quickly entice, enlist, and retain customers at all costs. It did this by delivering what the customer wants just before the customer needs it. Deliver too soon, and it may have wasted money on building solutions that the customer decides they no longer want. Deliver too late, and someone else may well have taken the company's market share—and the revenue—away. The keyword here is deliver.

As a small start-up, in the early days, the going is slow and the work is hard: lots of R&D, frantically-built pre-sales prototypes, quick and dirty deliveries, and unrealistic deadlines. After many long days, nights, weeks, months, and weekends, things actually start to come together. The customer base starts to grow and the orders—and revenue—start rolling in. After a while, the number of employees are in double figures and the founders have become directors.

So, what has this got to do with CD or DevOps? Well, everything really. The culture, default behaviors, and engineering practices of a small software house are what would be classed as pretty good in terms of CD and DevOps. For example:

• There are next to no barriers between developers and the operations teams—in fact, they are generally one and the same
• Developers have full access to the production environment and can closely monitor their software
• All areas of the business are focused on the same thing, that being to get software into the production environment a quickly as possible, thus delighting customers
• Speed of delivery is crucial
• If things break, everyone swarms around to help fix the problem—even out of hours
• The software evolves quickly and features are added in incremental chunks
• The ways of working are normally very agile
• Communication and collaboration across the business is efficient and, for the most part, effective
  

There is a reason for stating that the culture, default behaviors, and engineering practices of a small software house would be classed as pretty good rather than ideal. This is because there are many flaws in the way a small software business typically has to operate to stay alive:

• Corners will be cut to hit deadlines, which compromises software design, quality, and elegance
• Application security best practices are given short shrift or even ignored
• Engineering best practices are compromised to hit deadlines
• The concept of technical debt is pretty much ignored
• Testing won't be in the forefront of the developer's mind (even if it were, there may not be enough time to work in a test-first way)
• Source-and version-control systems are not used religiously
• With unrestricted access to the production environment, ad hoc and uncontrolled tweaks and changes can be made to the infrastructure and environmental setup
• Software releasing will be mainly manual and most of the time an afterthought of the overall system design
• At times, a rough and ready prototype may become production code without the opportunity for refactoring
• Documentation is scant or non-existent—any that does exist is probably out of date
• The work-life balance for an engineer working within a small software house is not sustainable and burn out does happen
  

Let's have a look at the software-delivery process for ACME systems Version 1.0, which, to be honest, shouldn't take too long.