Skip to content

Coding Architects, Architecting Coders

In the beginning, there were system architects and there were coders. The system architects were much revered for their experience and wisdom and had the ultimate authority over the state of the software system. They lived in private offices where they could do the hard work of figuring out how to build a system. Once they had figured out how a system was to be built, the system architects would write a thick document detailing how and what to code and then pass it to the coders to be implemented. The coders on the other hand, were relatively inexperienced, typing automatons who could implement what they were told to implement by the system architects. They had no decision making ability or thinking responsibility, save perhaps for deciding how much whitespace to include in their code, and even that much responsibility was a bone of contention for the system architects. What the coders were to code was dictated to them and all they had to do was type it in. If any of the coders got hit by a bus, they could be easily replaced by the next warm body to come along.

Everything was fine in software development land, until the upper-crust of coders evolved into thinking beings and noticed a few things. First, the system architects hadn’t coded anything in 20 years and often made mistakes. Granted, the architects may have implemented the most advanced wis-bang COBOL feature in 1980, and so had gained noteriety, which led eventually to their current position, but they were out of touch with the code. They had no practical experience with modern languages, compilers, and techniques. Of course they had read the latest books on modern software development, but they had never actually implemented anything using what they had read. Since everything one reads in a book must be correct (especially if you paid $79.95 on Amazon.com for it), the system architects claimed their knowledge was up-to-date and therefore continued to decree the hows and whats of the system design. The evolved coders could do nothing. Mistakes were decreed and implemented and problems ensued. Projects were over budget and over time and the software systems produced were riddle with bugs at every level. Though the management could obviously see that the blame was to be placed on the relatively inexperienced coders, the evolved coders knew what the real problem was. The system architects were out of touch.

The second thing the coders noticed was that they had a lot more knowledge than anyone gave them credit for. They were in the trenches, writing code and figuring stuff out. They knew the details and could relate those details upward to the component level and further to the system level. In short, they knew an extensive amount of information that could have a signifcant beneficial impact on the state of the system design on multiple levels. Alas, no one was listening to them. There job was to code what they were told to code, even if it was wrong. And so they did. Problems ensued, mistakes were made, projects failed.

So the evolved coders decided to take their knowledge elsewhere and build their own systems. They architected the systems themselves and though mistakes were made due to inexperience in system design, they were offset by the advantage of having pertinent, up-to-the-minute, hands on information on which to base critical design decisions. They were successful and they gained noteriety. Eventually, they were lured in by corporations and were raised to the level of exalted system architects. The new system architects got more money, private offices and more ego stroking corporate mumbo-jumbo then you could shake a stick at. In addition the system architects would no longer have to be bothered with the tedious chore of coding. They could spend their time on important design issues and let the corporation’s army of coders implement their immaculate designs.

Lather, rinse, repeat.

——————————————

Coding architects and architecting coders. The solution is to share the knowledge and share the experience. Gain the advantage by using both sets of developers on both tasks. Everybody teaches, everybody learns, everybody wins.

System architects who don’t cut code are out of touch. Coders who don’t have any architectural input are wasted.