Dominic Cronin's weblog
- Will my library be generic?
- Is it a genuine (watertight?) abstraction, in that a naive programmer can simply call it with the assurance that the domain experts have done their job within?
- Am I happy that whatever updates and bugfixes the library gets will be appropriate for all its clients?
- Will I have problems updating the library because I don't dare break its clients?
- Validate your HTML. Know what it means to have valid HTML markup. Understand the tooling. More information is always better than less information. Why fly blind?
- Nobody cares if your HTML is valid. Except you. If you want to. Don't think for a second that producing perfectly valid HTML is more important than running your website, delivering features that delight your users, or getting the job done.
9 Troubleshooting questions
Some questions from Tess Fernandez to help when troubleshooting complex problems.
Tess Fernandez' blog (If broken it is, fix it you should) usually contains very technical content. Today she has posted a troubleshooting guide that will be of use to anyone who has to deal with complex problems. It comes in the form of 9 questions, with full details and examples to explain each question. For the impatient, here's the list, but I heartily recommend reading the entire post.
The wrong level of abstraction, YAGNI, LOLA, and the fallacy of re-use.
Almost as an aside, in his recent post "And get rid of those pesky programmers", Phil Haack spins out a link to Udi Dahan's "The fallacy of ReUse". Coupled with the fact that I'd just read Jeff Atwood's "The Wrong Level of Abstraction" and that this subject is a hobby horse of mine, well I have to write something, eh?
It's all about judgement, isn't it? I mean - the kind of judgement that you expect people to acquire as they gain experience in software development. When do you re-use something, and when do you just re-do the job. As a web content management (WCM) specialist, my own work often involves creating templates that generate web pages based on content entered into other parts of the system by authors and editors. My weapon of choice in this endeavour is Tridion. As with other WCM tools, the templating facilities provide you with the ability to write out the HTML of the page design, and inject specific items of data where you want. In my (not so?) humble opinion, this is exactly the right level of abstraction for dealing with the specified problem, viz. that of creating a web page.
Some people, given the same task and tools, will immediately factor every single thing into a reusable library of functions. I don't do this, and sometimes a new colleague will be surprised at this, or even say they think it's wrong. My first response is usually to tell them that as and when there is a second occasion when I need the same functionality, I will either factor it out to something more abstract, or maybe just wait for the third occasion. As the agilists will have it, You ain't gonna need it (YAGNI). The problem goes further, however. Often I am faced with a choice between writing a few lines of code locally, very closely focussed on the specific output I need, or using/creating some generic function that will give me the output I need, if only I can figure out exactly how to invoke it. Maybe it will almost do what I need. <blink>No problem, I can always tweak it up a bit and add a parameter or two. Right?</blink>
I recently came across a function whose purpose was to create hyperlinks. It would accept about ten parameters, and could produce perhaps 20 variations on the theme of a hyperlink. In order to use this function, you have to open it up and read it, otherwise you don't know how its going to behave. (I'd defy anyone to thoroughly document the consequences of combining the parameters in different ways.) So a clear and present danger in creating an abstraction is that you create aleaky abstraction. (With more than a nod in the direction of Joel Spolsky's splendid article on the Law of Leaky Abstractions, or LOLA to her friends!)
So wrapping up this trivial stuff into an abstraction just made it non-trivial to work with. Result! Actually - all the function really did was dispatch to (hopefully) the correct code snippet based on the parameters. Having the code snippets locally in the templates would have been much easier to read and less error prone. The API provided by the vendor was already at the right level of abstraction, and further abstracting it was probably a mistake.
Of course, it's not as simple as that - otherwise we would never have started down this road in the first place. There is benefit in creating library functions, but mostly it's not about saving you from writing the same three lines of code in a bunch of places. It's often the case that what you want is for any change in the behaviour of your function to be propagated automatically to all the places it's called from. The only trouble is, you can't tell after the fact whether all the people you called your code knew that this was your intention. Udi Dahan notes that the characteristic property of code which you want to reuse is that it is generic. He also notes that re-use introduces dependencies, and that dependencies are what cause all the pain and grief of software maintenance.
Jeff Atwood's problem was the other way round. His choice had been to programme at a lower level of abstraction, when perhaps choosing to use a higher level library written by domain experts would have saved him from mistakes caused by him not understanding the low-level implementation details well enough.
So when you think about moving some code into a library, think about why you're doing it. If your purpose is to capture expertise that your client programmers don't have, you are probably doing a good thing. In this case, your library will probably have a very clear, tightly focussed purpose. There must be no possible ambiguity (or leaks, if you prefer) in the API you expose. When I invoke YAGNI against prematurely factoring code out into libraries, I can hope that this introduces a shakedown period between on the one hand, needing some code, and on the other hand, needing to introduce a layer of abstraction. Without this shakedown period, it's quite unlikely that my decision to abstract will be conscious enough to encompass those questions:
Of course, the "domain expert" might be the programmer who writes the client. Even so, getting the interface right is just as important for your own peace of mind. Then you can afford to forget some of the detail of the inner workings.
Coming back to re-use: we are often faced with managers who assume that re-use is always good. It is up to us as technicians to make the right judgements about what should be re-used, and then if necessary inform and explain. As Udi implies, building for re-use is often synonymous with lock-in to maintenance hell. Sometimes, the right decision is to build disposable code on top of cleanly factored abstractions. The HTML templating I began with is a good example. If the site design changes, it probably makes sense just to throw the old templates away and start again. Because the underlying API gives me clean access to the various fields in the content, I can put together another page template very quickly - probably quicker than figuring out all the dependencies under the old design. Jeff's example of JQuery is another good one. Because the library is so powerful and tightly engineered, it's not going to take you long to simply re-implement your desired behaviour when the design changes.
Re-use is unlikely to be successful unless the code being re-used was explicitly designed with that in mind. Simply factoring some code out to keep it tidy isn't the same thing as building a library. Be careful that you don't accidentally give the impression that your code is intended, designed and implemented for re-use if it isn't. It's OK to write disposable code too, especially if you know the difference between the two.
Server upgrades - portage hell and beyond
Oh what fun you can have once you start to upgrade a previously working server.
So it's now a couple of months ago that I decided to blow the dust off some unfinished business on my Gentoo server. I'd always thought it would be nice to get a desktop running, but it had never been a priority. After all - the machine is used as a server. It sits under the telly and serves up the occasional web page. A desktop is definitly a "nice-to-have" feature rather than an essential one. As usual with such things, it expanded out into a mega-project.
I'd previously tried to get KDE running, and now I'd be installing Gnome, I'd be adding a lot of packages and uninstallling quite some others, so the first order of the day was some general housekeeping and clean-up. Gentoo linux is characterised by the portage package management and build system. You specify that you want to use a particular package by using the emerge utility, and the relevant code is pulled from the servers, compiled and installed automatically. If the module you've requested needs some other module, that will be built too, and so on - from there it's turtles all the way down.
Portage keeps track of the packages you've specified under the heading of "world". You can sync your system with the latest releases, and then rebuild world. Lots of people do this very regularly, and thereby ensure that they have the latest-greatest versions of everything running on their computers. (Obviously, you can also specify that you want specific versions for some things.) Anyway, I started off in the standard way by running emerge --sync and then emerge --update --deep --newuse. Then I watched the breakage roll in. It had been a couple of years since I'd done this, and I'd definitely never done it after my previous abortive attempts at a desktop, so my system was, frankly, a mess. The main problem is that you get one package that isn't compatible with another. Then you have to fiddle with versions, or just uninstall things just to get it working. The longer you leave it, the bigger a puzzle it is. To put it in perspective, people who use Gentoo for their desktop machine often get it in sync every day. On a server you don't update much, you might let it go six months. A couple of years is just crazy.
Quite some time ago, I had realised that using portage to keep my Zope/Plone server up to date would just be a world of pain. There are just too many dependencies within the Python/Zope/Plone stack. Specifically, the problem is that to upgrade, you pretty much need to run the old version side-by-side with the new one while you upgrade your data. Portage generally lets you have only one version of a package at any given time. There are some rare exceptions, in which case separate versions can co-exist, in what are known as "slots". For Zope and Plone, I chose instead to use Buildout, which does something similar to portage, but for python-based systems. This worked fine, but it meant that portage didn't know about these systems. (You can install them using portage, but not at the versions I needed to satisfy some of the plone add-ons I was using.)
So I wrestled with portage through the wee-small-hours night after night - got all sleep-deprived and cranky, and otherwise wasn't much further forward. Quite a long time later, I emerged (pun unintentional, but acknowledged) with a system where all the dependencies lined up beautifully. Everything was clean, and all desktop-ish things were consigned to oblivion.
Great stuff, I thought - now we're cooking. So I went ahead and started to add Gnome to my system, only to discover that I needed to juggle with yet more dependencies in order to get Gnome installed. (Gnome requires quite a few packages, and most of them have their own requirements too!) Never mind - a few days later I was good to go. Super!
Except... aaargh... along the way, I'd broken my web site. You see, to get Gnome running (at least at the latest version, which is what I wanted), I'd installed Python 2.5. Why not, eh? After all, 2.4 is pretty old hat; they even have 2.6 these days. But - it's Zope, you see. I'm running Plone 3.1.7, which requires Zope 2.10.6, which requires Python 2.4.4. So when I went to start up my web site, it didn't - Zope pretty comprehensively didn't want to run on Python 2.5. Ouch!
But no problemo! After all, Python is one of the very few things in Gentoo portage that has slots. You can have Python 2.4 and Python 2.5 side-by-side. So then you can have either one as the default. You could fix up the symbolic links to /usr/bin/python by hand, but there's a utility that helps you to do this quickly and accurately (as well as supporting several other system configuration options), so I "emerged" eselect, and was able to switch between the two. After switching to 2.4, Zope should just work again, eh. After all, it had worked on 2.4 before....wrong!
It turned out that I could get the result I wanted by doing a full emerge of Python 2.4, but simply switching between the two wasn't enough. The full emerge, would also take care of recompiling all the libraries that linked to Python. What I needed was the "python-updater" utility. This is a script that rebuilds all the stuff that's known to work differently on the two versions of Python. If I switched to Python 2.4 and ran python-updater, everything was fine.
But the story goes on. Running Python 2.4 as my system default Python was enough to get the web site back in the air, but presumably this would be a big spanner in the works of my project to get a desktop running. (Actually, not just a desktop - I'd added some other packages such as mono-develop, which represent my motivation for wanting a desktop in the first place, but some of these also had Python dependencies).
After a bit of research, I realised that if I could specify the Python executable I wanted in my buildout configuration. (using the "executable" directive in the [buildout] section). This meant I could have the default Python be 2.5 and still have Zope/Plone use 2.4. I tried this, and it worked, and the web site was back up and I breathed a sigh of relief. Then I thought - let's get back to a clean system, so I ran python-updater.... and huge skip-loads of fail came raining down. Zope seemed to start OK, but my Plone sites were hosed, and had some bizarre message that didn't point anywhere useful whatsoever. Grrr... so I set the system Python back to 2.4, ran python-updater, and all was well with the world. At this point I left the system alone for a couple of days just to recover a little tenacity - sometimes you have to.
When I came back to the problem, I flipped everything back into the broken configuration, and started methodical debugging. After quite a few false starts, someone suggested that I start Zope in debug mode. I did this, and the problem was immediately apparent. While starting up, Zope was reporting that it couldn't find PIL, the Python Imaging library. Well PIL is pretty clearly a dependency for Plone, so that was the problem. Re-visiting python-updater a couple of times showed that one of the things it does is to remove Python's site-packages from whichever Python you're switching away from. (I don't understand why it does this. Is that a bug?)
This new development led me to the conclusion that if, instead of having the buildout rely on the PIL installation in Python's site packages, it had its own local copy, I could just leave it wired up to Python2.4, and it wouldn't matter that switching to 2.5 and running python-updater would make the 2.4 site packages disappear. But how to do this? I spent a little time investigating the possibility of using buildout to download and build a local PIL. I'd seen some hints on the web that you could use a buildout recipe to do this, so I tried using a buildout recipe that was supposed to do this, however it was so poorly documented that I was reduced to guesswork and soon fell back to plan B. (Fortunately, I can't remember the name of the recipe, and Googling for it a second time didn't turn it up. What it did turn up was this, which might also work.)
Plan B was to attempt something using virtualenv which will create a virtual python environment locally for you, into which you can deploy whatever packages you want. I was just about to go along this road, but it looked quite tricky to figure it all out and integrate with my existing buildout, so I asked on the #plone channel on freenode IRC and someone suggested I look at PILwoTk. At first I thought I'd rather look straight into the sun, but I simply added the egg to buildout.cfg and it just worked. I don't know where PILwoTk is to be found or why it has such a bizarre name, but it's got my system working with a local PIL in my buildout. Great.
All I need to do now is finish getting my desktop working. Of course, it won't be a real desktop, because there's no desk, and definitely no screen or keyboard. Watch this space.
Amsterdam
Ingrid's "Where I live" post highlights some of the bizarre perceptions people have of Amsterdam and why a person might choose to live there. When I first came here, I was struck by the number of my countryfolk whose immediate thought was "you'll be stoned all the time then".
For sure, the regulations concerning cannabis are relatively liberal here. For me that mostly means that I know that there may possibly be some in the house, but I have no idea where it might be. Maybe it was the victim of a spring-cleaning frenzy. In less liberal regimes, you damn well know where your stash is at.
Predicate
It's a predicate. That's the name of the thing, a predicate. Why can't I remember that?
So there I was, trying to explain some XPath thing to one or two of the guys on the project, and I kept hitting this mental block. The things in the squaredy-brackets; what the heck is that called? You know - those things that denote some sort of truth value that indicates membership in a set. The flippin' WHERE-CLAUSE thingys in an XPath. Jeez - you know what I mean anyway - why is it this hard?
It's called a predicate. I knew that - really!
Some words don't stick in my brain. I used to try to conquer this problem by solving crosswords, but then you end up with crossword compilers with warped minds. I recall being driven to distraction by one crossword clue which used gambolas a synonym for capriole. How can you cope with that?
Fizzbin
Scott Hanselman just posted this: http://www.hanselman.com/blog/FizzBinTheTechnicalSupportSecretHandshake.aspx
Tongue-in-cheek or otherwise, the idea makes me smile, and I can't help secretly hoping that it could work. Yeah sure, it's a secret, right! Just don't tell anyone who shouldn't know. And of course, all the support guys will instantly trust you as soon as you say it.
Powershell profile for Tridion development
My powershell profile for Tridion and general .Net development
I have recently stopped using a local vmware image on my laptop for development work, and instead I now use an image hosted on a proper vmware server at the office. I pretty soon discovered that I needed the vcvars script from my other powershell profile. As it took me ten minutes to load up the old image and copy the profile, I figured I'd post it here for future reference. The good bits nicked from elsewhere are credited inline.
Edit: The aliases for the compound templating uploader didn't really work, so now I have a function for this.
# http://www.leastprivilege.com/MyMonadCommandPrompt.aspx
function prompt { "PS " + (get-location).Path + "`n> " }
# http://www.interact-sw.co.uk/iangblog/2007/02/09/pshdetectelevation
& {
$wid=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$prp=new-object System.Security.Principal.WindowsPrincipal($wid)
$adm=[System.Security.Principal.WindowsBuiltInRole]::Administrator
$IsAdmin=$prp.IsInRole($adm)
if ($IsAdmin)
{
(get-host).UI.RawUI.Backgroundcolor="DarkRed"
clear-host
}
}
# http://www.leastprivilege.com/AdminTitleBarForPowerShell.aspx
$id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$p = New-Object System.Security.Principal.WindowsPrincipal($id)
if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
{
$Host.UI.RawUI.WindowTitle = "Administrator: " + $Host.UI.RawUI.WindowTitle
}
# http://www.tavaresstudios.com/Blog/post/The-last-vsvars32ps1-Ill-ever-need.aspx
function VsVars32($version = "8.0")
{
$key = "HKLM:SOFTWARE\Microsoft\VisualStudio\" + $version
$VsKey = get-ItemProperty $key
$VsInstallPath = [System.IO.Path]::GetDirectoryName($VsKey.InstallDir)
$VsToolsDir = [System.IO.Path]::GetDirectoryName($VsInstallPath)
$VsToolsDir = [System.IO.Path]::Combine($VsToolsDir, "Tools")
$BatchFile = [System.IO.Path]::Combine($VsToolsDir, "vsvars32.bat")
Get-Batchfile $BatchFile
[System.Console]::Title = "Visual Studio " + $version + " Windows Powershell"
}
function Get-Batchfile ($file) {
$cmd = "`"$file`" & set"
cmd /c $cmd | Foreach-Object {
$p, $v = $_.split('=')
Set-Item -path env:$p -value $v
}
}
set-alias -name rat -value RestartAllTridion
function RestartAllTridion
{
"### Restart All Tridion ###"
"Stopping All Tridion services"
service TC*, Tri* | stop-service -force
kt
"Doing an IISRESET"
iisreset
"Starting all Tridion services"
service TC*, Tri* | start-service
"### Done ###"
}
set-alias -name kt -value killTridion
function KillTridion
{
"Shutting down Tridion COM+ Application
$COMAdminCatalog = new-object -com COMAdmin.COMAdminCatalog
$COMAdminCatalog.ShutdownApplication("Tridion Content Manager")
}
set-alias -name upta -value uploadTridionAssembly
function uploadTridionAssembly {
& 'C:\Program Files\Tridion\bin\client\TcmUploadAssembly.exe' /verbose config.xml $args[0]
}
HTML Validation: does it matter?
Jeff Atwood doesn't think we care if his site validates. Is he right?
In a recent blog post, Jeff Atwood of Coding Horror gives this advice:
It's something of a geek disease to obsess about valid markup, but what does do you get for the effort that it takes to achieve it?
On my current project, we started with a requirement from the customer that the site should validate as XHTML strict. There was some discussion about how much effort this would take to achieve, but in the end we agreed to begin work on this basis, and to take the various difficulties and issues as they came. At the time of writing, we're just about to go into acceptance testing, and the site still validates completely as 'strict'. What has this meant in practice?
Firstly, there have been compromises. Well actually, one compromise of note: the abandonment of using the target attribute to control the types of window used when following different kinds of links. This means that we've resorted to using javascript to open new windows when necessary, and that the small minority of non-javascript visitors will simply find that their browser navigates to the new link in the same window. (Personally, I don't mind that; it simply means that we're regarding popup windows as part of our progressive enhancement strategy. This is reasonable - the native behaviour of web browsers is that links open in the same window - get over it!) The only other thing I can think of is that we're still not sure what the mime-type of an XHTML page should be.
That's the sum total of the differences it's caused from an external point of view. As Jeff says: Nobody cares.
Internally though, as a development practice, it's been pretty useful. Jeff's reasons are good, but I'd add one specific point. Your CSS relies very heavily on the browser being able to validate the DOM correctly. Building in a practice that the developers doing the HTML templating have to validate their output has had a direct impact on the number of CSS bugs and problems that we've seen. This is particularly true when you have cross-browser issues to deal with. The guys are supposed to test on IE and Firefox, but mostly we work in Firefox, and sometimes IE gets forgotten, which usually ends up ten minutes later with someone noticing that the visual output in IE is broken. Validating the HTML from the Web developer plug-in in Firefox is very easy ("Tools-> Validate Local HTML" works very well, as the site isn't currently visible to the w3c validator)
Whenever any issue comes up that's connected with the visual display or layout of the page, the first thing we do is validate it again. Most of the time, the HTML turns out to be broken, and at that point we turn our attention to fixing it. Previously, we might well have invested unnecessary effort on trying to debug the CSS. So in this sense, validating your HTML is akin to paying attention to your compiler warnings. Disciplined developers who keep their output free of warnings, are immediately alerted to real issues because they aren't swamped in the warnings generated by all those things that weren't important enough to fix.
In the grand scheme of things, standards generally help. Long term, and over time, that is. In the short term, well the history of the web has shown that if you need to get results today, well don't wait for the standards to be widely adopted. The downside is that we have to live in a world of browser incompatibilities and just accept the extra work that this causes. So yes, I want to be standards compliant, but only once the standards support the functionality I want to create. Validation matters, in that it without standards, nothing ever gets better, but it costs us effort that may not give us a personal short-term payback. A classic tragedy of the commons.
It's easy to make things bigger; it's harder to make things better.
Doug Crockford recently said: "It's easy to make things bigger; it's harder to make things better.". I agree.
Architects and programmers
I spoke briefly yesterday with a colleague who is busy setting up a team whose focus will be developing architectural competences within the company. During our conversation, I expressed my view that architecture is a basic core competence for a software developer. I hope I managed to make it clear to him that I do regard architectural concerns as a valid and valuable field of enterprise within the development of software systems, but just in case, and for the record, I'll try to write down what I believe to be the truth about this subject.
Firstly, let's talk about the problem, which is that in the world of computer software, architecture has become rather a loaded term, and is perhaps abused by various interest groups to suit their own ends. This isn't new: for as long as I can remember there has been a sort of job title inflation in our business. These days, it's not enough to be a programmer any more, although once we might have regarded all sorts of capabilities as being implied by the term. (Perhaps programmer just means lowly coder, as though there ever was such a thing. Surely, there are competent programmers and those who are less so.) Then we had to be analyst-programmers (APs), and perhaps the invention of that title meant that programmerdidn't imply analyst any more. At some point, people seemed to get the point that unless a programmer was an analyst too, you shouldn't hire him, and the whole AP thing dropped out of fashion.
Nowadays, you have to say software developer, which apparently implies analyst, while maybe 'programmer' didn't. Strangely though, it doesn't seem to imply that you need to understand architecture. That's kind of funny, because the technical career path sort of goes, junior developer, developer, senior developer, architect... Did you notice that? You suddenly transmute from programmer to architect - funny, eh? I can see why this might be. After all - once you are a senior, where do you go from there. Where's your career development path?
In the world of bricks and mortar, no-one calls a bricklayer an architect, but the person who designed the house you live in is almost certainly an architect. In general, the architect is responsible for taking the customer's requirements and transforming them into a concrete (!) building or other such developement. This means discussing the customer's needs, understanding the available materials, techniques, etc., creating a design, and overseeing the construction to ensure correct construction in line with that design. The notion of architecture also implies an overview, and a sense of aesthetics applied to the construction as a whole in the context of its environment.
A bricklayer by contrast, is more of a craftsman. Bricklayers understand things like bonds and cement and gravity and straight edges and so forth. They have technique, but people don't see them as designers, even though they are probably responsible for design in the small. Of course, a computer programmer is a craftsman too; he must wield his programming languages in an artful way, and choose among possible implementations of a larger design.
That's about where the analogy breaks down though. Learning a few programming languages and being able to write in them probably fits the job description of a junior programmer. Most of the work of a journeyman programmer is far more involved. He talks to end-users, customers or product managers. He understands the requirements and produces designs which reflect the available techniques. This includes far more than simply coding. If we take the example of a programmer working on a typical web application, he may very well produce and implement designs which require knowledge of relational databases and how to produce an abstraction layer to access them, (including perhaps the use of object-relational mapping tools). Then there's probably an application server, transaction management and issues regarding state (or the lack of it). Then there's presumably a web server to deal with, and more choices about statefulness, including session management, and perhaps the need to cluster. Onwards to the network layers, where he'll need to understand TCP/IP, firewalls, proxies of various kinds, DNS, HTTP, encryption and certificate infrastructures, Web services, REST..... We're getting somewhere near the browser now, so there'll be AJAX, Comet, HTML, XHTML, Javascript and CSS browser hacks.
Well I'm sure you get the picture. My putative programmer probably not only has to understand this all on paper, but needs to know how to put all the pieces together with his own bare hands, and we haven't even started on development techniques and methodologies from waterfall to agile, version control, continuous integration, project management, design patterns and how to tell snake-oil from cargo-cult lunacy and both of them from the real deal.
An now after all that, when he finally takes the career step to pick up a business card that says "architect" on it, we shouldn't be surprised that he begins with at least some small clue about what's going on. The strange thing is that when I baldly state my view that architecture is a core skill for programmers, well you wouldn't believe the number of times I get contradicted.
Without a solid understanding of architectural concerns, you are not a programmer. Any real architect understands this, but unfortunately, I've seen far too often the kind of conversation that goes like this:
Programmer: Let's discuss the architecture.
Architect: I'm the architect, why would there be a discussion?
Over the years I have known several software architects who could and did write code to express their ideas and prove their concepts. For these people, a discussion of architecture with a programmer was not a threat, because when the programmer inevitably asked "How does it work?", they would be able to demonstrate,.
Unfortunately, the other kind of "architect" in this scenario usually doesn't have the ability or the inclination to express his proposed architecture in working code. Unless you have the ability to express your proposed architecture in working code, it is supremely unlikely to work. I'd go further than that and say that the best way for an architect to convey his design to a programmer is exactly that; working code. This may be just a basic proof of concept, but unless the architect has written the proof of concept code, he hasn't done his part of the job yet, and if he has written it, why shouldn't it be a deliverable. You may laugh, but I've observed so-called architects in the wild, and seen technologies selected from a brochure without so much as a trial run, and foisted on programmers, who then had to get everything to work.
You learn software architecture by being a programmer. Becoming the architect doesn't absolve you from maintaining the ability to get it and keep it working. Far from it.
Before anyone goes running off with any strange ideas, let me be very clear. I don't have any problem with software architects. (Some aspects of my work are fairly accurately described by the term.) What I'm railing against is the way that the job title has been assumed by large numbers of people who seem to think that this puts them above the need for achieving technical consensus about what will work and what constitutes good practice.
Am I talking about you? Ask yourself this simple question: Is architecture a core skill for a software developer?
