Weblogs Forum - I Know Why Software Sucks

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
I Know Why Software Sucks

34 replies on 3 pages. Most recent reply: Feb 27, 2008 11:48 PM by Jeffrey Lowers

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 34 replies on 3 pages [ « | 1 2 3 | » ]

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: I Know Why Software Sucks

Posted: Feb 10, 2004 11:17 AM

I reflected on my experience programming, since 1976. The most successful (and most fun) project I ever worked on was one of my first. The project had two managers: one to deal with management (this was at a big company), and one who was the senior programmer/analyst, more experienced and more even-tempered than any of the other geeks. Those two project managers did four things and did them well:

1. Made sure the project was supported by management and other groups in the company. No one but them ever got dragged into progress meetings, or asked to produce schedules or estimates, and they made sure we had everything we needed at all times.

2. Reviewed EVERY program or change at the time it was submitted for testing, and made sure testing was done before releasing anything into production. The reviews and testing were somewhat informal but with one person watching the whole process it went smoothly. What formalities we had mostly had to do with standards and technical procedures, and those were pretty simple. An added benefit was that one person, whom we all trusted and respected, had a good idea of what was going right and wrong across the project, and what skills and deficiencies everyone had. We reviewed a weekly log of additions/changes/bugs/etc. in informal pizza meetings, which led to lots of good ideas, code sharing, etc. Attendance was optional but if you never went your work would suffer.

3. Assigned junior programmers to apprentice with senior programmers. The assignments changed for every sub-task, kind of like pair programming. The senior programmers would guide the junior programmers and "show them the ropes." The seniors answered to the project managers. When a junior programmer demonstrated both technical skills and the ability to work with and listen to other people he/she was promoted to more senior status. We were expected to deal with personality problems like adults.

4. Got rid of non-performers and anyone who couldn't get along with the rest of the group. Technically unskilled programmers and prima-donnas alike were let go. Junior programmers who took too long to produce were let go. Senior programmers who did't like working with apprentices were let go. The project was initially staffed by hiring about 100 contractors with very little interviewing (I was hired out of my university computer center tutoring job), at slightly above-market hourly rates. Within a month only about 60 were left, and at the end of the project we had a seasoned team of 40 who had worked together for a year and formed the core of a development group. Most of us were hired on full-time.

This project, which went on for a little over a year, was very low-stress and a lot of fun. Some people left on their own, either because they found other work, or didn't like the project, but about 50 people were let go over the course of the year for performance or personality reasons. That jibes pretty well with my (now 25 years) experience: about half of the programmers I've worked with were technically competent and could work with other people. The other half have no business working as programmers, at least not on a project that requires more than one programmer.

That experience has never been duplicated in my career, though I have worked with plenty of good managers and programmers since.

I think the biggest reason these projects are so few and far between is that senior programmers with the right mix of technical and people skills are rare. Even rarer are companies willing to let project managers hire and fire as necessary, or even impose hard deliverables and rules. Almost none of my managers have ever done real code reviews, and managers often discourage the kind of peer reviews or master/apprentice arrangements that would help build everyone's skills AND build an effective team.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: I Know Why Software Sucks

Posted: Feb 10, 2004 2:50 PM

> > > They should take responsibility for letting everyone
> > > know they are not going to get it done asap.
> You must know more understanding people than I, because
> this never does anything but get a lot of people angry
>
> Not as angry as when they the due date arrives, someone
> has to ask if it's completed and they say no; not as angry
> as when they pretend it has been completed and it isn't
> until someone tries to use it...

Yeah, but who does that? Who says 'yeah I can get that done' when they can't?

> If you cut the right corners, time is less of a factor.
> So is robustness and stability, but people only seem to
> care about that after it is too late.
> Seems like you have a technical challenge - what do you
> need to do differently to produce better quality code,
> faster?

