Architects

"So no, we don't hire architects. We hire developers. In a small team, there is no room for management deadwood."

 

 

 

 

Tags:

    tags:

5 Comments


    The image path is broken, you forgot one level of going up. Plus, going to its current URL, one can see that you have DEBUG set to True in your Django deployment. You don't do that on da intarweb! ;-)


    Nicola, yeah, my tinymce does that for some reason. Fail! But DEBUG=True is only because I rock at debugging live systems; that gets turned off eventually ;)


    So, does that mean you agree with the sentiment? That architects (that is, people who should be experts at making system wide trade-offs, guiding the technical direction of development efforts and documenting those decisions) are simply "management deadwood"?

    I can see how a small team might think it can get by without expertise in all of these, but any extended development effort (e.g. bugfixes or enhancements a few months after rollout) is going to need an accurate written version of how the system actually works and how it should work in future. That documentation better also give the whys and why nots, so the maintenance/enhancement team doesn't blunder into the same dead ends the original team did. Demanding good reasons for decisions, and getting good at writing these explanations down is what software and systems architecture is all about. Helping the team have a common set of terms for what they're doing, and matching them to what the users know also helps.

    The biggest problem I've seen with some software architects is that they haven't yet gained the expertise in documenting their decisions, and then aren't around to guide development as it goes. This is just the sort of problem that only having a small number of architects in a midsize to large company would lead to, as those architects are continually being pulled into starting up new projects. This means that this particular group of architects never see what pain their decisions have caused, and never they get to learn from their mistakes.


    Let me point out that Information Architect (IA) position is not a development position but a User Experience Design (UXD) one. I objected to the position inflation over there too (I preferred Interaction Designer), but it wasn't my department.

    On the "large company, few architects, poor documentation" question, I think documentation is of limited value (see "Agile Development, Documentation and Bringing Projects back from the Dead" at http://blogs.pathf.com/agileajax/2008...) without an ongoing, living, breathing development team. And that documentation written by developers who have ceased getting their hands dirty (read "Architects") tends to be more useless than most.

    Those big EA departments springing up all over the place are very reminiscent of the PMO groups that get formed and fired every few years at those same big companies.


    "So, does that mean you agree with the sentiment? "

    Richard, I do agree. I've seen cases where architects can add value, but like Dietrich I think you're generally better off pushing design decisions down to the people who build (and test) the software. My ideal model for a software architect isn't a building/works architect, it's more like the Chief Engineer role held at Toyota.

    "Let me point out that Information Architect (IA) position is not a development position but a User Experience Design (UXD) one. I objected to the position inflation over there too (I preferred Interaction Designer), but it wasn't my department."

    Hi Dietrich! I took the quote because I loved it. It has more punch than Fowler's 2-architects taxonomy, and I hope it gets picked up. Putting the picture in there - I couldn't help myself. Sorry :)