We need to stop writing software like it was the 90s (which unfortunately we still do to this day). Let’s take agile to a new level by making software that is agile enough for business needs. The xp agile methodology requires that we have Communication, Simplicity, Feedback, Courage and Respect as the core principles when we write software. I think it’s time we take these agile principles to heart when designing our systems. We should stop writing software because there is a specific business requirement for it. We should instead focus on writing software that has great utility by itself.

If you look at how AWS was built, it was most definitely not designed to suit a specific set of business needs. It is a culmination of multiple pieces of utility software that has found synergy by working together to satisfy multiple business needs. This is the reason that AWS has hundreds of available services. They we’re built because they had a specific utility that they we’re good at. That should be enough reason for software  to be written and not wait for a business requirement before we start putting code to silicon.

We should stop falling into the trap of trying to implement reusable components and services only when a business opportunity comes. Aligning business requirements to development of these components may seem an obvious win but rarely does it produce the intended result because of the following reasons:

• Lack of time and resources
• Urgency to deliver business feature first over re-usable feature
• Short sightedness or just not enough vision
• Mentality of satisfying the business requirement first over creating a good product

We all start off with the best of intentions but when time is running out or business begins to demand for results, we all know that robustness and flexibility is dropped in favor of bespoke but usable features. We need to build something SIMPLE now! We don’t need to plan months or years ahead, just enough so we can start something. Then we design and implement a SIMPLE utility that can act as a stand alone service or as a reusable component.

The utility will of course need to have actual business value so we will need to get FEEDBACK. I think this should start within the development community where we get to show them what we built and receive comments and hear use cases from them. This is how we build a better product. We should also take negative FEEDBACK very seriously. If we deem that what we are working on is not useful for technical reasons (performance, lack of organization’s technology support, an existing and better competing utility/component) we should drop it. But we should never use the excuse that we don’t have enough people to work on it (because honestly we NEVER really ever have enough people to work on anything that is not business aligned). If a utility or component is deemed useful, we will build it.