Depending on the study you want to believe, maybe open source what I'm working on? http://techperformanceadvisor.com/doc/13441 I don't think my employer would like it. Most studies seem to indicate that defects per lines of code or defects per man hour is relatively constant regardless of the quality of the programmer or the tools used. I don't believe it, but that's what the studies generally say. All I can say is I work on that question on almost a daily basis. If you have any insights, I would love to hear them.

> It is hard for people without a background in software
> to manage software projects from what I've seen
> Could it just be hard to manage software projects,
> period?

It is, but in my experience I've had a much better time with people that had a solid software background. As Greg's post points out, these types of managers are hard to find and working in an environment to foster these types of managers is hard to find. To me it is a fundamental process flaw that developers end up applying a lot of band aids to because development is often the one left holding the ball. So maybe it isn't management per se, but somewhere the process is broken. Or the whole process of managing software projects is flawed.

> I'm wondering why it is that you are taking the stance
> that it is always the programmers fault.
> I'm just turning around what you write and sending it
> back. It isn't "the programmers" fault or "the managers"
> fault - they are both at fault when they play "the blame
> game" and they are both contributing to the poor level of
> communication by erecting caricatures about the others.

Ok, I can't argue with that. Unfortunately a lot of people play the blame game. So, you have to at the bare minimum play the cover your ass game. I would rather play the let's deliver a quality product customers are willing to pay for game, but few people seem to like to play that game. I know a lot of people that like to play the write status about the status reports about the project game, though.

> That somebody who is a developer must somehow always be
> able to compensate for the faults / shortcomings /
> weaknesses / etc. of others.
> And yet, you expect a manager to always be able to
> compensate for... ?
> You don't have responsibility for the "faults" of the
> managers (or other developers) - you do have
> responsibility for doing whatever you can, to make a
> success out of the situation. Complaining is at least a
> sign that you're unhappy with the current situation - but
> nothing will change until after you change what
> you are contributing to the problem.

Yeah, but rants are fun! And you can only do so much. At some point you have to stop slamming your head into the brick wall because it hurts.

> questions are seen as pestering and in some cases the
> person isn't available most of the time. This is a HUGE
> timesink
> Seems like from their perspective, dealing with you is a
> HUGE timesink. Why do you think your time is
> somehow more valuable? What can you do to make answering
> your questions less time consuming?

I don't care about my time. I care about getting the project done in a timely manner and I want it to be of as high quality as possible. It's that simple. I would prefer to spend my time working on the project rather than getting clarification on a point that should have been addressed before it got to me. On the other hand, I don't like releasing crap so I do everything possible to avoid that. If that involves getting clarification on a grey area that has a large impact on product functionality, I'm not going to let it slide and I'm not going to just guess.

And prototypes, which you've mentioned before, end up being a tricky game because in practice there is rarely such a thing as a 'quick prototype'. If the prototype is good, it often becomes the product because the person reviewing it looks at it and says 'hey, it looks like you almost got that all done.' If it isn't good, the implication is often that you've been wasting your time. Never mind that you learned a lot from doing it and even more from people's reaction to it. So I don't tend to make 'quick prototypes' unless it is very early in the project or if I know I'm only going to be showing it to developers. If you buy into XP, they believe the same thing about prototyping. And that's from a lot of guys I consider a lot smarter than myself. Or at least a lot more wise.

Either way, those guys have been doing this a bit longer than I have and hopefully have a little more accumulated wisdom under their belts. I look at the agile manifesto and I think to myself 'wow, what kind of a pipe dream development environment that is.' Then I read in Greg's post that, hey, somewhere something similar to that kind of development environment does, or at least did, exist.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: I Know Why Software Sucks

Posted: Feb 11, 2004 9:48 AM

Yeah, but who does that? Who says 'yeah I can get that done' when they can't?
I've experienced those situations more than once, with different companies, different programmers.

> Seems like you have a technical challenge - what do you
> need to do differently to produce better quality code,
> faster?
(Note that my question was, what do you need to do differently.)

Most studies seem to indicate that defects per lines of code or defects per man hour is relatively constant regardless of the quality of the programmer or the tools used. I don't believe it, but that's what the studies generally say.
Source me a reference for that.

