I would be very interested in hearing more about the distinction between managing innovation instead of widget building. On a very related note, managing processes centered on creative tasks, such as Graphic Design work.

Is there really that big a difference between managing someone who turns a bolt as it passes on an assembly line and someone who writes code of a living? If the requirements are solid, isn't the coding just a mechanical task in the development lifecycle?

Any thoughts? I would really appreciate any references people have on this subject.

-- Anonymous, April 24, 2001

Answers

One big difference is that software exists only as a intellectual artifact. It has, generally, no physical representation. This means that managing a team of software developers to a large part involves ensuring that everyone on the team shares the same understanding, the same vision of what is being built. Requirements are a tool to make that happen, but even solid requirements do not define the final product 100%. They only define the requirements that it must fulfill. The team as a whole must share a common understanding of those requirements, as well as a common understanding of the software that will be built to fulfill those requirements.

-- Anonymous, April 24, 2001

Ok, I agree that requirements don't describe the final product 100%, but maybe the specifications (design work) do describe what is to be built during coding. This is much like a blue print. It describes where the nails go when framing. The carpenter doesn't decide on the job site where to put the walls, or what the walls should be made of. This is the job of the architect.

This is true of software development as well. The design architect decides what functions and methods should be present, then the coder should implement the specifications provided by the architect.

The idea that coding only produces an intellectual artifact doesn't seem to hold water to me. There IS a physical product that is produced. We can review that product for correctness, just as we can for a widget. We can version control it. We can own it. We can detect defects with it. We can do all of this after the intellectual product has been produced. There IS a deliverable we can possess, inspect, and modify.

I disagree with the concept of the entire team needing to understand the entire project. The project can be broken into smaller pieces and the team member needs to only understand that portion of the project they are responsible for coding. We can give some of the specifications for the printing portion of an application and they don't need to understand the business logic behind the calculations within the application. The business logic can be handed to a completely isolated group of programmers to be built. A common vision is not required and only causes time to be wasted on the project in question. Why do the printing coders need to communicate with the business logic coders, if the specifications for the things to be built are clear and detailed.

At the heart of this issue, to me, is the following question: why do programmers insist that coding is creative. It is the design work that requires creativity. Programming is simple and mechanical. "Build a function that excepts 3 integers, adds them together, and returns the result." Nothing creative to that.

My example is too simplistic. I know it. But it is useful to demonstrate that coding is NOT creative.

No one really gets requirements like that. So, lets take it more abstractly. "Build a class (or object) that has the following methods that implement the following business logic and process." Now the structure of those methods and processes should be documented during the design phase. At no time during coding should decisions be made about methods being added to objects. This implies poorly written design specs.

In good Object Models, the methods are defined, as well as the algorithms to accomplish the tasks. The interaction between the objects are defined. Whether a method should be public or private, inherited from the super or overridden by the child.

The problem is that most programmers design as they code, making the line very confusing, and HARD TO MANAGE.

Anyway, just some thoughts.

-- Anonymous, April 24, 2001

Do you have perfect architects?

-- Anonymous, April 25, 2001

>My example is too simplistic. I know it. But it is useful to >demonstrate that coding is NOT creative.

Would it be accurate to day that in your idea coding shop, if you could have a machine that translated specs into code, you would fire all your developers? if coding is not creative, you don't need people.

If we came up with some way of writing specs so that a machine could understand them (ex. XML using a not-currently-available 'spec shema', something like 'specML'), then you could write a piece of software that took your XML'ed spec and spit out code in whatever language you wanted.

The XML-to-code software would be the last piece of software you would need programmers on-hand to write. Once it was done, you could fire them all, or at least the bulk of them. You might want to keep a few on hand to maintain the machine.

Machines are easier to manage, and they scale better then people.

-- Anonymous, April 25, 2001

Ed, I think you have hit my point very closely. The only thing I would change in your response is this: I would not fire all my programmers. I would cross train them into spec writers. Have them doing the intellectual work of writing interfaces between objects and systems. Have the developers spend time designing objects and systems, instead of coding them.

