Yes, Software Architecture really does matter

Software Architecture really does matter and, apparently, this is not a commonly held belief.

All too often, software developers are hired to "program" an app and get it out the door.  Bad patterns from previous gigs are carried over and perpetuated. Whatever technology leadership is in place just reacts to business pressures, and puts pressure on the team to deliver while trusting the developers to get the architecture right.

At some point architecture decay sets in, the code gets brittle, new features take forever to add, new hires can't really figure out the code,  the software gets bloated and runs slow, management gets frustrated and demands to know who is responsible, someone gets fired or quits, and new leadership is brought into "fix" the problem.  I've observed this pattern several times.

Here are my general guidelines for software architecture:

Don't be special!

Software architectures get into trouble when a couple of developers think they have a special set of problems and decide to be special in the way they apply well known patterns or technologies.  I've seen this many times, and have had to pay the price to fix it.  There is a reason why patterns develop over time, and why the community of developers apply something in a particular way.  Use the technology the way it was intended to be used. Otherwise, the next group of people won't understand your "special" techniques and you won't be able to upgrade or evolve properly and then someone will have to undo what you did. Don't be special.

Listen, pause, think, code, repeat.

Before you write the fist line of code, pause and think.  A one hour or one-half day discussion about where everything fits and what the proper architecture should be pays very large dividends.  Find an architect or senior developer, sit with them and bounce around ideas.  Look at what others have done.  Read articles, blog entries or books.  Avoid inventing something new, use something that already works.

Don't go dark

One of the worst things you can do when coding is go dark to the rest of your team.  You need to share and they need to know what you are doing (daily stand ups really help here).  Review your architecture and code with your team often.  Tell them what you are doing often. Keep running your ideas past them.  Doing all of this will minimize the chance that you will do something dumb.

Technology leadership should really lead

Software architecture should be a top-level item for technology leads and managers.  Talk about it, espouse it and be familiar with the architecture that the coders are developing.  Too often, technology leadership has no idea about the software architecture.  Some managers manage by Gantt charts and feature lists -  that's not leadership, that project management.  Lead and get in front of architecture issues. Make sure senior management is aware that this is important.  Add time to the project for it.  Schedule meetings to discuss it.  Give senior and lead developers time to address it.  

Seriously, architecture is important stuff.  Don't just hope it happens right.