If you have any insights, I would love to hear them.
1) Be curious.
Measure: note the time you start a micro task, and when you switch to some other micro task (including when you're interupted or go to the rest room or... All day, every day for at least a week.
Analyse: work through the bulk data, classifying the micro tasks in various ways, exploring where the time goes.

Investigate different ways you can approach those task categories that take most time. Plan, Do, Check, Act...

2) Keep a work diary. At end-of-day write down what you are working on, what you don't understand, the tasks you want to do next; everything that you would deal with in the next couple of hours, if you weren't stopping work. When you come back to work, read what it was you had-in-mind.

Long ago, Peter Naur (BNF) found this simple approach was effective in re-establishing task flow and increased productivity.

I know a lot of people that like to play the write status about the status reports about the project game, though.
There you go again: it's somebody else that's "the problem".

Yeah, but rants are fun! And you can only do so much. At some point you have to stop slamming your head into the brick wall because it hurts.
At some point you choose to go around the wall.

I care about getting the project done in a timely manner and I want it to be of as high quality as possible. It's that simple. I would prefer to spend my time working on the project rather than getting clarification on a point that should have been addressed before it got to me.
If you need clarification to get the project done then that's just part of the project, not an excuse to blame someone for not providing the perfect spec.

And prototypes, which you've mentioned before, end up being a tricky game because in practice there is rarely such a thing as a 'quick prototype'.
Use paper and coloured pens - that's real quick. All you're trying to do is provide a context that helps someone answer your questions.
Use a written scenario.

Then I read in Greg's post that, hey, somewhere something similar to that kind of development environment does, or at least did, exist.
The important detail was that they got rid of half the programmers that were originally hired.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: I Know Why Software Sucks

Posted: Feb 12, 2004 11:04 PM

> If you have any insights, I would love to hear
> them.
> 1) Be curious.
> Measure: note the time you start a micro task, and when
> you switch to some other micro task (including when you're
> interupted or go to the rest room or... All day, every day
> for at least a week.
> Analyse: work through the bulk data, classifying the micro
> tasks in various ways, exploring where the time goes.
>
> Investigate different ways you can approach those task
> categories that take most time. Plan, Do, Check, Act...
>
> 2) Keep a work diary. At end-of-day write down what you
> are working on, what you don't understand, the tasks you
> want to do next; everything that you would deal with in
> the next couple of hours, if you weren't stopping work.
> When you come back to work, read what it was you
> had-in-mind.
>
> Long ago, Peter Naur (BNF) found this simple approach was
> effective in re-establishing task flow and increased
> productivity.

Good suggestion. I'll give it a shot. Thanks

Since we've both basically repeated ourselves the past two posts, I have a question. When does somebody else's 'problem' really become a problem. If you get to the point where you have exhausted all possibilities, what then?

