Fog Creek Software
Discussion Board

Design and implementation as separate roles

From the recent CAMEL discussion, Nat Ersoz said "It will be a cold day in hell when I code something that someone else "architected".  Likewise, if I have to write the spec, then I might as well spend the remaining part of the day writing the code."

I've traditionally taken the same design-to-code-in-one-day approach as Nat, but am considering taking a new job with clear separation between the design role and the implementation role.  My job would be to do the design and then hand it over to an on-site contractor to implement.

At first, I worried that I'd miss the satisfaction of coding my own designs, but the more I think about it, the more I like the thought of not having to shift gears so much.  Because I would do less transitioning from high-level to low-level, I could actually get more done, and have a more focused, comprehensive approach to development.

As I've practiced honing my design skills in preparation for this possible job, I've noticed that having to put down on paper "trivial" things where I would traditionally have jumped straight into code helps me to spot conceptual gotchas a lot sooner.

Of course this level of rigor comes at a cost.  What are your thoughts on the kinds of projects that justify this degree of separation, and what are issues to look out for when different people have different roles? (The "cold day in hell" response, etc.)

Friday, March 14, 2003

Often, designers will create a reference implementation of their design to prove that it is implementable.  I know the W3C won't release a spec as final until there are at least n (can't remember the number) implementations.

On a separate note, I have heard Steve McConnell talk about this (apparently, MS did it for a while with Master and Slave Coders) and he says it's horrible for morale.  Well, for the slaves anyway.

Friday, March 14, 2003

I read Nat's "remaining part of the day" more as a figure of speech than as switching roles on the same day. When I work on a new subsystem, I spend 30-50% of the time planning before I write any production code at all. This sometimes goes on for a couple of weeks or more. Then I switch roles and write code most of the time. I imagine if I had to hand over my spec to a coder, I'd have to spend much longer on it, because there are many details I don't need to put in there because they don't concern anyone else but me as a programmer and architect.

The good thing about having two separate people working on the system is that two heads think better than one. But given the fact nobody wants to be a code slave, and it only makes the architect's job more cumbersome, I'd prefer two all-round developers.

Big B
Friday, March 14, 2003

Well, yes, I used some exageration - it was to make a point.

I often code to a specification - in fact most of my work is that way.  I have hardware data sheets from a manufacturer, and I have ITU, ISO and IETF standards/RFC's to code to (among others as well).  So I'm no stranger to coding to something defined outside of my own realm.

However, these are not software architecture designs by individuals in secret rooms.  They are open standards designed by comitee.  This is something completely different that having some architects appointed within a corporate structure with the intent of telling someone what to do.

Additionally, it should be expected that individuals will have skills that are specialized and will be more proficient within a certain context than others.  Each individual should be taking part in the design discussion, especially when they are known to be skilled in a specific art.

I'll put forth the hypothesis that any engineer will to be a code slave is not worth having on a team.  That certainly has been my experience.

Nat Ersoz
Friday, March 14, 2003

Nat, I think we're coming from very different business areas.  Business software design can be a lot less straight-forward than things that have clear-cut standards to code to.  If I'm implementing networking protocols for a wireless device, I would expect as a coder to understand far more about the big picture than if I were coding part of a huge line-of-business application.  I would also expect to participate more in design discussion as a networking programmer than as a business programmer.  I would be far more likely to refer to coders on a networking device project as engineers than I would coders on a line-of-business project.  Working as a coder on a large line-of-business project would probably drive someone with the "engineering mind" bonkers.  There's a valid place for both kinds of programmers in this world, but it's often hard for people on one side of the fence to understand that about the guys on the other side.

Friday, March 14, 2003


Let me turn the tables and ask you a question -- What are your thoughts about this position?

The following are questions that I would like to know something more about before commenting on your question:

* What type of design work are we talking about here? Modeling large object-oriented business systems?

* Is design work going to be your ONLY responsibility? What about analysis and requirements work?

* Does the company have enough "new development" work in the pipeline to keep you busy for the next couple of years?

* What tools and technologies are you expected to know/use?

* Have you ever designed a large "corporate enterprise" business system before? What I mean is do you feel you are qualified to do this type of work?

My only comment for now is -- If I was looking to specialize in something,  I don't think I could ask for a better job than what you might be doing soon.

Let us know what how things turn out for you.

One Programmer's Opinion
Saturday, March 15, 2003

In answer to OPO's questions:

My thoughts on the position are basically that it is my ideal job if I'm actually able to perform.  But if I can't perform then I shouldn't waste their time and mine.  It's a tough call to make because it's not an easy job for me to to quantify from what I've been able to learn so far.

I would say the design work involves small to mid-size object-oriented business systems.  But they expect several of them to be on my plate at once, with an eye toward eventually creating one unified system from some of them.

There will be requirements gathering and analysis in addition to design, but I chose "design" as the representative word to keep the discussion as down-to-earth as possible, given some people's aversion to anything remotely related to the word "architect".

From the plans they've talked about, there is no shortage of projects for the foreseeable future, from SCADA to maintenance management to accounting and everything in between.

They seem quite dedicated to staying cutting-edge, and perform extensive analysis of new technologies as they arrive.  New development is currently focused on .NET with Oracle back-ends, but they have some Java and other technologies in their past, and they aren't afraid to change gears quickly, which I believe is part of the reason they contract out almost all implementation.

They haven't emphasized any particular development methodology.  In fact they've emphasized that they really feel that software development is more of an art than a science, and therefore value people who have a good intuition more than they value a particular brand of methodologist.  As long as you're able to produce, it doesn't matter how you get there.  We did cover software engineering and project management topics fairly extensively, and I think we see eye-to-eye for the most part, but I would probably have a fair bit of leeway as far as design tools and techniques.

I haven't designed a large business system before as far as big-bang design goes, but I did spend several years iteratively designing and building a mid-size system that nobody knew was going to grow to deal with all the different business areas that it did.  I would say it ended up being enterprise-wide in scope by the time it was done.  It was in a similar line of business as the new job opportunity.

One of the non-technical things that appeals to me is the opportunity to specialize in a business that deals with a wide range of roles, from the maintenance mechanic to the engineer to the more traditional information worker types.  I think working to meet the technology needs of that range of people in a unified way is a great opportunity to grow.

Saturday, March 15, 2003

This idea of splitting design and implementation roles has a few major drawbacks as I see it. Most large corporations have their share of designated "system architects" or "database architects" or what you want to call them. For the sake of the argument they are all designers.

Then, you have a buch of coders, that code from given specs. If you come in as a new coder and you are spoonfed completed specs you can not easily build up a full understanding of your platform, because you never get to excersise it to the fullest. Its when you design complete solutions, and then implement them you really learn the ways of working on a given platform, and a given tool.

This being a designated coder maybe works for relatively inexperienced coders, that are just starting to work professionally.

Also, if you have a group of designated designers that do specs, they sometimes seem to justify bad design descisions with being "superior" to coders. With database designers for example, having done tons of DB2 stuff does not automatically make you a good designer for Oracle. The way the databases handle non-trivial stuff differs.

The design of a new system is always a series of tradeoffs, and if the person doing the design is not very proficient with the tools/platform being used you are in for surprises.

I have seen cases where the coders would make better designers than designers because they have a better hands on experience with things.

I think working together and taking the best design that can be thought up between designers and coders, is what is going to work best. Either split things up, or have the designated designers take part in the implementation process as well. A designer of a system is not finished working when the spec is done.

Saturday, March 15, 2003

I'm not sure what I've been saying that's giving off the large company vibe, but the job I'm talking about is in an IT department that I'm guessing has less than a dozen people in it, including management, network admins, and DBAs.  They seem to have made a conscious effort to keep themselves lean and mean despite ongoing application development work.  I believe this is the exact opposite of the type of place that people are characterizing when they put double-quotes around the word "architect".

If I were to take this position, I would do my best to involve the programmers in any relevant design decisions and definitely in time estimates, but because they're all contractors there's an extra layer of separation I'm not used to dealing with.  They have some truly brilliant programmers working for them, so I'd like to find ways for them be as involved as possible.  Perhaps I'm seeing the separation of roles as more drastic than it actually is, but if it really is that clean-cut then I need to find a way to deal with it.

Saturday, March 15, 2003


Maybe separation works if done right, maybe I have just seen poor implementations. Nothing you said really led me to believe you were talking about a big company. My experience led me to that, because when I worked for smaller outfits (10-30 people), I have not seen this splitting done to the extreme.

Ofcourse even the smaller places had people that were given titles along the lines of Senior Develper, Lead Programmer, Designer and what have you, but this was mainly just titles. We were working as a team always, and  whats important is that the most informed member of the  team is making the descision for a given design issue.

