A developer perspective:

Most project managers, program managers, product managers, development managers are not pointy haired bosses, most are trying to do a good job, but:

The factor that most controls the development is not the management, it is the developers, there is a massive range in the ability of developers, it is difficult for another programmer to gauge this difference and nearly impossible for a non-programmer. Unhappy developers are unproductive, especially the good ones.

Nearly all developers are highly motivated to produce good software, a lot of management activity negatively affects this, so a light hand is good. Almost all developers know more about the software and what they are doing with it than anyone else. (this is the details of the stuff they are buried in every day).

The best thing that a software manager can do, is get the best developers he (sometimes she) can get hold of and remove as many obstacles as possible from them getting the job done.

There is nothing you can do to make it work, you have to help it work.

To many managers, getting rid of the arrogant, undisciplined, over-paid, technology-obsessed, improperly-dressed etc. programmers would appear to be a significant added benefit. Bjarne Stroustrup The C++ Programming Language 3e, section 24.2.4

2. You know less than the people you are managing.

Detailed software knowledge has a half-life of about 3 years, if you are a manager you out of date.

When someone is working all day everyday in the details of the product, when they run the software time and again during the day, when they are thinking in real detail about how it works day in day out, they know the software. Management simply cannot apply this level of attention to every part of the product.

Software development has chaos theory as its in-laws, you often need to know the details to make the right decision.

3. You are not in control.

Management and developers are motivated by different things, some managers do not understand this.

Software developers are motivated more by problem solving, intellectual challenge, technical development, being proud of their work than they are directly by money or promotion (Nine Things Developers Want More Than Money). Many developers are positively averse to office politics.

Think maslow’s hierarchy of needs. Think self-actualization.

4. You don’t get to do the fun stuff.

Every single, ex-developer I have ever spoken to misses development. Every single one. You may be better, you may be interested, you may want to keep your hand in, but you are not available, you need to focus on being a good manager. It is regrettable, but you need to live with it. Some mangers eventually go back to development, most do not.

True happiness comes from the joy of deeds well done, the zest of creating things new. Antoine de Saint-Exupery

5. You are not in control.

You cannot really tell what developers are actually doing, if you say do it this way and they agree, how do you know what they actually do.

If you work “with” the developers, then they will work “with” you.

6. Saying something is so, does not make it so.

For a lot of management you can say something is so, and proceed with the assumption that it is, even when it isn’t it is unlikely to be provable, so it can simply be asserted. It is not so in software, if the estimate for development is nine months then it is nine months. If a customer absolutely positively must have it in six months, then it won’t happen, you either have to remove a lot of functionality (perhaps half, things being non-linear) or convince the client it will take nine months.

The most likely outcome from this clash of timetables is that the developers (and prior to that the manager) will cave in, accept the new date, rush the development which will end up taking nine months anyway (if your lucky) and be in a worse condition because its been rushed.

7. You are not in control.

Developers are analytical & critical thinkers, they are far more concerned with actually correct than politically correct.

They are going to argue and discuss things and sometimes disagree with you and each other.

The truth does not change according to our ability to stomach it. Flannery O’Connor

8. You cannot estimate how long things will take.

Estimation should be performed by the people who are going to implement the functionality. However most estimates are produced by management or marketing and typically adjusted by politics, rather than prudence. This is just lying to yourselves, don’t do it.

Estimates are frequently determined before requirements, they are aspirations or at best guidelines. Estimates have to be based on requirements (and may require significant investigation, such as functional specifications, use cases, prototypes etc), in any case it is likely that either requirements will have to slip or the overall schedule will. You can either explain this to the customer at the beginning of a project or the end, its up to you.

I have always found that plans are useless, but planning is indispensable. Dwight Eisenhower

9. You are not in control.

If your developers never cause you any problems, then they don’t know what they are doing. You have the wrong developers, your pretty much sunk regardless.

You can have an easy life getting nothing done or a more “interesting” life doing something useful. You choose.

10. We know software management is hard, because there are so few good software managers.

In my time I have worked with the many and varied of the software world and this is how it measures:

Developers:

36% Good

32% Average

32% Poor

Software Managers:

13% Good

23% Average

64% Poor

In the case of the software managers, that 13% good figure translates to three people out of nearly 15 years of experience.

My three good managers have been:

Mike Bates (BJSS)

Boyd Moffat (Three-X Communications)

Don Kavanagh (Morse)

I know software management is hard, because there are so few that are good at it.

If you think your management doesn’t know what it’s doing or that your organisation turns out low-quality software crap that embarrasses you, then leave. Edward Yourdon, Rise and Resurrection of the American Programmer

Add Bookmark:

























Share this: Twitter

Facebook

Like this: Like Loading...

Posted in lists, management, Software, Uncategorized, Work