I figure there are only two alternatives. One is walk away. The other is bring it up and try to rectify it. At what point does asking somebody for clarification go from part of the project to a real problem? I know it's some number greater than 1 but is it 3? 10? 1,392? I just want to know. You seem to be of the mind that no matter the issue, if it is bothering you then it is your problem, not somebody elses. Up to a point I agree with this, but if that was always the case, half of the programmers let go in Greg's post that you mention as the important part (I really didn't miss that, by the way) would have been able to keep their jobs. Management could have just worked around the problem and all the programmers could have kept their jobs and the product could have been delivered on time, under budget and completely bug free, right?

After all, it wasn't the programmers fault they were doing a bad job, why should management take it out on them and deny them a paycheck? They MUST not have done a good job managing the project, delivering estimates, coordinating teams and getting the proper amount of testing and debugging done to ensure a stable release.

I'll be the first to admit that things aren't always managements fault. Many times it is the development staff. Recently there were some wonderful articles on zdnet about programmer incompetence to which I nodded my head in agreement. Here is one link http://techupdate.zdnet.com/techupdate/stories/main/Rx_for_better_software.html that, in addition to ragging on bad programmers, also has a reference to Fred Brooks stating that he also read there is no correlation in programmer productivity and programmer experience. Perhaps I'm going a bit far afield here, but I would count defect rate as a part of productivity. When I find more concrete examples, I'll post them here.

But as much as it is developments responsibilty to manage expectations of management, I feel management likewise has a duty to their best to create an environment for creating a quality product that satisfies customer needs. At least, if they want a happy staff churning out quality code, this seems to be a reasonable assumption. I realize cost (time, labor, etc.) is a part of this, thus deadlines, necessary product features, etc. I think anybody with half a clue realizes this.

At what point do you quit side stepping the problem, which is what it sounds to me like you are advising, and actually take steps to address it? After all, that's what the firing of all those programmers in Greg's post would be about, I would assume. Addressing a problem with the quality of certain members of the development staff, whether it be they technically deficient, unmotivated, hard to work with or whatever other reasons people get dismissed for. This is relatively easy because management has this capability.

The development staff usually does not have the clout or right, etc. to just say 'hey, manager X is a bozo. He's late with requirements, is always contradicting himself, asks for major changes to the project three days before delivery date and is never available to address issues. It's been like this for three release cycles now. Can he be fired?'

So other constantly ignoring the problem or possibly devloping a habit of three martini lunches, what does one do? I would normally raise the issue and see what can be done about it, but that's just me. I'm not saying that everything, or even most things are managements fault, but sometimes it is. And when it is, more often than not, the blame gets pushed as far down the chain as possible, so said manager can keep their job. I've seen it happen more than once, hence my bitterness about this particular topic.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: I Know Why Software Sucks

Posted: Feb 13, 2004 10:23 AM

When does somebody else's 'problem' really become a problem
When they have the same effect on everyone they deal with.

If you get to the point where you have exhausted all possibilities, what then?
Learn to be more creative. There really are a lot of possibilities - it's just that some of them require us to openly acknowledge what we contribute to the situation, and that makes them less palatable.

I figure there are only two alternatives. One is walk away. The other is bring it up and try to rectify it
And if you walk away, is it with the idea that the other person's behaviour was irredemiably broken?
And if you bring it up, are you trying to rectify the other persons broken behaviour?

You seem to be of the mind that no matter the issue, if it is bothering you then it is your problem, not somebody elses.
In contrast to - take credit and give blame? ;-)

We're talking about a working relationship between people, a history of action and reaction - if there's something wrong with that working relationship then it's usually the case that all the participants are contributing to the problem.

The only behaviour you have any control over is your own. If you want a situation to change, persistently change what you contribute to it.

Why do you have to be the one to change? Because you want to change the situation.

At what point do you quit side stepping the problem, which is what it sounds to me like you are advising, and actually take steps to address it?
Let me be clear, address "the problem".
Do you really know what "the problem" is or are you just reporting the symptoms you experience?

-snip-
dismissed for. This is relatively easy because management has this capability
Not that easy if you want to avoid being sued.

The development staff usually does not have the clout or right, etc. to just say 'hey, manager X is a bozo. He's late with requirements, is always contradicting himself, asks for major changes to the project three days before delivery date and is never available to address issues. It's been like this for three release cycles now. Can he be fired?'
Seems like manager Y could have passed along all those actions to manager X, doesn't it?

Given that you think manager X a bozo, why would manager X want to spend anymore time with you than he can avoid?

-snip-
I've seen it happen more than once, hence my bitterness about this particular topic
Successful consultants understand that their role is to make their clients successful. What can you do to make your managers successful?

Elisabeth Freeman

Posts: 4
Nickname: beth
Registered: Apr, 2003

Re: I Know Why Software Sucks

Posted: Feb 14, 2004 10:56 AM

I'm not sure I agree managers should code for 20 years before becoming managers. Being a manager takes a different (somewhat overlapping) set of skills from being a (great) programmer. Some people can do both but they are few and far between in my experience. Programming for 20 years develops only one set of skills - programming.

