Object Oriented Management

Mix software design with management theory.

Many managers seem to think they could write code better than their programmers. Let's give them the chance--but in an abstracted way. Think of it as coding the organization.

"but in an abstracted way". I'm thinking, "Lead, don't do" ... maybe I'll camel that into LeadersDontDo; I can spin off 3 good directives in 5 minutes but they might take (say) 24 pgmr/hrs to implement ... let the folks doing the work do the work.

A manager is given a problem to solve and a team of programmers with which to solve it. The manager uses object-oriented design techniques to assign responsibilities to various programmers (objects) and defines the interactions the objects will have amongst each other (interfaces and methods). Performance evaluation becomes strictly a matter of meeting requirements and programmer outputs passing UnitTests (for example, X component coded and 100% tested in Y time).

When the manager has a special request, he must first modify the object interface and determine the potential impact said modification will incur on other object functions. Perhaps another function will not occur in the previously-defined length of time.

It would give software managers a good taste of the difficult tasks faced by programmers, especially in a poorly-defined and rapidly changing environment...and might convince them to gladly stick to being JustaManager?.

Let me get this right. You *want* your management to treat you as if you were an abstract object?

I get a bit fed up with the lack of understanding on this Wiki of what managers actually do. In most companies, management is a *lot* more complex (if not necessarily more difficult) than programming, because we have to deal with people, who aren't as rational as the objects in a program. We also know that, and so would reject an exercise like you propose as clearly unworkable. --AnonymousManager? (and ex-developer).

You shouldn't be surprised that at the boardroom level of large entities, a programmer really is just a small, abstract object. The exercise is a humorous (and hopefully benign) way for non-technical managers to experience the concept of OO. Rational behavior is not necessarily relevant to the exercise. Even on a loose scale, managers do need to understand the delegation of responsibilities to the underlings. They must manage loading, resource conflicts, and interactions. This is obviously a complex task worthy of a manager's complete attention. If the manager can derive a reasonable model using OO techniques, then, perhaps, the manager can consider taking some technical responsibility on an OO development project. If not, well, then perhaps the manager should stick to all the other complex issues of management

Even on a loose scale, managers do need to understand the delegation of responsibilities to the underlings. They must manage loading, resource conflicts, and interactions

Oh yes, and good ones do. It's a lot more complicated than (most) development, because real people are involved (I've done both). That's why I doubt that anything will come from this OO management exercise.

[3rd voice] I don't think anybody suggests that management is an "easy" function, but they are often clueless about technical issues without admitting it, and then stick their fingers into pies that they know little about. (They may be clueless because they are not involved in the details of the project, or because they have been away from the field for too long.) If anything, the very job of a manager should be to shield the developers from the politics and people issues so that they can focus more on technical issues. IOW, a role instead of a level. That is a hard job in itself.

Navigate the politics and resolve the people issues. Shielding promotes dependency, inhibits growth, and adds risk.

Shielding can be is necessary. Not all people issues can just be resolved easily, or at all.

I can spin off 3 directives in 5 minutes but they might take 24 programmer-hours to implement and test ... let the folks doing the work do the work.

Experience is a good thing. It's not required to test every practice in every circumstance in order for it to be a good idea. This doesn't mean that you shouldn't review to see how it went, but it's often better to implement and see rather than insist on testing. "We're different" is the cry of the technical person when asked to do something that's worked again and again elsewhere. Sometimes they're right - but development at one shop isn't normally that different to development elsewhere.

"Implement and see" is what I meant by "test". It really is necessary to test every practice in every circumstance.

OK. The original comment (not mine) is not unreasonable. Setting standards doesn't require you to be the one that does the work.

No, but you don't know if a directive is "good" until it has been tested.

You don't *know*, but you can have a pretty good idea. That's the "we're different" returning again. Some things have worked in enough circumstances that you can be pretty sure they're going to work in this one. I don't *know* the Sun will rise tomorrow :-)

There are directives I can say are good in seconds. Like: "The server is down, please bring it back up correctly and get the system going again. Then let's figure out what went wrong." or "There is a bug causing us to charge the wrong amount in this case, here is the detailed bug report, please start fixing it now."

But those are the directives anyone could issue. Why pay a manager for that?

The value of the manager in those situations is in follow through, coordination, and communication. For example, in the example the manager brought the developer the information they needed to fix the bug.

OK, how about decisions about the appropriate level of project management formality for this situation, or which skills are the most appropriate to look for in the next member of the team, or how best to report to the client or management, or who to assign to this project we've just heard about, or negotiating how to split a particular task between us and this other team over there, or to agree next year's training budget or the million and one things that aren't development but are needed to have an effective development team? Some developers will have the skills for this, but others - who may be excellent developers - will not, and I'd like to be able to use those developers. Managing is a skilled job. Developing is a skilled job. Not everyone can be skilled at both.

Whoa, pardner. I agree we need managers. I've even been one from time to time. I'm challenging the view that managers know which directives are good before they come out of their mouths. We can hope and assume, but no one knows until we test.

We don't *know*. We can have a damn good idea, though. Do you test, every time, if an collection is best as an array, or a hash table, etc?

I test, every time, if a collection is good enough. Every time.

You _test_? Really? You don't use your knowledge of the algorithmic properties of the various data structures and the way they've behaved in other programs? OK, but I'd have thought the time would be better spent on other things. I'd certainly check that things overall were fast enough, but unless some hotspot became obvious I wouldn't test every data structure choice.

Nope, you apply some rules, often gained from experience, about what works. Managers do the same thing (in a less certain context, admittedly). I'm just tired of technical people who say: "oh, <practice X> won't work here", and fighting the implementation tooth and nail. If testing can take a year or two (as can be true with, say, problem management), trust your manager to know what he's doing, just like you want him (or her) to trust your decisions. I find it odd that developers can, apparently without irony, complain that management interfere with their decisions and yet think the managers decisions require no skill or experience and they could make them just as well. See the top of this page, and many other pages on the Wiki.

You're not arguing against anything I've said. What are you arguing against?

The (possibly mistakenly interpreted by me) view that all management decisions/directives must not be accepted until "tested" by the developers, along with complaints about managers being out of order when not instantly accepting programmer's decisions. See the rest of this page. If you're not representing that view, then great :-)

Nothing should be accepted until it is tested, no matter who initiates it.

Then we are disagreeing. Accept it, for now. It can be rejected, changed or altered later. I don't think it is reasonable to insist, say, that a change to project management processes is tested before *you* will work with it. Just trust that the people whose job it is to propose such things, and whose responsibility it is to propose things that work, know what they're doing, and go with it.

I didn't say it must be tested before I will work with it. I'll test it. I'll hope it works. I won't assume it works.

OK. I interpreted "accepted" in "Nothing should be accepted until it is tested" as meaning you wouldn't work with (wouldn't accept) it

[1st voice] I can wholeheartedly agree with delegating responsibility for results (as long as resources go with). But I do not agree so much with defining the interactions (interfaces and methods) between developers. Leave it to the team to work out the interactions. Otherwise, it is too much MicroManagement.

That depends on the practice. Sometimes, it's best to re-use a method that's worked before, or is standardized across the organization (so, perhaps, there's training and documentation available). I don't want to stand aside and watch as a development team slowly reinvents good project management practice, for instance.

[3rd voice] Also, consider that defining the teams is, in a way, defining the interactions. You can’t always afford to have developers querying everyone in the company to find the best skill sets to solve a problem. To a great degree, this is the very role of a manager.

[1st voice] I agree with both these qualifications: training and documentation usefully provide guidance, and it makes sense for managers to range widely in rustling up needed talent.