The Difference between "Not Yet" and "No"; Why Software Architecture is So Important

Software development has come a long way from when I started.  I come from the era of punch cards and batch compiling.  Many times you could wait over 20 minutes to compile a program, just to find out that you missed a semi-colon or had a typo.  Back then, you had to be aware of the feature you were implementing, how it fit into the system and the testing you needed to do to make sure it worked.  It also forced people to do a good up-front design of the system architecture.  You had to have a stable base to develop on, with well thought out plans for the future, just because of how time-consuming it was to make a mistake.

 Today, developers use IDE's (Integrated Development Environments) for coding.  They can type the code into an editor, which auto-completes it, and flags errors immediately.  It provides for rapid software development (in comparison). 

One of the unfortunate side effects of this instant gratification is a shift in thinking about software architecture.  There is a "go fast and break things" attitude, where developers have the mindset that their code WILL be changed, and everything they do is temporary.  They throw a product together and get users to try it out, and if it isn't quite right, well it was throw-away code anyway.  The problem with this attitude is, most of the time code doesn't get thrown away. It gets built upon a base that is not well planned or thought out, and then a year later they have to start from scratch because the product wasn't designed for expandability (both in users and in features).

Our product is for the event planning industry, specifically for managing staff and volunteers in real time.  When we developed the base architecture for the system, we took the time to figure out what future features we might need in the system and designed the back end so that it was scalable. We started designing with the ultimate event in mind, the Olympic Games.  We made sure that our architecture could handle something of that size and complexity.  The first iteration of the product used a small subset of what we designed in the back end. 

I am proud to say that 2 years later, with every feature request we have received from our customers, we have been able to say “Not yet” rather than “No”.  What that means is that our back end can handle the feature, we just haven’t exposed it to the customer yet via the user interface.