I also think it's possible to manage programmers effectively without being a brilliant programmer yourself, if you can (among other things) 1) tell a good architecture from a bad one; 2) think broadly enough about what the system is supposed to do long term, and anticipate what people might want it to do later and allow for those changes to be architected in; and 3) have enough really good programmers on the team that you can let them make the in-depth technical decisions so that you, the manager can focus on doing the things that programmers are generally not so good at like managing people, communicating, thinking big picture about an entire project (not just the code) and so on.

Thoughts?

todd hoff

Posts: 22
Nickname: thoff
Registered: Jan, 2004

Re: I Know Why Software Sucks

Posted: Feb 14, 2004 4:20 PM

I have worked with too many bad programmers
to every blame just management. At various
times for various reasons, i have been one
of those bad programmers.

Management shoulders a lot of blame. But how
many times must management see missed schedules,
missed features, lots of bugs, arrogant attitude,
etc before they curl up into a little ball so
they won't get hit from above and below.

Good programmers will make a good system. The
fact that there aren't a lot of good systems
means there aren't a lot of good programmers.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: I Know Why Software Sucks

Posted: Feb 14, 2004 9:58 PM

Most of the good software systems that I've used, seen or developed have involved a very small number of good software engineers who have great knowledge of good system design. However, these people also have to do all the things being discussed at length here too. They must be persistent about qualifying every issue in the design to the point that they know exactly what code covers that issue.

When there are personality conflicts, you must make the effort to really change the environment that is manifesting the conflict. Either someone is not getting your drift, or you are communicating conflicting information in your actions (of all natures) that is problematic.

People make mistakes because they are imperfect. A team of people helps to limit the impact of these mistakes by utilizing careful process controls. The people that recognize their abilities to fail, and who present their work for review with that in mind are the ones that actually add the most value to the process. Those without enough information to do the correct job, and/or those who are hiding their work till the last minute so that there will be little opportunity for review are creating the most damage.

It should be possible to look at the requirements and look at the software system and see how those requirements are met with simple explanations. Inexperienced developers write software with everything done as low level blocks of code. Experienced programers recognize the benefits of doing something once, testing it and then building the next layer on top of that. This lets you express the complexity of the total system as a more readable sequence of simple steps instead of a glob of complex low level code.

It's not software engineers or managers that make poor systems. Its bad choices by any of these groups.

The best managers I've ever had were the ones that asked me how they could help solve a problem.

The worst managers I've ever had asked why the problem was ever allowed to manifest itself.

Root cause analysis is important, but it's not the first issue to deal with.

Chris Roeder

Posts: 1
Nickname: croeder
Registered: Feb, 2004

Re: I Know Why Software Sucks

Posted: Feb 15, 2004 11:00 AM

Teaching at a tech college through the bust I had a chance to work
with some older, more mature artists and journalists (english teachers).
One thing I, ashamedly, realized is that there are professions that
include criticism in their pedagogy. Ever hear of a book or a newspaper
without an editor? The art classes include instruction on giving and taking
criticism! I've seen the odd code review, but not as a regular practice as
(apparently) in these other professions.

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: I Know Why Software Sucks

Posted: Feb 15, 2004 9:22 PM

I don't want to stick my nose into your argument, but since both sides referred to my posting let me explain it a little better.

In the project I referred to the project managers fully expected about half of the contractors they hired to leave one way or another during the project. Their budgets and schedules reflected that expectation. From past experience they knew that about half of the programmers they might hire would produce, and the other half would not. Rather than spend a lot of valuable time interviewing or testing or calling references, they hired almost anyone who had some programming qualifications and could sell themselves in a ten-minute interview, and let natural selection do the rest.

Everyone started out at the same level, with some exceptions for programmers who had prior knowledge of the system, or a prior relationship with other senior members of the team (i.e. someone who could vouch for them). Everyone could succeed or fail, and it mattered little what was on your resume.