In other places I have seen developers are forbidden to make design descisions, add a table, talk to the DBA. Add a field in the table, justify that change with the DB designer - I can understand that some companies enforce such strict rules in their production systems, but when applied to development,  this leads to territorial fights and is harmful.

I guess its simply a matter of how you implement  the system. After thinking for 30 seconds, the key rule seems to be that the most informed person in the team should make the descision. May seem like this almost goes without saying, but the role separation is malpracticed in some places.

Saturday, March 15, 2003

Sure... the larger the group and the more the group fragments into titles of speciality and the greater the social prestige of those titles, the more dysfunctional the group becomes.  The greatest dysfunction occurs when the group adds to its numbers just to continue its existance (e.g. job security illusion).

The distribution of responsibility for something like design and implementation is not necessarily bad by itself, but becomes so when "conceptual intergrity" as defined by Fred Brooks becomes impossible to achieve.  At this point, all projects and implementations can rightly be called failures.

Joe AA
Saturday, March 15, 2003

From the point of view of the business, you have to understand the economics of the organizational scheme you choose.  It does no good to say "specialization is best!" or "generalizing is best!!" or any of that until you understand your goals.  Each kind of organization is designed to optimize some goal.

If you choose what is usually called "the functional team" approach, you choose specialization as your primary organizing principle.  You have a bunch of finance people on the team called "finance" and you have a bunch of engineers on the team called "engineering."  Similarly, if you choose the purley cross functional approach, where you have autonomous teams staffed with a variety of skillsets, you are choosing generalization, or breadth, as your primary organizing principle.

The first kind of organization strives for efficiency of each functional unit though economies of scale within the unit.  The tradeoff is that this kind of organization is relatively slow due to relatively lean communication links between the functional areas and lack of visibility across the areas.

The second kind of organization strives for speed.  This comes at the cost of reduced quality (in general) and inefficiency.

Recently, hybrid teams have resulted in what's called "matrix organizations."  These posses either the best qualities of each of the other types or (more often?) the worst.

If you are a business, you need to decide what your goal will be and organize your resources accordingly.

When you are choosing how to develop your skills, you have to look at the market for each of these kinds of organizations and plan accordingly.  Assuming, of course, that your main goals are economic.

Saturday, March 15, 2003

We do similar stuff here. Issues are:

1. We employ (or try to) expensive software engineers to, effectively, turn word documents, (those well known formal specifications of software) into source code. This is because employing cheap ones means you get non-working source code. Those expensive software engineers get bored in approximately a few months. So there's an on-going replacement cost.

2. There's the tendency to turn intermediate artifacts into important things.

3. No-one can actually tell when the programming-in-Word is done, because it doesn't get tested. Which implies that documents are "completed" on the day they are due to be completed, however completed they are...

4. What happens is that the word -> code -> executable compilation stage fails, at which point we have to back up and force people to add to the Word stage. This is, somehow, always the fault of the "Word->code->executable" programmer, and comes off their time budget and not the fault of "Word document" programmer.

5. The stages end up not overlapping. The coder won't start work until the design is complete. This means your shortest work path is at least as long as the sum of the stages. In integrated development, bits of the work can overlap.

6. The way we solve 5 here is to cut the work up into tiny, tiny pieces. This means one lump can start work before others have finished coming down the waterfall. It also means the coders can't use knowledge about the whole system's requirements to produce re-usable libraries of code or anything like that...

7. The "Word" programmer doesn't need a computing education, so can be recruited as junior staff.

8. There is a temptation to regard the informal Word -> formal C++ translation as "merely mechanistic", and to try to optimise the process by macdonaldising the development team. This causes real problems because now neither the code designer or the code writer now know what they're doing.

Isn't it great when people who have no idea about software processes design a software process.

Katie Lucas
Monday, March 17, 2003

My point of view is that people that don't understand processes in general are designing processes.  Anyone advertising a "standard process" is someone to avoid.  There is no optimal process, only processes that are optimal for a given objective in a given environment.  You can standardize the tools somewhat, but is you standardize their interaction, all you do is optimize the status quo.  Any change to the environment and suddenly your gem of a process is systematically undermining your ability to compete effectively.  The nice thing, though, is that your competitors are probably doing the same :)


Monday, March 17, 2003

Katie:  Ugh ugh ugh.  That *sucks.*

Excellently described, though.

Brent P. Newhall
Tuesday, March 18, 2003

*  Recent Topics

*  Fog Creek Home