At 10:27 AM 2/23/01 -0800, C. Daniel Cooper wrote: > > My story would go in a similar vain but the second team did get the > > program built in one week and it did work 'OK' and it made management > > very happy. I was placed on the list for the next lay-offs and they > > were promoted. > >I'm sure these stories abound. In my own equivalent, the other team's >code was delivered to the customer in half the time, and I *was* laid >off. Their code was "mostly working". Well, in my "many" years of experience I have often been on projects with "hot dog" programmers who swore by "quick and dirty". Early on these were assembly language hot dogs. More recently they have been C language hot dogs. My experience with these "hot dogs" has been that they invariably fail to deliver their fair share of the work on time. And when they do deliver, their work is invariably sucky. Yet, management tends to be happy with them. My observation is that they are much better at convincing management they do good work than they are at doing good work. . . . >But the point of my original email was not to elicit these stories >(satisfying as they are); instead, it was an attempt at understanding >the phenomenon. Why does "the other team" always seem to exist? This is a key question that lead me, almost 10 years ago, to start studying the whole "sucky software" issue. It was very puzzling to me then. I still don't feel I fully understand the phenomenon, but I do understand it a lot better than I did then. "Hackers" thoroughly love being around computers and software. They are in this business because it is FUN, not because they have any particular commitment to the profession. To make matters worse, they have managed to get into the business without receiving any significant education or training to qualify them to be in the business. One reason they are able to "impress" management is their deep love for software. Their enthusiasm is often mistaken for competence. At the same time, they are generally very intelligent - not r.e. software, so much, but in general. They use their intelligence to learn what buttons are most successful with management, and work those buttons skillfully. There are other aspects to this phenomenon, but I think these are 2 key aspects of it. >Earlier, >I wrote, > > > the developers either 1) don't see their software as being sucky -- > > a training/competence issue -- or 2) they tolerate suckiness in order > > to meet deadlines, ie, they accept the development schedule along with > > all the other requirements their product must meet. > >The common thread in our stories is that we reject the premise of #2: >we refuse to accept a deadline that will induce sucky software. But >the "other team" does accept it. Are their standards lower than >ours? Yes. Throughout (U.S.) industry there is little evidence that quality is a serious consideration when it comes to "getting the job done". >When I talk to these developers, I get a different perspective: >they see themselves as "pragmatic", "getting the job done", "not a >blue-sky academic", etc. Our view is that "suckiness is intolerable and >the deadline is unrealistic;" their view is that "flawless software >delivered late is sucky." They have made a tradeoff that to us is >abhorrent: some degree of suckiness is tolerable versus missing the >deadline; or more simply, some degree of suckiness is always tolerable. Part of this is the jargon they have learned that "pleases management". Part of it is that they genuinely believe software can't be implemented correctly in the first place. If it can't be done right with a LOT of effort, it might as well be done wrong with less effort. >I really don't like arguing this point, but I think it's a reality >that we in the Ada community tend to be blind to. We seem to think >(hope) we can eradicate suckiness, via better tools and environments, >better training and curricula, better processes and methods, and yes, >by using Ada versus other languages. But if all these were in place, >would suck-inducing deadlines go away? I think not; they would only >get shorter :-( Assuming that management gets proper training, I think deadlines would almost become a non-issue eventually. That is, both developers and managers would focus more on steady, productive progress. And, since far less time (currently something like 80-90 % of developer time) would be spent on maintenance, it would appear that projects are coming in ahead of schedule most of the time. But the detailed development of this argument is quite lengthy . . . . >Am I being overly pessimistic here? Is there some Utopia we can aim >for, where sucky software is no longer built? Or, are we just being >unrealistic in hoping so, since some degree of suckiness will always >be tolerable no matter how things improve? What we are talking about here is a substantial cultural change, after which "suckiness" not only would not be tolerated, but would not even be an option. This, admittedly, is a BIG change. But we have to start somewhere. . . . . . sro S. Ron Oliver, semi-retired professor of Computer Science and Computer Engineering. www.csc.calpoly.edu/~sroliver caress Corporation is proud to be the U.S. representative for Top Graph'X, developers of high quality software components, using Ada. For more information, check out www.topgraphx.com. Tired of sucky software! ? Check out www.caressCorp.com and follow the links to software sucks and The Oliver Academy.