I completely agree with the AUTOMATED nature of coding. How much Assembly coding is being done now compared to 4GL's like Powerbuilder or VB? We have been able to abstract coding, why not take it the next step and write designs that generated into code.

Again, I don't want to fire the programmers, I want to empower them to spend their time doing the architecture work instead of the swinging of the hammer. Of course, not every developer is ready for this power and responsibility and my ideal organization would have to trim those developers unable to design out of the organization. Turn them into testers?

I do think we have started to talk about automated coding, and I was really hoping to get some input on managing innovative tasks, such as design work. I believe it IS different to manage this type of work, but I can't articulate the difference very well. I would like to be able to add some structure and definition to statement that "Managing innovative work is different." Why is it different? What are the unique challenges faced by these tasks and people?

-- Anonymous, April 25, 2001

If the programmers are working in a language that's sufficiently powerful that the only things left to do are at a high level (decide on objects and methods and algorithms, like you said), would there be any difference between code and design?

What if some languages are already high-level enough for that?

I like the ideas you're suggesting - automate low-level stuff so that the programmers are free to work on higher-level stuff. The programming world has been moving in that direction ever since it started. Do you have ideas about which kinds of details can be next to be automated away?

I don't have much to add about managing innovative work. Everything I know about it, I learned from Peopleware. :) I assume that if you're here at Joel's site, you've read it.

-- Anonymous, April 25, 2001

People get very tied down with job function names, and programmer is one which ties most everyone in knots. Back when I started a programmer was someone that translated an analyst's design into code. That code was invariably a small unit in a whole humongous system and only interfaced with other units through files. User interfaces were non-existent.

At that time the supposed career path of a programmer was to analyst programmer, then into some kind of management. The creativity a programmer had in converting the analyst's design into code was minimal and generally at a syntactical rather than grammatical level. That is the more experienced they were with a language the more tricks they could bring to bear.

Programs at the time were leviathan, slow and pretty clumsy. There were no tools to improve performance or give an idea of correctness and the best work habit a programmer could acquire was good desk checking (mind, that's _still_ the best habit).

Before my time, when computers were valves, programmers were closer to technicians working on particle accelerators than manipulators of objects and properties.

And now? A programmer might be a VB form designer whose only direct experience writing code is having to put wrappers around event firing to get other components to work with their form; or they might be writing protocol engines that take some dialect of XML and spit it into relational tables or vice versa; or they might be implementing interfaces using XPCOM, DCOM, CORBA or whatever and having to deal with data marshalling and semaphore problems; or and so on.

So perhaps you might think that any of these or the multi-various other definitions of what a programmer is, could be analogous to a production line worker. If you do then you also need to ask yourself what creativity should a production line worker have?

Certainly not the creativity to turn the bolt round the other way or replace it with one of an entirely different diameter or thread width.

Perhaps the creativity though to recognise that using a different length bolt would improve workflow or perhaps that a bolt is entirely the wrong fastener for the material. Ah, now you probably doubt that the production line worker could possibly know enough of the context of the work to even arrive at those solutions?

If you do then you also doubt (given everything else) that your programmer has anything meaningful to say about a design as a whole or even whether a design is viable or not.

I would say that both the production line worker and programmer, and any other person involved in a process, should have as much information and context of the work they have in hand as they ask for and where possible they should be encouraged to do the asking. Its no accident that productivity in any process can be improved simply by the different stages in the process knowing more about not only how they interface with their neighbours but also why their neighbours are the way they are.

Empowering people, whether they are programmers, charge hands or secretaries is a Good Thing. Job demarcation, whatever its cause is invariably a Bad Thing. The smaller that organisations become ( and the trend is to become very small indeed), the more important it is to employ people rather than job functions.

Hmmm, this has become very long...

Simon

-- Anonymous, April 30, 2001