Although we were contractors rather than employees, we were given free training in both system analysis and design (from Edward Yourdon himself, who came on-site), and programming (I went to Boston for two weeks to attend classes at DEC). The management was committed to letting anyone succeed in the job, but ultimately each of us had to put in the effort and do a good job.

No one was let go for honest mistakes. We apprenticed with a senior programmer who gave advice and reviewed our work, we were given training, 24-hour access to a dedicated development system, documentation, etc. A few people proved themselves unable to learn and produce fast enough; it may sound cruel but they probably were not meant to be programmers and found out fairly quickly. Most of the people who left had personality issues: prima donnas, unwilling to participate as either master or apprentice, etc. One guy was canned for making up test results, a couple of guys were drinking too much on the job. I could be wrong but I don't think anyone with some native talent who was willing to learn and work and could get along with others was let go -- I started out very junior and so did most of the others.

I would use this staffing technique if it wasn't a lawsuit minefield. I can't even count how many times I've seen a complete loser hired because he/she had a great resume. And I can't remember all of the skilled and dedicated programmers who look like crap on paper. If I could fill every opening by bringing people on as interns and giving them a chance to prove themselves (or not) I'd much prefer that over the lengthy and dishonest hiring process I am usually forced to follow.

Drew Mills

Posts: 1
Nickname: tamills
Registered: Feb, 2004

Re: I Know Why Software Sucks

Posted: Feb 16, 2004 3:05 PM

Although I've seen horrendous mistakes by managers, I'm not sure that managers can take the rap for large systems. I've been on large projects with good professional managers (think ISS) where the project still sucked. I think the issue with large systems is complexity.

Human relationships have a threshold of complexity beyond which we can no longer communicate. We evolved in a world where the ability to communicate with 100 other people on a single endeavor just was never necessary. This is not a skill which our emotions support.

And this problem is most certainly an emotional one, not an intellectual one. The best efforts are those which follow the natural emotional tendencies of the people working on the project. There are several things we need:

1) Feedback - positive and negative
2) Rewards - We need to feel good
3) Responsiveness in 1 & 2. Both of the above need to happen on a regular and frequent basis. Otherwise, people lose heart.

Unfortunately the feedback and rewards must operate in the limited-complexity environment I first mentioned above. There is only so much that can be said at any given time regarding any specific activity and only so many people that can give the rewards/feedback.

This need for feedback/rewards goes in all directions. If people give us requirements, they need rewards and feedback to know they are doing the right thing and to feel good about having done it. More communication adds more complexity.

As soon as the complexity threshold is crossed when giving/receiving feedback then people begin to lose the ability of ensuring that understanding is happening. As soon as the complexity threshold is crossed when giving/receiving rewards, then people start to lose the feeling that their work is respected and appreciated.

It is no wonder large systems are difficult to build. The only hope lies in the commoditization of parts. If parts of the system are so reliable and cheap that they do not have to be thought about and talked about, developers and analysts can get right to the task of thinking about and getting feedback/rewards on higher-level stuff.

In large systems that have been successful but without commoditized parts, you'll find outrageous expensiveness that is tied directly to developing these parts to (just) a satisfactory level.

ilPostino

Posts: 8
Nickname: ilpostino
Registered: Feb, 2004

Re: I Know Why Software Sucks

Posted: Feb 19, 2004 7:19 AM

bravo! my life is "Office Space" I have had to deal with having 4 bosses and 2 dev managers on the same project!?! $2M later and it fails, big surprise - I feel that upper management, the ones above the dev managers are even worse. In this place developers like me who have 15+ years of experience get told how to develop the product by "Lead" developers who only have 5, go manager go!

-C

Sean Corfield

Posts: 3
Nickname: scorfield
Registered: Feb, 2004

Re: I Know Why Software Sucks

Posted: Feb 29, 2004 1:29 PM

Greg's posts struck a real chord with me. I spent a brief period working for a very traditional corporate environment that had a very rigid hiring and promotion structure - if you were good at something, you got promoted until you were not good at something and there you stayed. Your vacated positions were always backfilled (with more junior people).

