Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!columbia!rutgers.rutgers.edu!sri-spam!ames!elroy!jplgodo!wlbr!scgvaxd!trwrb!cadovax!keithd From: keithd@cadovax.UUCP (Keith Doyle) Newsgroups: comp.sys.amiga Subject: Structured Techniques From Hell (was: Electronic Arts bashing) Message-ID: <1660@cadovax.UUCP> Date: Sun, 19-Jul-87 20:39:23 EDT Article-I.D.: cadovax.1660 Posted: Sun Jul 19 20:39:23 1987 Date-Received: Tue, 21-Jul-87 04:33:03 EDT References:Reply-To: keithd@cadovax.UUCP (Keith Doyle) Organization: Contel Business Systems, Torrance, CA Lines: 198 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