The Hardest Thing About Architecture
The hardest thing about being an architect is trust. The close second is clear communication. In my position, I simply don't have enough time to write, test, and debug all the code that I'm capable of designing, so it has to be put into the hands of others. I've been in this position before and it is quite a challenge to find the right level of detail in design for which there is enough information to implement, but not so much that I could've just written it. Then comes the trust. You hand your design and your intentions off to someone else to make it a reality. This is not meant to be a slam on the capabilities of my peers at Atalasoft, who I know read every word a plunk down here (hahaha), because they are quite capable. Current work has driven me into reflection. This issue for me is that in past jobs I've created designs for others to implment and what I've gotten back looks like the result of a game a telephone, completely missing the intent of the design, and that costs time to repair, but everyone learns in the process and that's a good thing.
In order to help things along, there has to be clear communication as to the
intent of the design, so that it won't be misinterpreted and that small holes in the details can be filled in because the intent is understood. I'm still working on that part.
In addition to trust on my part, there is also trust on the part of the implementor that this level of abstraction is really essential. I know I tend to be guilty of overdesigning code. I tend to favor flexibility and extensibility over simplicity and sometimes I go too far. Yet, history has proven that systems that are too powerful for the apparent task turn out to often be well worth the extra cost in complexity.
I like to think of PostScript page description language as a perfect example. It is a standard that from its release was far more powerful that is really necessary for driving a printer. Think about it: circa 1984 they were embedding a full Turing complete language with full affine transformations for putting pixels on a page in a way that was resolution independent, meaning that the same PostScript looked apparently the same on a desktop laser printer as a typesetter (except that the typesetter's output was far finer). All math was floating point and it is entirely possible to render a glyph scaled to the size of Cleveland. The first consumer PostScript printers ran on 68K class controllers with a relatively tiny amount of memory and no floating point acceleration, but they served very well. Now I see handheld devices which are more capable than these printers and think that their imaging model should be better, after all there is enough power to outdo an original Apple LaserWriter.
So I'm in the process of foisting three more code designs on us that are probably more powerful than they need to be, but I'm hoping that the flexibility will carry us nimbly forward in the decade to come.