When I left after only five months - dismayed at how inept most of the department was (managers and programmers alike) - my exit interview offered me the chance to share my thoughts with the departmental head. My advice was to cut about half the staff they had and flatten out their rigid job title structure. That wasn't received well!

Part of our industry's problem stems from having too many mediocre people who joined the gravy train. Over the years we've accrued a lot of personnel baggage and these days it's hard to get rid of it - as Greg says, it's a lawsuit minefield.

And we let it happen, all of us. It's not 'their' fault, it's collectively 'our' fault. Our managers are part of our industry too and we all depend on each other working together as a team.

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: I Know Why Software Sucks

Posted: Mar 3, 2004 1:49 AM

> I don't think that the managers missing development
> experience is the real problem.
>
It's not the entire problem, but it is part of the problem.

> Our domain is so complex, that we have to develop
> specialties. We need good developers that have several
> years of experience in development and we need managers
> with several years of experience in management. A long
> career in development doesn't make a good manager.
>
Certainly true, but a complete lack of understanding about the people and processes you're managing is even worse.
A good manager knows when to listen and when to force a decision, sadly most managers seem in it only for the powergames and will force decisions that they are not qualified to make and try to micromanage processes they don't understand.

> We developers too often focus our attention primarily on
> technology. Our own views are predominant. We easily
> ignore the management view.
>
Well said. In the end it's the product that counts, not how it was derived at.
If the product doesn't suit the needs of the customer (whether the customer is internal or external) the job wasn't done.
As often the manager(s) are the only ones in contact with the customer (whether this is good or not is another discussion entirely...) they're the ones who (should) know what the product should be.
They're the ones with domain knowledge, unless you're in a company or project that has been working on building and maintaining the same application (or multiple applications for the same narrow market) for a long time.

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: I Know Why Software Sucks

Posted: Mar 3, 2004 2:47 AM

> Greg's posts struck a real chord with me. I spent a brief
> period working for a very traditional corporate
> environment that had a very rigid hiring and promotion
> structure - if you were good at something, you got
> promoted until you were not good at something and there
> you stayed. Your vacated positions were always backfilled
> (with more junior people).
>
That's typical of most large organisations.
Promotion is vertical instead of horizontal, and people keep getting promoted into incompetence because they get promoted as long as they perform.
If you say no to a promotion that means your career is definitely over so you say yes even though you deep down know you are not likely to succeed in your new position.

> When I left after only five months - dismayed at how inept
> most of the department was (managers and programmers
> alike) - my exit interview offered me the chance to share
> my thoughts with the departmental head. My advice was to
> cut about half the staff they had and flatten out their
> rigid job title structure. That wasn't received well!
>
Of course not.
The HR people who talk with you are the ones benefitting from the rigid structure as their jobs get a lot easier (XXX has Y years of experience in position A so he gets promoted to position B, nice easy procedures and forms).
The non-HR people present will not like being reminded that they're incompetent or likely to end up that way.

> Part of our industry's problem stems from having too many
> mediocre people who joined the gravy train. Over the years
> we've accrued a lot of personnel baggage and these days
> it's hard to get rid of it - as Greg says, it's a lawsuit
> minefield.
>
I'd not say "mediocre" as much as "in the wrong place".
There's a lot of people that would perform very well in churning out standardised software (say custom mods to standard applications) but are piped into developing new things from scratch, something they can't grasp.
They are afraid to say they can't do that for fear of their jobs so they muddle along while the project falls further and further behind as teammates cover for them.

> And we let it happen, all of us. It's not 'their' fault,
> it's collectively 'our' fault. Our managers are part of
> our industry too and we all depend on each other working
> together as a team.

True. But they're (as you mentioned yourself) often promoted from other jobs into positions in which they are uncomfortable or incompetent (the same goes for many designers and architects).
It's not their fault (at least exclusively) they ended up in that position of course, it's the fault of the entire system of promoting people until they become incompetent at what they do.

Flat View: This topic has 34 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic