keithd@cadovax.UUCP (Keith Doyle) (07/20/87)
In article <893@hp-sdd.HP.COM> nick@hp-sdd.UUCP (Nick Flor) writes: >>All the structured design and analysis will not save an idiot. > >It *is* set up to save the idiot. Actually, this is one of the main problems I have with structured design doctrines/dogmas. It treats your good programmers like they don't know what they are doing. Virtually any good programmer has come to the same conclusions about the design process that structured design techniques have. Buy when managment implements such processes, it's usually to atone for a history of failed schedules, which in my opinion is usually due to poor management. But does management implement 'structured management techniques'? No, they pass the blame down the line, and implement 'structured design techniques' as a panacea. And in so doing, they are telling the programmers, "Well, we don't trust your ability to do a good job without hand-holding, so we're setting up this procedure to baby-sit you. And then you end up with what you payed for, mediocre programmers, producing mediocre software, because that is what the system is optimized for. >Do you even know anything about >the structured design/analysis process? Part of the process involves >going over your design THOROUGHLY with your project team. >You should >be able to catch all the bugs the user could potentially discover through >normal use. Too many packages out there contain bugs that are discovered >to pathological interference by buffoons. Structured design eliminates >most of this. >In large projects, the documentation that results from following >the methodology not only facilitates the delegation of well defined >tasks to different people but also makes it easier for future project >teams to understand/fix/enhance/modify etc. the code reliably. Sure, but if you need Yourdon or Marcus to tell you that, or worse, to setup rigid dogmas to accomplish such, you're already beyond hope. Management imposition of structured techniques has attacked the *symptom* of the problem, not the problem itself. And what is the problem? You've lost the ability to keep your programmers inspired and motivated and to be conciensious toward their job. If you hadn't they would have been coming to YOU to tell you they've arrived at new ways of improving maintainability and bug-free-ness. >Look folks, I'm just sick to death of some of the sh*tty code that gets >published. I'm not trying to flame anyone in particular, just immature >attitudes towards software design. So what about the sh*tty code that gets published that was produced with structured design techniques? And what good is the most maintainable code in the world, if the end product isn't worth using? Or if the programmers primary goal has been to produce the best looking design documentation in the world? The user never sees the design documentation, and you can't boot the design documentation in his disk drive. >When we finally get off of our high chairs and acknowledge that bottom-up-do- >what-comes-easy-first design just doesn't work for software of considerable >size, everyone will be a lot better off. What I object to, is not the theory of structured design per se, but the fact that many times, management is shoving it down peoples throat in an attempt to cover their own ass, because they're completely in the dark as to how to get a good product out on schedule without somebodys book telling them what to do. I'd say they need some techniques to learn how to manage themselves out of paper bags. And in particular, how to motivate people. I mean, if structured techniques didn't exist, it would be necessary to invent them. Because there is an enormous market for a wonderful warm fuzzy band-aid solution to the 'software problem'. Never mind how well it might really work, or if there are other methods that can be used. Never mind asking the programmers what they think might be good ways to address the problems, or what shoving ANY technique down peoples throat is going to do their motivation and job satisfaction. Some guy over there has written books on the subject that everybodies buying, so he must know what he's talking about (and never mind that he turns around and tries to sell you the software tool to do you the job for you for big bucks either). And then never mind that: 1) We never have the budget to get the right tools for the job, or really good tools may just be a pipe dream at this time, but are going to impose the dogma anyway without tools. 2) We don't have the time or money to hold classes for the programmers to tell them how to do all this new stuff that's being expected of them. 3) We don't care what the programmers think of all this, or what effects it has on their morale or inspiration, if they don't like it they're all fired. ("If we base their review on the completeness of the design documentation, they'll get it done") 4) None of these techniques say anything about the quality of the finished product other than it's maintainablity and bug-free-ness, and tend to make the design documentation everyones primary focus and responsibility, over and above the true quality and utility of the finished product. I tend to subscribe to the less-is-more school of design. I'd say if the software is of such a considerable size, it is probably grossly overdesigned. The Amiga hardware team, (Miner et al) I would say is a darn good example of the less-is-more school of hardware design. It's always easy to make something more complicated. Making something less complicated is the hard part. The most complicated messes I have ever seen have grown out of structured dogmas, mainly because everyone is so busy protecting their own ass, and defending their own turf, trying to make life easier for themselves in a bureaucratic environment. And due to such priorities, the actual design suffers (good enough for government work). Imposing dogmas of structured techniques make management feel they have done their job. Such dogmas are good for below average programming staffs I suppose. But I wouldn't know, I've always worked with pretty intelligent programmers for the most part. When management comes and asks me how they should do their job, is when I would expect them to tell me how to do mine. Do you tell a writer how to formulate an outline? Which chapter to write first? Do you tell an artist which colors he should use? What order he should paint them in? To produce a detailed design document first? When you take the 'art' out of the 'art of computer programming', is when you take the 'artwork' out of the product. I'm interested in creating works of art, not in camels that were supposed to be horses. If the programmers feel they need to implement specific structured techniques to handle a situation, it should be THEIR choice, and THEIR decision. After all, it is THEY that you are expecting to do this job. If you can't get them excited about doing it, all the Youron's and Marco's in the world won't help you. You pigenhole your programmers in a box, and they'll act like square pegs in round holes. Their interest in the project will wane, and you'll lose a lot of them. At least, you'll lose the best of them. You have to keep your good programmers inspired, motivated, not optimize your system for idiots. You should maintain their freedom to innovate, to create, if that is what you want them to do. And in my book, that is what you should be wanting them to do. Any project that is so complicated that you need to implement dogmas of structured techinques to handle, is probably ALREADY too high-level, and has not been broken down enough. It's up to the product managers and other managment to learn a little top down design themselves, and not foist a ridiculous set of constraints on the design of a product which begins to look like the final answer to the worlds problems in one single module. Structured dogmas blame the programmer for everything. You don't know how to design your code, noone can support your code, you don't know how to document your code, you don't know how to test your code. And it could never be that QC or Test or Documentation departments are the ones that don't know how to do their job, it's up to you to spoon feed them with the most outstanding wonderful design documentation in the world. That makes their job easy. But it does it by making yours (as a programmer) more difficult. As if things weren't complicated enough as they were, learning 80386 machine language, understanding UNIX and DOS, keeping up with technology. And never mind that many programmers aren't cut out to be good writers, or good illustrators. That some of them may have learned programming because they didn't cut it in english classes. That they may be poor communicators. We can force them to be good jack-of-all-trades and do everybodies work for them. After all, they're getting paid more than people in those other departments. You have to give your programmers credit for having some brains. If you expect them to act intelligently, they will. If you treat them like children, that's how they're likely to act. A motivated programmer will address a comment like 'the support people find it hard to understand your last program/documentation' by striving to make it better on the next program. If he asks for ideas on how to make it better, certainly a book on structured techniques might be a good suggestion. Maybe you can get your professional documentation staff (assuming you have one) involved. And who knows, he might just come up with a solution on his own that works much better for a given situation. We'll never know if we don't give him the freedom to be innovative. But naw, programmers are basically nurds and idiots, we can't expect them to have any brains. There are two basic ways you can run a department. You can take the people you have, and figure out how to build the best organization you can around what their abilities are, or you can design the perfect organization, and try to fit the people you have into the various 'slots'. I agree, its much easier for a manager to do the latter. Otherwise, you have to have an organization that is adaptable, as people come and go, and you will have to do some adapting when that happens. However, having an adaptable organization may have other benefits when other things change too, like technology, the marketplace, etc. I prefer an organization that tries to make the best use of peoples talents, not one that tries to fit everyone into the 'mold' of a perfect programmer. Unfortunately, until enough management learns of the importance of motivating people, and ways of doing such, the market for *magic* techniques will just get larger and larger. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa Contel Business Systems 213-323-8170 "Everything should be as simple as possible, but no simpler." -Einstein
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (07/22/87)
In article <1660@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: |In article <893@hp-sdd.HP.COM> nick@hp-sdd.UUCP (Nick Flor) writes: |||All the structured design and analysis will not save an idiot. || ||It *is* set up to save the idiot. | |Actually, this is one of the main problems I have with structured |design doctrines/dogmas. It treats your good programmers like they |don't know what they are doing. Virtually any good programmer has |come to the same conclusions about the design process that structured |design techniques have. No. By your own statement the good programmers recognize the benefits of structured design techniques. What structured design attempts to do is make those programmers who don't quite know what they are doing behave as if they did. In other words, it provides the inexperienced a technique which will make them more effective. ||Do you even know anything about ||the structured design/analysis process? Part of the process involves ||going over your design THOROUGHLY with your project team. | ||You should ||be able to catch all the bugs the user could potentially discover through ||normal use. Too many packages out there contain bugs that are discovered ||to pathological interference by buffoons. Structured design eliminates ||most of this. | ||In large projects, the documentation that results from following ||the methodology not only facilitates the delegation of well defined ||tasks to different people but also makes it easier for future project ||teams to understand/fix/enhance/modify etc. the code reliably. | |Sure, but if you need Yourdon or Marcus to tell you that, or worse, to |setup rigid dogmas to accomplish such, you're already beyond hope. An individual working entirely alone can use any techniques which suite him. Someone who works with other people has to communicate with them in a way that is mutually understandable. The adoption of a structured design methodology brings order to the design process. Designers, programmers, and analysts have a technique which brings errors to light sooner. The sooner errors are recognized the earlier (and more cheaply) they can be corrected. You don't achieve those benefits if just one member of the design group uses structured techniques. The structured approach facilitates communication by reducing the time it takes for one person to understand what another is doing. |Management imposition of structured techniques has attacked the *symptom* |of the problem, not the problem itself. And what is the problem? |You've lost the ability to keep your programmers inspired and motivated |and to be conciensious toward their job. If you hadn't they would have |been coming to YOU to tell you they've arrived at new ways of improving |maintainability and bug-free-ness. Question: What is a manager? Answer: Someone who believes in magic. Most managers think they can buy a program or product, install it, and watch their problems magically disappear. So they declare structured design to be the order of the day. Then they go sit on their hands and look surprised when the problems are still there. You're right, Keith, that management imposition of structured techniques doesn't solve the problem. You can't just impose structured techniques. You have to teach people how to use them. If that's done properly programmers will be inspired and motivated. They'll be excited by the way structured design techniques help them write reliable code. They'll see it as a better tool that lets them spend more time on new development and less time on maintenance. ||Look folks, I'm just sick to death of some of the sh*tty code that gets ||published. I'm not trying to flame anyone in particular, just immature ||attitudes towards software design. | |So what about the sh*tty code that gets published that was produced with |structured design techniques? And what good is the most maintainable |code in the world, if the end product isn't worth using? Or if the |programmers primary goal has been to produce the best looking design |documentation in the world? The user never sees the design |documentation, and you can't boot the design documentation in his |disk drive. All other things being equal, an easily maintainable program is better than one that isn't. Of course you can use structured design techniques to write bad programs. You can write programs that are inefficient, hard to use, or simply useless. But if you have a good idea for a program and you know how to use the resources of the target machine and you understand the end users' needs structured design will let you design the same program faster than a non-structured design. Or it will let you build a better (more reliable, more maintainable) program in the same time. And it might even suggest additional features that could be added because they could use modules that were already required for the original design. It isn't a question of good programming versus structured design, it's a combination of good programming AND structured design that's needed. ||When we finally get off of our high chairs and acknowledge that bottom-up-do- ||what-comes-easy-first design just doesn't work for software of considerable ||size, everyone will be a lot better off. | |What I object to, is not the theory of structured design per se, but |the fact that many times, management is shoving it down peoples throat in |an attempt to cover their own ass, because they're completely in the |dark as to how to get a good product out on schedule without somebodys |book telling them what to do. I'd say they need some techniques to |learn how to manage themselves out of paper bags. And in particular, |how to motivate people. The most motivated people in the world can't produce a product if they don't know how. If they're good, they can figure out how, but why should everyone re-invent structured design? A great deal of work has already been done in the field of software engineering. Let's take advantage of it, even if it's "not invented here". |I mean, if structured techniques didn't exist, it would be necessary |to invent them. Because there is an enormous market for a wonderful |warm fuzzy band-aid solution to the 'software problem'. Never mind how well |it might really work, or if there are other methods that can be used. |Never mind asking the programmers what they think might be good ways |to address the problems, or what shoving ANY technique down peoples |throat is going to do their motivation and job satisfaction. Some guy |over there has written books on the subject that everybodies buying, |so he must know what he's talking about (and never mind that he turns |around and tries to sell you the software tool to do you the job for |you for big bucks either). You're absolutely right, Keith. No technique is going to work with people who aren't motivated. And nothing turns off motivated people than a manager whose attitude tells them "You guys are so dumb I need this system to keep you in line." But the problem is with the manager's approach, not the structured design system. Another manager, pushing the same techniques, whose approach was "Here's a tool that you'll find really helpful" will have lots better luck. |Any project that is so complicated that you need to implement dogmas |of structured techinques to handle, is probably ALREADY too high-level, |and has not been broken down enough. It's up to the product managers |and other managment to learn a little top down design themselves, and |not foist a ridiculous set of constraints on the design of a product |which begins to look like the final answer to the worlds problems in one |single module. To me, this sounds like any project big enough to require structured design techniques should have had structured design techniques applied earlier. |Structured dogmas blame the programmer for everything. You don't know |how to design your code, noone can support your code, you don't know |how to document your code, you don't know how to test your code. And |it could never be that QC or Test or Documentation departments are the |ones that don't know how to do their job, it's up to you to spoon feed |them with the most outstanding wonderful design documentation in the |world. That makes their job easy. It's your code. If you can't document it no one can. If you can't tell people how to use it QC and Test people can't put it through its paces. The Documentation department's job is to tell the end user how to operate your software. They can't do that if you don't tell them how it works. | But it does it by making yours (as a |programmer) more difficult. As if things weren't complicated enough as |they were, learning 80386 machine language, understanding UNIX and DOS, |keeping up with technology. And never mind that many programmers aren't |cut out to be good writers, or good illustrators. That some of them |may have learned programming because they didn't cut it in english classes. |That they may be poor communicators. We can force them to be good |jack-of-all-trades and do everybodies work for them. After all, they're |getting paid more than people in those other departments. Of course, if you just want to be a coder, with no influence on the design, someone else can do all these things and give you detailed specifications. But if you want to be creative, if you want to use your ability to write code to make the computer do what you want it to do you must take the responsibility that goes with that level of work. You must be prepared to make your products interface with others'. You must be ready to explain how to use your software and how to maintain it. Whoever plays the creative role has to explain the implications of his creation--no one else can. |There are two basic ways you can run a department. You can take the |people you have, and figure out how to build the best organization you |can around what their abilities are, or you can design the perfect |organization, and try to fit the people you have into the various 'slots'. |I agree, its much easier for a manager to do the latter. Otherwise, you |have to have an organization that is adaptable, as people come and go, and |you will have to do some adapting when that happens. However, having |an adaptable organization may have other benefits when other things |change too, like technology, the marketplace, etc. I prefer an |organization that tries to make the best use of peoples talents, not |one that tries to fit everyone into the 'mold' of a perfect programmer. |Unfortunately, until enough management learns of the importance of motivating |people, and ways of doing such, the market for *magic* techniques will |just get larger and larger. How true that is! But once again, those are complaints about poor management that really aren't relevant to the question of structured design techniques. Think how much worse things would be if these same poor managers actively prevented the use of structured design techniques and worked to block the adoption of programming standards. Unbelievable? I wish it were. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...seismo!akgua!usfvax2!jc3b21!fgd3
nwd@j.cc.purdue.edu (Daniel Lawrence) (07/24/87)
> [A long discussion of "Structered Design"]
Please forgive my ignorance in this area, but when we start
debating the pros and cons of structured design, perhaps someone could
define the term for us. When I program, I believe I do it in a
"structured" manner, but is this the structure that you are debating?
Daniel Lawrence
UUCP: ihnp4!pur-ee!j.cc.purdue.edu!nwd
ARPA: nwd@j.cc.purdue.edu
FIDO: 201/2 The Programmer's Room (317) 742-5533
ATT: (317) 742-5153