Thursday, May 12, 2005

Architect: Person, Role, or Useless Appendage?

There is a good thread going (or was when I started this) on at TheServerSide.NET about "What Skills Should a .NET Architect Possess?" The correct question might be whether or not an architect is different from a senior developer. More importantly, how does the architect (or analogue) interact with developers? I've been (stranded) on both sides of the fence on this question and I'm still ambivalent, so I'll let everyone else decide.

At one pole is the heavy process waterfall shops with elaborate responsibility matrices. Architects do all the design upfront in comprehensive documents and developers code what they're told. It doesn't really work that way of course. When I was an architect (at least in name), I wasn't allowed to code. I was told that I was "too important to code." I wasn't important enough to be paid well, but just important enough to do lots of powerpoint presentations to kick off projects that were cancelled within a month.

On the other hand, I walked away very unimpressed from my first and only true Extreme Programming project. Doing the simplest thing that possibly works, with little or no emphasis on architecture or even design at all, can lead to truly awful code. I felt we consistently missed opportunities to become more productive by just stopping to think once in a while. We missed abstractions that could have helped us go faster. We waited to refactor to use an abstraction after it became pitifully obvious the abstraction was necessary. Refactoring is good, but there is no such thing as a big refactoring. Big refactorings are just rework.

A terrible amount of code was duplicated because every pair was so focused on their own stories. Pairing and rotating helps, but you're still only working on a user story at a time. Even worse is the fact that user stories are dribbled out to the developers, so there doesn't seem to be any way to get traction on a coherent design. Important concerns like instrumentation, data access strategy, operational support, and security can easily be lost in the hustle and bustle of trying to make the iteration.

I don't believe in very many absolutes (always do this, but never do that) in software development, but here's a couple I do believe:

  1. Non-coding architects create terrible architectures. If you can't code it, you certainly cannot design it. I had to come from behind one of my architect peers on a large project after he had been more or less been kicked off the project for being a pain in the rear. The project manager just looked a little dazed and said, "It was going so well at first. He was producing so many design documents and then..." Development just changes too fast to do the beard stroking architect thing. Turn around twice, and your COBOL/VB6/Pro IV skills have been passed by. It was pretty scary being a non-coding architect in early 2003 with no production .NET or J2EE experience.
  2. Development is often all about responding to feedback. Feedback from your code when you realize your design isn't ideal or a different approach proves superior, feedback from performance data, and feedback from the business people as they refine their understanding of their needs. Feedback needs to be acted on quickly in order to be valuable. Small refactorings done as the need arises greatly streamlines the code. Big refactorings put off lead to nightmares. Developers who aren't able to deviate from a bad design because of a lack of skill or authority are more or less helpless to create good code. Both times I've been the recipient of a design spec from someone else the "design" was tossed out as completely unworkable.
  3. Spec coders suck and cannot create any kind of non-trivial software. Being a spec coder sucks even worse. Being a non-coding architect working with spec coders is a living nightmare no one should have to endure. I've found to my chagrin that the more detailed your instructions are to another developer, the worse code they create. Give the same developer more leeway in their approach and maybe some amount of coaching, and their code is consistently better because they're thinking while they code. Everybody should be involved in design to better understand why they're doing what they're doing.
  4. Design should be continuous. I like Jim Shore's article on this topic. The key is to always be thinking and challenging your design and never get complacent. Keeping somewhat in line with agile ideology, do think ahead and anticipate needs and risks, but don't act upon them earlier than you need to. I'll blog much more on this some day. I don't really fit into either the XP or RUP crowds in my approach to design. It's the year 2005, the discussions should have moved on from "waterfall or iterative" to "how best to do iterative development" a long, long time ago.
  5. It's very advantageous to step outside of the current batch of stories or code and look at the bigger picture. If that requires tagging someone as the designated architect, so be it.
    You better have somebody (preferably plural) with real technical design skills involved with the coding effort on a daily basis.
  6. Regardless of process or approach, design skill is vital. Being able to quote Chairman Beck's little white book with a gleam in your eyes does not count as design knowledge. A working knowledge of design patterns and the fundamentals of good design can actually contribute to the success of a project. If all you know is write "if/then/else" statements until the NUnit tests pass, your version of the "Simplest Thing Possible" is probably a bad design.

"I feel better now, thank you for listening" -- Roy Moore

0 Comments:

Post a Comment

<< Home