Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Making Software Suck Less 315

Posted by timothy from the like-frank-lloyd-wright dept.
That much software sucks -- perhaps most of it -- is hard to dispute. Except for the simplest programs, it seems like the price of complexity is a tendency to failure. Commands don't work, user interfaces are neglected to the point of ruin, and components of even the same piece of software often clash with each other. And once you start combining them and try to use more than one application at once, sometimes the best you can hope for is an operating system that neatly segregates the problems so that your word processor doesn't take down your web browser, your IDE or your e-mail client. At least those are desktop applications for individual users, though -- the trouble compounds briskly when the common faults of software manifest in multiuser environments, where one machine going down means a wasted time and frustration for a lot of people at once. In an effort to outline the ways that software could suck less is coding, reading and writing dervish chromatic.

Making Software Suck Less - Processes

Once upon a time, a prominent writer and programmer rose to declare "I want software that doesn't suck!" He then explained that certain successful free software projects have similar development features that contribute to software quality. Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.

There's hope, though. Improving the ways in which we produce software can dramatically improve the software itself. Extreme Programming suggests that simple habits, acting in concert, produce extremely powerful results. By adapting these techniques to the unique world of free software, we can improve the quality of our programs. We start by restating some common truths about free software development.

Distributed Development

Open development, of course, means that anyone with the time and the inclination can look at the code. Developers and dabblers have the opportunity to modify it to their needs. This by no means guarantees that anyone will do so. Making source code available is no silver bullet. Many qualified eyes actively looking for bugs make bugs shallow.

To harness the power of additional developers, you must attract them to the project. A simple design and clear documentation reduce the amount of work needed to come to grips with the system. XP suggests an overall metaphor to describe the system as a whole and to provide good names for the components and subsystems.

Test First

The most powerful weapon in your toolbox is comprehensive unit testing. (Unit tests are automated, independent procedures that exercise the smallest possible pieces of functionality individually.) Extreme Programming recommends a test-first approach. Before adding a new feature, the programmer writes a test for the feature and runs all the unit tests. The new test fails, so he writes code to pass the test. When all tests pass, the feature can be checked in. Tests cover everything that could possibly break.

When a bug appears, the programmer writes tests to demonstrate it. After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features. Besides that, it can prompt the programmer to write additional tests he had not previously considered.

Test-first programming ensures that all features have unit tests. Coders receive immediate feedback -- it's almost like a game. It produces a different mindset, freeing the programmer to concentrate solely on the task at hand. Code becomes easier to write, in the same way that finding the correct piece for a jigsaw puzzle is easier with its neighbors in place. Finally, it gives programmers the confidence to refactor, modifying existing code, by identifying the effects of a change.

Consider providing your test suite with the project. Add a 'test' or 'check' target to the Makefile. Projects designed to run on multiple platforms and distributions can generate better bug reports by including test results. Make it easy for users to report failures.

Simple Solutions First

After writing a test, write the simplest possible code that could pass it. Resist the tendency to make things more flexible than you need at the moment. Concentrate only on the task at hand, programming only what you need to pass the test. Don't sacrifice current elegance and simplicity for a feature months down the road.

"It's true that 'simple and tested code means less bugs'.... Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs."
Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future. Don't spend time and energy overgeneralizing for something six months away when no one will use it in the meantime. Reduce the need for costly and time-consuming rewrites by avoiding extraneous complexity.

Have a Plan, Code For Your Users

Write a plan for the software. Describe each feature in a paragraph or less, with sufficient detail that people will know when it is complete. Arrange the stories by importance, then tackle them in that order. This allows you to identify the work that will provide the most value to the customer. (In a free software project, the lead developers may be the customers.)

Dividing the project into stories allows delegation, especially in free software projects. Some tasks require an experienced hacker, while others serve as a gentle introduction to the program. Writing stories also provides sane goals and a project roadmap. Choose a few stories for each release. This gives end users a clear view of project progress.

Continuous Design, Refactor

With tests in place, you have the freedom to refine your initial design. By using the simplest solution first, you avoid investing time in hard to follow and difficult to maintain code. Your initial design will change. Your plan will change. Expect this and allow it to happen.

"Premature optimization-including premature low-level design--is the root of all evil."
When you see an opportunity to refactor, do it! Eliminate duplicate code. Relocate common features into a new object or a function. Reduce complexity and interconnections. Don't maintain the same functionality in multiple places. Use simple, well-defined, and consistent interfaces. This, along with your test suite, will allow you to overhaul individual pieces without having to track down holes in far-flung files.

Release Often, Release Working Features

Commit to regular release dates. This shortens the feedback loop. Users who can count on regular, stable releases with valuable new features will be more likely to use the software. It also provides more frequent entry points for new developers.

Follow your plan to add a few important features to each release. Focus programmer time and effort towards a simple, reachable goal. Allow time for design, testing, documenting, and packaging. The more often you have to do this, the more likely you are to streamline these processes. Resist the urge to add features you cannot complete in time. Instead, break them up into smaller stories and implement the most important parts. As usual, the unit tests help to stabilize the codebase and keep it in a state of stability. After completing a release, take time to modify your stories, shuffling priorities as necessary. Then commit to the next release.

Conclusion

If we truly want excellent software, with well-developed features and no messy surprises, we need more discipline in our approach to creating software. In my experiences with these techniques (and in talking to other developers), I have found that even simply migrating to a test-first approach, though painful, has increased my productivity and my confidence. It's scary at times, but immensely satisfying. Taken together, who knows what levels of excellence we can reach?
This discussion has been archived. No new comments can be posted.

Making Software Suck Less More

Making Software Suck Less

Comments Filter:
  • I've skimmed through the XP books, and there were some excellent ideas, and I partiuclarly like the attitude towards testing brought up there. I have one big question about it, that I didn't see the books answering.

    How do you do regression tests on a GUI app? For console apps, daemons and other backend software it strikes me as more or less straightforward to impliment, but there is no reliable way that I've found to do this level of testing for:
    * An application's GUI interface
    * The interactions between this GUI interface and the non-graphical code.

    If someone has a good answer to this, please let me know.


    ----
  • CS degrees don't prove anything, unfortunately. Too many CS grads got the degree because they wanted a job when they graduated, not because they enjoy algorithmic design, and are skilled with logic and organization.

    At my workplace we have everything from doctors to people who didn't graduate. The level of education has very little correlation to the quality of code they produce. We have people who didn't graduate who write well documented, well designed code, and people with graduates who constantly have bugs because they never learned to check for edge conditions. I'll admit, I've yet to work with a Doctor who wrote bad code.

    The problem is that it's hard to tell who, by nature, is an engineer. Yes, I'll admit, an engineering degree gives some credence to the concept that they'll be a reasonable programmer, but it's far from proof of anything.

    You know exactly what I mean by 'engineer by nature'. They're the kid that always figured out how everything worked, much to their parents chagrin. The ones with an inherent ability to comprehend a problem, and analyze it, no matter what the field. Unfortunately, there's a shortage of those people.

    --
    "Don't trolls get tired?"
  • I'd bet that the professional programmers who DON'T have degrees in CS tend to consider themselves better programmers than the degree holders.

    The key word in that sentence is 'tend'. Out of the two best programmers that I know personally, one has a doctrait, the other dropped out of a fine institution. The key is that they both know how to learn, and how to apply knowledge generally.

    --
    "Don't trolls get tired?"

  • The evidence is the college degree.

    And before one judges, one needs to find out why the degree is lacking. I know a guy who was in an Ivy League school, when his mother got terminally ill with cancer. He dropped out so as to reduce his family's financial burden, and started working, but he never stopped learning. When he came to a topic that he couldn't learn on his own he read everything he could, asked those who were knowledgeable in the field and even sat in on a few classes, so as to steal a little education.

    He's not an architect, but I'd let him build my house.

    --
    "Don't trolls get tired?"

  • No offense, but what the fuck are you talking about? You're refuting claims which were never made. Perhaps you should run for congress.

    My point was that the talented, meticulous non-college-grad programmer exists. Period. Not that he's common, nothing else.

    The rest of your argument, well you're debating the voices in your head, buddy.

    --
    "Don't trolls get tired?"
  • I've been a team co-leader and had to deal with those programmers who don't have CS degrees. There are a few, a very few, who figure out that they don't know anything and who take steps to remedy it, but most are legends in their own mind. There was one programmer, for example, who wanted to argue with the two most seniormost software engineers in the company and the project manager because we wanted a generic database access class and he felt that was too much work ("each of these classes I'm writing only need one line of SQL code per class! Why do you want me to go to all the trouble of writing a generic database access module?"). Now, the three of us combined had close to 40 years in the computer business and had been through enough failed projects to know what happens when you tie your code to one particular database (hint: what happens when you change databases? Which, BTW, we did, close to the end of the project, when the original database did not meet performance requirements, but that was no problem because we had the database access class!), but this arrogant guy with no CS degree thought he knew better than all of us. Brilliant guy, actually, but a legend in his own mind, and refused to listen to experience, and argued about anything and everything even if it was something he knew absolutely nothing about. Maybe one day he'll learn. But I doubt it.

    And I have other examples. Example after example after example. But I don't feel like repeating myself.

    Note that I'm not saying that ALL programmers without degrees are arrogant know-it-alls who know nothing about software engineering and refuse to listen to those of us with the experience to know better. Just that, in my experience, that's the majority of programmers without degrees. These jerks aren't going to learn software engineering, because they don't think it's important. They think that creating programs is a matter of sitting down and writing a program, and all that "software engineering" stuff is just a waste of time. And when the software engineers running the project ask them to do something because it's a good engineering practice (such as, e.g., abstracting out the database access into a seperate class to isolate the program from the underlying database), they throw a fit because a) they don't understand abstraction, and b) they think they know better than us. Then they go complain to our bosses that we're not listening to them (when it's actually the other way around -- we tell them why we want, say, an abstract database access class, and they refuse to believe that our reasons are important). Poor little geeks, upset because we want them to follow good engineering practice instead of letting them hack unreadable unmaintainable spaghetti code all day. Sob sob sob.

    Okay, now that I've raised the flame quotient...

    BTW: On how to make software that doesn't suck: My advice is componetize, componetize, componetize. If the pieces of the project are individually testable parts rather than being part of a huge monolithic program, you have a chance (BARELY a chance) of making the thing actually work. I say "BARELY a chance" because over 80% of projects end up failing. Sad, but true, software engineering today is taught the hard way -- through exposing programmers to failure at every opportunity -- rather than in a formal way that would avoid all that waste of time, effort, and money. So I guess you could say that the definition of a software engineer is: "A programmer who has suffered through enough failed projects to know better."

    -E

  • What I have to say is that you are full of [BLEEP!]. Software engineering is Gant charts and schedules and such, of course, and those aren't much fun -- for the project leader. But if the project architect has done his job right, and if the project leads are doing their jobs right, and if they're allowing their underlings to do THEIR jobs right, it all works out quite well.

    Here's the way it worked in the last project I worked on: I had a document describing how I wanted things to work. I had charts describing the pieces of the project and how they fit together, as big block diagrams. We as a team decided what information needed to be maintained, and a database schema that would maintain that information (okay, so I provided the initial scheme and chart, but the final result deviated in some significant ways from my original). Then team members chose pieces of the project (or were occasionally assigned pieces, as needed), and wrote up how their pieces worked and what components were needed to make their pieces work (we had a template to use for this, but there was plenty of freedom to stray outside the lines). Then we wrote it, and had a blast doing it. I remember the guy in the cubicle around the corner asking me how I wanted a certain component that was in his sandbox implemented. I shrugged, said "Don't ask me, you're the owner of that subsystem. Just document the inputs and outputs so I know how to call your component, and leave the document on my desk." (I read the document to make sure the component did what I needed, of course, but usually that wasn't a problem -- by that time we all pretty well knew what we were doing). He was, like, boggled. I overheard him later saying that he'd never worked on a project before where he had such latitude, and that it was the most fun he'd ever had in any job anywhere. Yes, there was a daily meeting to check the charts and check each other's progress to make sure that each member was working on the most timely component in his sandbox (because there WERE dependencies between our components, and thus ordering did matter), and yes, we did document everything's interfaces (we had a template), but mostly it was just plain fun. Helps to have good team members too, folks who know their business and don't need hand-holding... I wouldn't have said the above if I hadn't known that this guy had 6 years of programming experience and knew the ropes. But even the lesser programmers ended up having more fun than in the typical blah kind of project where they were basically told "do this this and this" and given no lattitude.

    -E

  • If you don't know what needs programming, how do you know what you need to write? And how do you know that what you produce will be usable?

    A genius programmer once showed me a mockup of a GUI for a tape backup product. Now, I had used tape backup products back in my sysadmin days, but was definitely an end user, not an expert on the subject. His screens were incomprehensible to poor sysadmin me. I shook my head and said "I don't know how to use that." He called me stupid and said it was intuitive. It took two senior programmers and two managers to convince him that his work of genius was not acceptable because nobody without his genius could understand it.

    If they had just put this guy in a back room and told him to program the bloody thing, well, it would have wasted three months worth of time for an incomprehensible product. Sometimes it's important to get non-techie input into things -- or at least get the input of people who don't know anything at all about that kind of product (I knew very little about tape backup products, except "you stick a tape in, click a couple of buttons, and it does something useful").

    When I was doing school administration software, the first thing I'd do when writing a new module was track down a couple of my pet school administrators, arrange a meeting with them, and go over the specs, proposed screen layouts, etc. to make sure that a) it met their needs, and b) that the screen layouts looked intuitive and reasonable to their non-techie eyes. One time I got a design torpedoed three days before I had to have working code turned in (state deadline). To say I was upset was an understatement -- that was the last time I did something without running it by the non-techies *EARLY* in the design process! (In case you're wondering -- I consumed mass quantities of coffee, worked for almost 72 hours straight, and hit the deadline, but I was extremely scared driving the final product to the office that I was going to crash into something because I was starting to see things that didn't exist by then).

    I suspect that most of the problems that people have with non-techie input comes from lack of involvement with the end users at an early stage of the product design. Well, and non-techie managers attempting to tell you how to code (or managers who aren't in your direct line of command trying to tell you that they need buzzword X, Y, and Z... at that time, involve your own engineering manager to explain that features X, Y, and Z will be in version 2.0 :-). But if your engineering manager is part of the problem rather than part of the solution, it's time to get another job -- not time to dismiss the importance of outside input.

    -E

  • A team I was on recently finished a project that was 90% written in Python. It was my experience that a) 90% of my time was spent working on the 10% of the code written in "C" (sigh!), and b) I could write about the same amount of Python code in a day as I could "C" code, but the Python code did 10 times more stuff. And a lot of stupid errors like memory leaks and buffer overflows are impossible in Python, so there goes half the reason why the wuftpd motto should be "Root access for all since 1995!". All in all, I don't think we could have completed a project of that scale if it had been written in "C" or C++... there wasn't enough of us, or enough time, to write 10 times more code.

    The main reason we chose Python was because a) the runtime system was time-tested and well debugged on all our target platforms (say that about any JVM out there!), b) it already had good low-level access to the OS without having to do anything fancy, and c) it was easy to drop to low-level "C" code whenever it was absolutely necessary for performance (we have five new Python classes written in "C" to speed up particularly hairy operations, as well as some additional "C" helper programs). The only problem we experienced with Python was a conflict between Python threading and the GTK+ toolkit (accessed via PyGTK)... disabling threading in Python fixed that.

    All in all, I'd recommend the experience -- it taught me that "C" is great for small programs, but for large programs a "real" language makes things *MUCH* easier. (And don't talk to me about C++, C++ pretends to be a real language but at its heart is still syntactic sugar on top of "C"). While I have some gripes about Python (like, I want variable declarations so that a tpyo does not create a new variable and make me tear out my hair for hours trying to figure out why my progrma does not work!), I will never again voluntarily use "C" or C++ for any large project. (Famous last words, karma says that my next project will be in C++ :-).

    -E

  • What I meant was that the courses were too shallow, that they dont go deep enough. That I wouldnt expect anyone with a 4.0gpa BS CS to know how to handle the simplest of real world problems.
    Tsk, tsk. You should expect someone with a BS in CSCI to know how to do proper programming. Almost none of 'em do (and I say this as a student at one of California's best computer science schools, CSU Chico), but it's nonetheless a reasonable expectation.

    Classes are offered in proper OO design, but they aren't mandatory. The "software engineering" classes I've taken are a joke, but others are available -- but arn't included in the BS degree.

    However, any student who goes in wanting to learn to be truly good can come out knowing it. They may have to go far out of their way, admittedly. I'm presently involved in a great number of projects at my University because they're challenging and interesting; I'm recieving no credit for any of them. Frankly, these projects cost me money -- I could be putting the hours in on my job -- but they're fun and interesting, and help me meet people.

    There's no reason not to expect the same from everyone. If they don't measure up, that's their own fault -- not that of the educational institution.

    The stuff they teach in undergrad CS should probably be moved into high school CS. As soon a kid knows a little algebra, he should be offered a chance to learn some basic programming.
    Agreed -- and algebra (or at minimum basic problem-solving) should be moved into junior high.

    I recently spent some time tutoring some 8th grade students at a local school who expressed an interest in learning to program. Every last one picked up the syntax (Python) very quickly, and every last one was lost when it came time to exercise problem-solving skills. Even introductory algebra would have been a tremendous help -- but then, so would be experience playing with the right toys... [oh, what were those toys? made up of modules containing motors, batteries, axles, gears... had 'em when I was a kid. the modern, but more expensive, equivalent would probably be Mindstorms]

    One whole issue, however, is the expense. Where are these high schools going to get instructors who know how to teach programming? While having a volunteer who comes in on occasion (as I was doing) works reasonably well as an extracurricular activity, I doubt it could legally done for a core-curriculum class.
  • No one would hire an architect or mechanical engineer who didn't have at least a piece of paper from a college.
    Computer programming isn't engineering. At least not good programming.

    Engineers make things that are, in fact, very reliable. They've given something up for that. There is very little innovation in engineering -- civil, mechanical, and to a lesser degree electrical. There are conventional designs, conventional requirements, and conventional ways to meet these requirements.

    In most engineering, this lack of innovation isn't so bad -- highway overpasses don't need to be revolutionary to work.

    Some software also fits this kind of conventionalism. Some things have indeed been accomplished in conventional and reliable ways. Disk access, for one. Thank goodness everyone isn't designing their own disk-access routines. Or writing their own TCP/IP stacks. Or implementing their own C compilers.

    It's easy to forget this -- in software, when you come up with a conventional and reliable solution, and fit it in the right place in the system, it will stay there and very few people will continue to work on it. All the other problems are usually novel in some manner -- which is to say, conventional engineering practices are totally inappropriate. Engineers work on the conventional problems long after they've been solved. Thank goodness we don't have to.

    Yes, there often is a Right Way to do something, a way whose benefits you would only realizing by studying other projects, and making projects of your own. But the Right Way is usually an intuitive concept -- a matter of taking knowledge and experience from one place, and redirecting those to a new area. The most important design decisions are things you can't represent as a checklist, and you probably can't teach in the model of engineering. I'm sure you can teach that stuff -- but it's just not engineering, and you can't teach it like you would engineering.

    If you want to make a parallel between engineering and software, you have to use a fair comparison anyway. Think of making a car. It is as complex as a relatively complex piece of software. It has lots of pieces, but it pretty much does only one thing -- roll. They come out with revisions once every year or two, with minor skin changes every year. A successful novel design hasn't happened for decades -- heck, a century -- just an incredible amount of feature creap.

    Once again, thank goodness we aren't engineers.

  • It seems to me that these techniques, while sound, are one of two things -- either simply common sense, or needless rules.

    The problem with too much structure in a process is this: either you are making rules for things that are done intuitively, or you are confining the creative process. I have used a lot of free and open-source software, and I would guess that 80% of projects that are in the 'stable beta' stage are of higher quality that the average commercial application.

    YMMV, of course.

    --
  • Companies are willing to hire programmers without degrees for a combination of two reasons: (1) they can be just as good, if not better than, a software engineer (in some cases); and (2) they work cheaply.

    I know many programmers that, despite having no 'formal' training, can run rings around the Software Engineers I know. IMO, formal training often reduces the ability to think creatively -- once you are taught "the right way", it's hard to break new ground.

    All of that said, I do agree that companies hire people without checking thier abilities. When I interview a potential candidate, I ask them to design code for a small, arbitrary problem. If the design is solid and the code functions smoothly, it goes a long way.

    --

  • Re:Configuration Management Tools? (Score:3)

    by xdroop ( 4039 ) on Tuesday January 23, 2001 @05:42PM (#486999) Homepage Journal
    OK, I work with in a CM/Build team for a... uh... company of some non-deterministic size. We build large software products. We use various CM tools, some Open Source, some Free, some neither.

    The one lesson which has been hammered home again and again and again is that a tool is just that, a tool. It can not, and will not, substitute for good programming practices and procedures which control who does what and where. It cannot be used to enforce policy; all it can do in the best of circumstances is assist a policy. Any time that a tool or process is bypassed in some way it is an indication of a problem -- either with the process, or with the business environment surrounding the process.

    These are lessons many of us know, but few have learned, and fewer still apply. I know that we try, but we do not always succeed.
    --

  • While I like the message, and perhaps re-iteration is good for the PHBs, I think all of the coders who dwell on Slashdot know this and try to make it their own (well, the good ones do, anyway).

    And, if people aren't aware of what it takes by now, do you really think they're going to get it, now? Save for perhaps the younger folks just spreading their programming wings, I guess.

    Okay, fine. say it again. If a few people get the message it was worth it.

  • No, definitly not: You need noncoders during the development process, or your software will suck as well. Coders have quite a different view than normal users, and so they need someone to tell them "Hey, this is unusable", or "Hey, I'd like to do it that way".

    Non-Coders should talk place in the process, testing the product, working with it, helping to get it out, but they should stick to "easy" coding tasks: defining user interfaces and such things.
    The backend of an app should be reserved for they guys that know what they do ;)
  • It's called a _method_, for goodness' sake. Methodology is the study of methods.

    (and method is the shorter of the two words, so there's no excuse not to use it... unless you are trying to obfuscate by using long words.)
  • For those of us who code, develop, (or even make graphics) in the workplace, we often do not have the luxury of making our work not suck. The reasons are threefold:

    There is a fourth reason, though wizard programmers tend to pretend that it doesn't exist.

    4) Truly amazing procrastination

    Hey, I'm not proud of it either -- but it is real and I've seen it in myself and in others. There are some fabulous programmers that I know that will delay starting a project until the last minute possible because they aren't interested in it.

    It's an aspect of a prima donna, like a 10-year-old Pac-Man genius (or for you younger guys, swap Mortal Kombat for Pac-Man). Programmers do things that people can barely believe, much less understand, and because of it they are granted more latitude than the guy who sweeps the floor. Floor sweeping is honorable labor, but nobody has any illusion to the difficulty of it. Programming (even simple stuff like whipping up shell scripts for adding users) has an aura of difficulty to it like few other positions.

    The poster strikes me as a graphic designer rather than a programmer, which puts him squarely in the "prima donna" category, plus a healthy dollop of pretentiousness.

    (Don't get mad at me -- I'm a graphic designer by education and training, a proto-programmer by practice. I can speak with some experience on both sides, and I know a LOT of graphic designers. By their nature, they are, to a man, pretentious in varying degrees -- they must be in order to convice clients that they really DO know that yellow text on a green background is NOT the way to go, regardless of what the client may think)

    The end result is that a programmer doesn't like to work on something he finds dull until he's forced into it by the constraints of time. At this point slapdash and haphazzard rule the day. When the project crashes and burns, the time-honored strawmen of "management" and "marketing" are drug out to explain away the poor code or design.

    Don't get me wrong -- marketing and management sometimes are to blame (it's another corrollary of programming that M & M tend to think "anything that I don't understand must be easy to do" -- which is patently untrue). But to lug these two boogeymen around in your pocket to wave about whenever DiscoWordWriter fails to perform is to deny the possibility that you, the programmer, didn't do your job.

    No job is forever stimulating or even interesting. There are great tracts of desert called Dull-O, Repititious-But-Neccessary, and Being Part Of A Team between you and the end of your career. Sometimes this means manually inserting 200 entries in a database, sometimes filling out time cards, sometimes meeting with marketing and working out a problem with the feature list (without automatically assuming that they're out to get you).

    Of course, it's a lot more fun (and easier) to blame somebody else. Hell Scott Adams makes a pretty nice living satairizing Pin The Blame On Management.

    For example, to use your example of a poorly designed web site that your boss demanded that you build, going to your boss and saying "This sucks" (or the equivalent) is tantemount to saying "your dick's pretty small". You present a preliminary design as requested as well as a few options, either built from scratch or examples of other, similar sites that you like. Now, instead of questioning the size of his member, you're acknowledging his superiority (in the org chart, if not in reality) by asking his opinion and advice. Will he take it? Maybe, maybe not. If not, you at least know that this is a Turd Project, and thus fast-track it out of your life. If he does realize that there are better options, you have just bronzed that turd. Either way, your boss sees you as a valued employee and person rather than an automaton who spits out code/graphics.

    That's part of working on large projects. I'd rather have a mediocre programmer that works with a team and turns out 10 decent projects a year (that can be polished and perfected by better coders) than a wizard who turns out 1 brilliant but completely unmaintainable project who wont work with anybody.

  • I have to strongly disagree with the notion marketing and management sometimes are to blame as I believe that they are almost always to blame.

    ...and thus you agree with me. Almost always and sometimes are complementary.

    Bad programmer, good programmer, doesn't matter. Sometimes you're faced with a dull and/or stupid project, and you piss around on it, either subconciously or conciously sabatoging it.

    There are, of course, some bad programmers out there. And maybe my view is biased because I'm not a bad programmer. But there is certainly a good supply of bad middle level management out there. This I know.

    I'm not denying it. Programmers like to blame management, management likes to blame programmers... it's a sad, tired old story. Sort of a modern day koan.

    On your project that you mentioned that took 6 weeks instead of 6 months, buy you got a black mark for it? Was it for completing the job in a timely fashion, or for something else? Could it be because you didn't communicate with your boss about what you were doing?

    I got hammered one time because I was working away on something that I was asked to do by a VP in another department. I worked hard and got it finished -- and got nailed for it by MY VP. Internal power games? Maybe. Blind stupid management? Nope. These were smart, talented guys. My VP didn't want me working on stuff for this other VP because things like this screw up the bookkeeping and budgeting -- which, I know, is anathema to nerds, but is a reality and a neccessary evil. You can't run a large corporation, moving thousands of feet in the same general direction, without some kind of standards and guidelines.

    Tell you what -- you can trash management when you are in charge of a 150 person department in a fortune 500 company, and know from which you speak. Until then, you're just making gratuitous assertions -- which (logic teaches us) can then be gratuitously denied.

  • Try making a 30-screen database app in Visual Basic. Actually no; don't ever try that. Just beleive me when I say that it's damn near impossible to produce a good product that way!

    I've done it repeatedly. It's not nigh-impossible - it's just not like writing in C. You have to bring the same professional attitude toward it, though. Design well, profile before optimizing, refactor, test, test, test.

    Which "useful language constructs" are missing? Even in VB 3, which lacked even rudimentary object orientation, we (less than 4 full-time-equivalent employees) managed to write a 90+ screen casino accounting package. Performance was excellent even on the 486-100s of the time. Modern VB is far, far better, and VB.NET better still.

    I use other languages as needed. Perl is fine for anything that won't leave my own machine. Occasionally I'll find something I can do much much better in C than in VB - in which case I write a DLL and call it from VB.

    I agree with your point that experience is critical. Please consider that language bigotry is the enemy of experience.

  • Say no to stupid fucking requirements (Score:3)

    by gelfling ( 6534 ) on Tuesday January 23, 2001 @12:16PM (#487009) Homepage Journal
    Does it REALLY have to make toast, brush your hair, whisper in your ear, service the wife, numerically prove the existance of an afterlife, feed the world and have good beat you can dance to?

    C'mon scope creep and stupid fucking requirements (SFR) are what generate sucktocity and general sucktitude. How many times have you listened to some account weenie get on all 4s and scarf the customer over and over. "Sure we can do that, no problem !!!!!!!"

    But it's an SFR and it will kill you.

    It
    will
    kill
    you.

  • Re:Software Engineering will make software suck le (Score:5)

    by locust ( 6639 ) on Tuesday January 23, 2001 @01:41PM (#487010)
    I know many programmers that, despite having no 'formal' training, can run rings around the Software Engineers I know.

    The ability to hack, and knowledge of computer system internals, cannot be compared to software engineering. Software engineering requires knowledge of the design process, understanding of system design, and understanding of scheduling. It requires the ability to manage design, complexity, schedule, and people. These are the points where most programmers of all grades fall down... It is the core of why software sucks. Most of the people writing code don't want to manage. They want to design. They don't want to schedule. To them management and scheduling are a burden that takes them from the pure thought stuff that they love to work with it. The price that is then paid, is that people who have no concept of the tasks at hand are asked to do the management component. Unreasonable deadlines are set, features are changed without the proper estimate of the effor to make the changes...

    There is another thing to add to this. It is that people have been building things for millenia. Yet very little of this experience has been transfered to software design. Consider the planning and construction of a ship. Surely the techniques that are applicable in the engineering of that ship (remeber what I said about the management component of engineering -its what makes you and engineer not a scientist) should be to some extent applicable with in software engineering. Yet from my reading of software engineering texts this transfer has not happend. I think it has specifically to do with the sort of backgrounds from which people come to software. The theoretical underpinnings of software have always come from mathematics, where practical things like getting resources can be assumed away. A large number of the remainder have come without any education at all (self taught). They are not in a position to draw these links. They don't know where to look for the information.

    --locust

  • In C++, most of the memory management issues "go away" if you're prepared to add a level of indirection. For example, there's no need for pointer-arrays, since you have structures like vectors. There's no need to micro-manage (what should be) simple data types like strings. Of course, you're stuck with pointers when you want to dynamically create objects (with factories or prototypes) but even then, there are a lot of tricks you can do to manage these (gui widgets that manage their children, handle-body tricks).

    What java does seem to offer though is a fairly elegant framework for applications where performance is not critical. The "everything-is-a-reference" mentality makes it somewhat cleaner than C++. I wish they'd implement generics though, this is one of the big advantages C++ has over java. Oh, and I wish Sun would hand java over to a standards body also ...


  • First of all, thanks for the comments.

    The important thing to remember is that all of the recommendations fit together. You can take just one (simple design, comprehensive unit testing), apply it to your work, and see some benefit. If you use all of them together, the interactions will give you more benefit.

    If you avoid the tenets of 'simple design' and 'reduce complexity', you'll have lots of trouble testing things. You'll spend lots of time debugging complex interactions between components.

    However, if you decouple things, test aggressively, and use simple and sane interfaces whenever possible, you'll have less difficulty. It's not a magic bullet, but simplicity really is a virtue in this case.

    Finally, the idea that change is always more expensive in the future is a very pervasive belief in software engineering. I'm not so sure. I can't back it up, but I'm willing to bet that projects like the Gimp [gimp.org], Mozilla [mozilla.org], and even Apache [apache.org] have spent or will spend more on their ground-up rewrites than they would have spent refactoring and simplifying. (Heck, I'd pay money to get a set of unit tests with a web browser!)

    I have no way to prove that. Then again, that CS professor who said "It will cost more to change things in the future" couldn't prove it either, and I know he'd never worked with requirements that changed every two months.

    At least in the software I'm writing where I can use XP, it's helping.

    --


  • Most accountants do not have a degree in Accounting.

    Most of the best software engineers I have known have done degrees such as Physics, or don't have a degree - I am working with a guy my age, who has twice the industry experience that I do, because he didn't go to university. And he knows as much Software Engineering as I do, and I study it for fun outside of working hours. And we "do the right thing" when we're writing our software.

    Don't be elitist and assume that a degree is everything - my experience is that a degree is almost irrelevant, it's the experiences that you gain at uni that count, and it's industry experience and good tutelage from experienced engineers that make good programmers and software engineers.

    ~Cederic

  • Although I agree with much of what you are saying, I have to pull you up on the unit testing - how many open source projects have unit test suites that can be run in a few seconds and tell you instantly whether or not all the tests have passed?

    ~Cederic

  • You write your tests at a very basic level. And you test your tests.

    E.g. Lets take a very very contrived (and poorly designed) piece of software:
    I want to write a web browser. Lets keep it simple and assume I'm just connecting to a server, downloading some HTML and calling an existing object to do the rendering.

    First off, write a test testing whether you can connect to the server. Write the skeleton code of your connection class only as much as you need for your test to compile.

    Run your test - it fails. It has to fail; you haven't written the connection class yet.

    Now write the part of the connection class that connects. The test passes.

    Now shut down your test server. Re-run your test. If it fails, you know your test is working.

    Now write your test that checks whether you can download a file (ideally html) from the server. Run it. It fails - we haven't written the code to retrieve a file.

    Write that code. Run the test. Does it pass? If it does, we've finished that piece of code. But, remove the file from the server. Run the test again. Does it fail? It should - if it doesn't, it's not testing the right thing. Put your file back, and move on.

    We need to validate that we got a file back (because our last test failed when the file was missing) - so write a test that validates this. Run it. Does it pass? Assume it fails. Ok, change the connection class so that the validation works properly. Run your test - does it work. Yes. But, while adding the validation, we broke the file retrieval. And now that test is failing. So now we make the changes needed so that the file download test works.

    Run the tests. Always run all the tests. Do all three pass? If so, move on. If not, fix the code.

    Suddenly we have a complex connection class, that's doing connection, validation, file retrieval. Disregard for the moment our poor design, ignore the obvious refactorings that are leaping to your mind, and consider the tests. Do we trust them? Yes we do - we've built them individually, we've tested the integrity of each test by making sure we can force it to fail, and one of the tests has already caught a potential (albeit obvious) bug for us.

    So taking a methodical approach we can build up a suite of 4-500 tests, and be sure that they all work. And since they all pass, we have an immense amount of confidence that our system works.

    ~Cederic

  • It's not new, but XP is the first methodology that I've seen that takes unit testing to the extent that it does. And what frightens me is that nobody taught me, showed me, even suggested to me that such testing could so easily be done, so effectively, and with such a beneficial outcome on the code I write. I owe Kent Beck, Martin Fowler and a few others (whose books I've bought) big thanks for that alone.

    ~Cederic

  • Most of the steps suggested in the article will result in better code being produced in less time overall.

    Plus, if your manager asks you what you are doing, and you answer, "Writing tests" then he's going to love you.

    Sneak these practices in the back door. Or even talk to your manager about them - complain about the low quality code you are being forced to produce. Demand the resources to do it properly. Insist on being permitted a small degree of professionalism. If you approach your boss with a list of things that are wrong with your current development process, and some suggested steps to improve them - especially if they involve writing tests, meeting user requirements and using source control systems - then if he doesn't agree these are good things then it's definitely time to find a new job.

    ~Cederic

  • Buy the book "Refactoring" by Martin Fowler. It has a whole ton of useful advice, techniques and methods for people in your situation. I rate is as perhaps the single most useful software engineering book I've read.

    For instance: If you are going to change code that isn't unit tested, then add a test for just that piece of code you are about to change. That takes a few minutes only. And add tests to the other parts of the system only when you change them.

    And use tests to recreate the bugs you are about to fix - then you know you've fixed it (because the test passes) and you'll know instantly next time someone changes the code to make the bug occur again - because your test will pick this up.

    ~Cederic

  • Re:Software Engineering will make software suck le (Score:3)

    by panda ( 10044 ) on Wednesday January 24, 2001 @03:01AM (#487029) Homepage Journal
    As a matter of fact, yeah, I've had friends who aren't architects, design and build their own houses, Steve for one, and some friends of my mother were doing it in the seventies, 'cause I recall being 8 and helping to paint it.

    In Steve's case, both he and his father worked out detailed prints on a drafting table and built the house themselves. They passed all the zoning commission rules at every step. Neither of them is an architect. Steve's a "software engineer" and his dad's a coal miner.

    Anyway, I know for a fact that degrees prove nothing. I've met plenty of folks with CS and Enginerring degrees who couldn't write decent code to save themselves. I've had to fix their crappy designs. I've met plenty of "hackers" w/out degrees who can program circles around me, and yes, I have a MS in Information Science so I have *some* formal programming training.

    The reason most software sucks really has nothing to do with the qualifications of the people writing the code or with anything that was cited in the original feature above. The real reason that most software sucks is that business managers impose ridiculously tight deadlines on the programmers, so there isn't time for adequate testing, code review or even real design. Real design involves a lot of prototyping and trial and error before you actually begin work on the final product. That's the real problem.

    The real reason that Free Software is better than commercial is that there is no definite release schedule, so you, as the programmer, have the luxury of releasing the code when you think it's ready and not when some arbitrary deadline set in a board meeting tells you have to.

    It has also been my experience that managers tend to have one view of what happens in software development, and what actually happens is something totally different, and that has occurred even with managers who had programming experience in the past. They seem to think we're all wizards and we just pull this stuff out of thin, and everything is "a fifteen minute fix" including refactoring and rewriting the entire application from scratch.

  • CMU currently has an undergraduate software engineering course in the CS department. The course tends to turn out pretty lousy projects in the end. Last semester they focused too much on the process and too little on the code (as they left around two weeks to write code and shoved test under the table). Some semesters go better than others.

    At least one of my undergraduate courses (Distributed Embedded Systems, in the ECE department) had a significant focus on the process of designing and managing an embedded system. We used a watered-down UML and requirements, wrote tests suites and did forward and backward traceability to make sure the requirements matched up with the diagrams. Then we wrote code (and had a very short debug cycle because we found most of our bugs in the design before coding).

    There are also graduate courses in and out of the SEI building which explore (or attempt to fix for real-time embedded systems, in the course in which I am currently enrolled) these processes.

  • I will echo the response of another and say that the type of testing that was talked about in that book, and the type of testing that XP advocates are different things.

    XP also combines extensive unit testing with a couple of processes (pair programming and refactoring) that mimic what you might achieve with formal inspections without actually having formal inspections.

  • Re:Software Engineering will make software suck le (Score:3)

    by Bongo ( 13261 ) on Tuesday January 23, 2001 @03:18PM (#487035)

    I still have a standing offer: will anyone have an architect without a degree design a house they would then live in?

    Le Corbusier, detested by his contemporaries (they built a high wall around his exhibition house to hide it), got, if I recall, a third (just passed) at college. But he's now considered generally one of the greatest architects of, er, last century.

    An architecture tutor once told me that, effectively, the lower your degree qualification, the more you'd end up earning.

    Certainly I don't wish to dismiss university qualification. It's not a free ride. You do have to work, do the necessary things, to achieve it.

    The debate here is whether those necessary things are the best/only way to produce a skilled individual. Especially in a field like architecture, where creativity and practicality have direct effect on the cost of a project, not to mention the highly intangibles like cultural depth, style, social engineering concerns, and philosophical and ethical standing (what's more valuable: reducing energy consumption, or reflecting the Zeitgeist?).

  • Re:Software Engineering will make software suck le (Score:4)

    by Bongo ( 13261 ) on Tuesday January 23, 2001 @02:58PM (#487036)

    Would you hire an architect to design a house for you without formal training?

    Just to pick up on this point, I read an old book written before architecture was professionalised in the UK. It argued against professionalisation, and made many "good points". I can't remember them all, but one that stuck in my mind is that the qualities of a good architect cannot be formally tested.

    Prior to professionalisation, people who were artists, perhaps sculptors, and who were also builders, could work as architects. Both the qualities of a good artist, and the qualities of a good builder, were proven by practical experience. Reading art books does not make you a good painter. Nor does looking at diagrams make you a sound builder.

    One of the main complaints that the book tried to make, was that while the natural artist/builder may be excluded from practicing architecture, the good bookworm would easily 'qualify'.

    So indeed we end up with only those 'architects' who are good at passing exams.

    Being able to remember textbook diagrams and calculations and history essays, for exam regurgitation does not guarantee any practical understanding. Note that doctors spend a lot of time training in hospitals. But architects are trained in studio/lecture theatre conditions that bear little relation to real world practice. Still confident about that architect you want to hire?

  • I have to strongly disagree with the notion marketing and management sometimes are to blame as I believe that they are almost always to blame. But it's not always pushing to get a product out faster, though that certainly is a huge problem. The first web project I did, I completed it in 6 weeks, including all the testing, when it had been originally estimated by middle management to be 6 months. I got called in to the meetings because I ran the servers it would run on, but ended up developing the whole thing, which ran bug free and fast. The department the project was for loved it. But management treated it as a NEGATIVE on my semi-annual review (so I started job hunting then).

    There are, of course, some bad programmers out there. And maybe my view is biased because I'm not a bad programmer. But there is certainly a good supply of bad middle level management out there. This I know.

  • If anything, software engineering should be like an apprenticeship.

    And I agree completely. As I said in my original post, a CS degree is NOT a Software Engineering degree, and it's training in Software Engineering which is needed. An apprenticeship should certainly be a part of the program.

    So I think pretty much everyone (except you obviously) knows that they are not hiring geniuses

    No, the problem isn't that you think you're hiring a genius, it's that the untrained ignoramous that you hire thinks of HIMSELF as a genius.

    There was a well-publicized study in 1999 or 2000 on just this topic. The more someone knows about something, the less competent they tend to evaluate themselves. Conversely, the less someone knows about something, the more they think they are competent. This leads to wildly unrealistic self-evaluation.

    I'd bet that the professional programmers who DON'T have degrees in CS tend to consider themselves better programmers than the degree holders. Draw your own conclusions.

    -jon

  • This same problem faces universities trying to create a software engineering school that is teaching to an ever moving target.

    And yet Chemical Engineering and Electrical Engineering can be taught. Amazing, that. I guess there haven't been any advances in those fields, either.

    If Software Engineering has changed SO much in the last N years, why is "The Mythical Man-Month", written before most /. posters were even born, still considered the best book on Software Engineering ever written?

    -jon

  • Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments

    http://www.apa.org/journals/psp/psp7761121.html

    -jon

  • I would LOVE to live in a house designed by Frank Lloyd Wright. No architectural degree - he studied civil engineering briefly.

    Wright's houses are known for problems like, oh, serious leaking roofs. As an architect, he made a great self-promoter.

    Are you going to tell me you are a better programmer than John Carmack? Do you really think you have a better handle on software engineering than Microsoft's Chief Software Architect(funny, but yes, thats his title).

    I'm certain I have a better handle on the principles of Software Engineering than BillG. He, however, is a far better businessman than I am.

    Ellison, AFAIK, isn't a programmer. But I could be wrong.

    I know about Carmack's game work, but I've never seen his code. I don't do game programming, but the little I do know of game programming indicates that well-ordered, maintainable code isn't a high priority--fast running, fast-completed code is. Most game codebases have about a 6 month life span, with no significant updates. In-house commercial software will last for 30 years, with constant updates. How would Carmack do in this environment? I dunno, and since he's stinking rich and happy from working on games, we'll never find out.

    Something like 100,000 software jobs open up every year, while our universities only graduate about 30,000 people with CS degrees. So why not have industry-standard apprenticeship programs.

    Sigh; people should read my original post before replying. I agree completely that the current CS curriculum is NOT sufficient. I agree that an apprenticeship is an excellent idea. But a CS degree from a good school is a hell of a lot better than nothing.

    Non-Traditional Students present a problem to the process, as the process wasn't designed for them. But retraining as a software engineer should be formalized, even if done at nights and at odd hours. And jobs in software are great,in the meantime, just as law students work in law offices before they pass the bar.

    -jon

  • There's nothing dangerous about Ayn Rand's books (there's nothing dangerous about ANY book); they just aren't well-written. If she had spent some time learning how to structure a story and develop characters, she might have created literature. But instead they are just the dogmatic holy books of a very silly cult.

    -jon

  • The fact is you CAN'T judge everyone on a case-by-case basis. There's no time. You need to filter when hiring. And a top-notch college education is a good filter. So are verbal and written communication skills. A resume submitted on a napkin is likely to be tossed no matter how smart you are. A person who can't compose a coherent thought during an interview isn't going to be hired. Such is life.

    By the by, getting into AND graduating from a good school doesn't require money, which is implied by your "snobby college kids" remark. I had friends in school whose families were of incredibly limited means; dirt poor would have been a step up. They had to work harder than everyone else (work study jobs on top of classes, large loans to pay off after school was over), but they did it.

    -jon

  • Re:Software Engineering will make software suck le (Score:3)

    by TWR ( 16835 ) on Tuesday January 23, 2001 @02:58PM (#487046)
    I would...if they could prove to me that they knew what they were doing.

    And if you yourself were not well-versed in the art of architecture, how would you be able to judge?

    Well, you might rely on the opinions of others who were able to judge. Perhaps there would be some sort of professional organization you could check with, see if this architect is a member.

    And how does the professional organization let members in? Usually some sort of coursework or test must be passed.

    And how does one prepare for this test? Well, probably some practice, as well as some instruction from others versed in architecture.

    Gee, sounds a lot like getting a degree and going through formal training, eh?

    As I've now said repeatedly in this thread, a CS degree is NOT proof of skill as a software engineer. But lacking other tests, it's the best we've got. Discounting it because it isn't perfect is, quite simply, dumb.

    -jon

  • Re:Software Engineering will make software suck le (Score:4)

    by TWR ( 16835 ) on Tuesday January 23, 2001 @11:13AM (#487047)
    IMO, formal training often reduces the ability to think creatively -- once you are taught "the right way", it's hard to break new ground.

    Bah. Would you hire an architect to design a house for you without formal training? (I don't want to hear about Howard Roark; he's a fictional character in a poorly written book) Would you hire an untrained civil engineer to build a bridge for you?

    There is no relationship between formal training and creativity. There IS a relationship between formal training and knowing what will work. Geniuses know how to push the limits on what will work and create new paradigms. Most untrained people in any field (and heck, most people in any field) are not geniuses, and the less people know, the more likely that they think they are geniuses. That's the real danger.

    -jon

  • Software Engineering will make software suck less (Score:5)

    by TWR ( 16835 ) on Tuesday January 23, 2001 @10:56AM (#487048)
    The real problem isn't a particular methodology like XP (which does have good ideas in it), it's the complete lack of professionalism in the software industry.

    How many times have people heard of programmers with no degree working on or designing large-scale projects? It's insane. No one would hire an architect or mechanical engineer who didn't have at least a piece of paper from a college. But it happens all the time in software. The costs of the defective systems being turned out by untrained programmers is starting to matter.

    Even a CS degree really isn't a sufficient solution to the problem. Software Engineering is NOT computer science, just as Chemical Engineering is not Chemistry. You need knowledge of the latter to do the former, but there is a different skill set which must be learned. Unfortunately, I'm not aware of any school which is teaching it to potential software engineers. When they do, real software development can finally begin.

    -jon

  • Re:Software Engineering will make software suck le (Score:5)

    by TWR ( 16835 ) on Tuesday January 23, 2001 @01:01PM (#487049)
    I believe he's referencing a paper whose subject was "Incompetent people fail to understand that they are incompetent, thus overestimate their skills." Hardly ground-breaking research.

    No it isn't ground-breaking to know that ignorant people don't know they are ignorant; the authors of the paper quote Charles Darwin: "as Charles Darwin (1871) sagely noted over a century ago, 'ignorance more frequently begets confidence than does knowledge'."

    What was ground-breaking was showing that people who weren't ignorant downplayed their skills; they "knew what they didn't know."

    He makes the flawed assumption that college graduates make a better effort to continuously hone their skills than non-graduates - a claim with little to no evidence, at least none that he has shown.

    The evidence is the college degree. It's a hoop to jump through; a painful, stupid hoop sometimes, but a hoop nonetheless. Get a science or engineering degree from a top-tier school and it says that, at the very least, you know how to work and to think. Skip that process and pretend that it doesn't have any value and it says volumes about you.

    I trust in top-tier universities to separate wheat from the chaff because I don't know of any other process which is a better way to judge someone just starting out. Can you name one, or do your skills only lend themselves to criticism?

    I still have a standing offer: will anyone have an architect without a degree design a house they would then live in?

    -jon

  • This is a really good point. If your program depends on third-party libraries, then you must test the libraries too. If you just assume they are perfect, you are asking for trouble. Perhaps your new code is reusing the old library in a way or context unexpected by the library's designer.

    Of course, you don't really need to go a write a complete test suite for every library you use. That's tough, especially for closed source libraries. Since you probably only care about bugs that affect your program, then your program's own test suite should cover those test cases already!

  • Frank Lloyd Wright are completely static, unadaptable to their inhabitants' needs. When his clients often complained that their roofs leaked, Wright would tell them "that's how you know it's a roof" and refused to fix it. Wright homes are well known for their leaky roofs. He built the building HE wanted, regardless of the client's wishes.

    Perl and Linux, however, are very flexible organisms, grown incrementally and organically to meet precisely their users' needs. Exactly the opposite of Wright's design mentality.
  • > A couple of famous people in the industry you may have heard about: Bill Gates ... Do you really think you have a better handle on software engineering than Microsoft's Chief Software Architect

    Frankly, I think my handle on SE surpasses his by about the same amount that his bank account surpasses mine.

    --
  • > The difference is that building a bridge or an engine takes huge amounts of capital

    An even bigger difference is that people don't expect a bridge to fall down every third or fourth time they use it, whereas with software they think that's normal.

    > When I looked at the curriculae at a few colleges offering degrees in CS, I had to laugh. They teach almost nothing

    I think you meant to say, nothing that you hold valuable.

    > Ive met PhD's I wouldnt wipe my shoes on. It seems like programming skill is inversely proportional to academic accreditation.

    I think that's an unfair generalization. Sure, there are people with PhDs in theoretical computer science who don't need to be 1337 44x0r5 to do their work, and maybe you and me can program circles around them. But can we compete in their field? CS is about a lot more than just hacking out code. (Arguably, hacking out code is for us bottom feeders, with the 1337 doing the design work and the 1337er doing the theoretical work that the designs are based on.)

    And then there's the PhDs who do their dissertations in other fields of CS. I know CS grad students doing their PhD research who write code by the metric ton, sometimes for extremely complex algorithms. And have to know how to use big piles of other utilites to do their work, too. And maintain their own systems and networks. And publish their research code for all the world to see and criticize. I suspect that some of them could compete with the 1337357 of hackers in terms of doing a hard job well.

    Don't get me wrong; I have immense regard for people who are self-taught professionals, in CS or any other profession (or hobby). But that's no ground for bashing formal education.

    And frankly, I think the cure for reliable software is going to come from the adoption of formals methods and other mathematical stuff that I'll never be very good at.

    --
  • My Theory of Responsible Software Design:

    If you're having fun doing it, you're probably doing it the wrong way.

  • This is not groundbreaking, but it's IMPORTANT (Score:3)

    by drenehtsral ( 29789 ) on Tuesday January 23, 2001 @11:19AM (#487060) Homepage
    I always see a lot of people saying "this is all just common sense" or "this is nothing new" or whatever, but if people followed this set of guidelines, there would be a lot fewer bugs out there irritating computer users.
    A similar strategy is set forth in some of the newer computer programming books i've seen including "The Practice of Programming" and "The Pragmatic Programmer", both of which aim to develop habits in programmers that cause them to produce cleaner saner code in a practical and intuitive way.
    I think this is important because it is a practical alternative to the people who say "all programmers should be licenced and regulated, they should all have degrees, and all their code should be mathematically proven and group audited" while this will produce space-shuttle or medical-instrument grade applications, it will also produce space-shuttle grade costs. When you have to pay $125,000 per seat to use your word processor, but it's bug free, it's just not worth it.
    These common sense practical approaces are more efficent than standard high pressure, low quality, commercial software development in terms of man-hours spent developing the same software, and as an added bonus, the software works better, and when it does have bugs, they are easier to track down.
    So, no it's not new, it's the advice from older programmers who have been doing this since _way_ before i was born, so i should listen to it, not ignore it because it's not new....

  • Configuration Management Tools? (Score:3)

    by a.out ( 31606 ) on Tuesday January 23, 2001 @10:57AM (#487061)
    How important do you guys value Configuration Management Tools (tools that aid in the process of developing software)? I think they are very important to the development process. If you don't use them you're dead in the water.

    The design, development, testing and deployment of software is a very iterative process. What kind of tools do you use that you have found to match this process and be very sucessfull?

    I realize that these tools have to be easier to use and have more benifits to using them than not to use. But what would be an ideal situation for the development of "software that doesn't suck?"
  • [As long as non-coders are involved in coding...] software will continue to suck.

    Non-coders can not and do not, by definition, get involved in coding. If what you mean is that non-coders should not influence coding, I'd have do disagree. If anything, many of our problems are caused by non-coders not being involved enough in the development processes. QA should be involved in the requirements phase to ensure that something's testable, support should be involved to ensure that it's supportable, and users should be involved to ensure that it's usable. Often this involvement would be beneficial in the design phase as well. Obviously it's wrong to let these people determine how the actual code gets written, so long as it meets requirements, but non-coders do have useful expertise that we can and should use to make products better.

  • One issue that this article doesn't bring up, and that many software engineering books ignore, is that sometimes all of the processes in the world won't help your software be more stable because of reliance on other software.

    Excellent point! Many of us spend most of our professional lives working on software to extend an existing system in directions that its designers never intended it to be extended. Most kernel software fits into this category, for example, and we all know that's the only kind of software Real Men worry about, right? ;-) In any case, it often feels like we're in hostile territory, and there really are few guidelines as to how it can be done safely and cleanly. Too many of the well-known methodologies assume total control over one's environment, making them relatively useless for many environments.

  • The fact is you CAN'T judge everyone on a case-by-case basis. There's no time. You need to filter when hiring.

    I've had to wade through some pretty deep stacks of resumes in my time, and I've never had to resort to filtering criteria as superficial as what you suggest. There is always enough time to look beyond the name of the school (if any); every candidate puts something on their resume besides a school name, that they think will help convince you to hire them. If you don't look beyond the alma mater you are shortchanging both the candidate and your employer, and failing in your professional responsibility.

  • I've been a team co-leader and had to deal with those programmers who don't have CS degrees. There are a few, a very few, who figure out that they don't know anything and who take steps to remedy it, but most are legends in their own mind.

    The above would have been just as true without the phrase "who don't have CS degrees"; it's a common trait among programmers, degreed or not. I've seen the kinds of behavior you describe from many people with degrees, many times. In fact, I'd say that in my experience the people with degrees - particularly advanced degrees from "good schools" - are the most likely to have the attitude that they already know everything and don't need to learn anything else ever again.

    Another advantage to programmers without degrees: they're never snobbish prigs about their or other people's academic backgrounds.

  • XP is no panacea (Score:4)

    by Salamander ( 33735 ) <jeff AT pl DOT atyp DOT us> on Tuesday January 23, 2001 @02:11PM (#487068) Homepage Journal

    OK. With all due respect to its creators and proponents, I think this XP meme has just gotten out of hand. Even some of XP's most ardent supporters admit, in moments of much-appreciated honesty, that its value depends on a certain set of assumptions about project type, size and environment. Check out this article [extremeprogramming.org] for an example.

    XP uses iteration as a central theme. Iteration is great. I've hardly ever seen a program that wasn't significantly better on the second try than the first. Many older methodologies are based more on decomposition as a central theme...and you know what? Decomposition is great too! Divide and conquer, oh yeah. These are both incredibly useful tools which should be considered to complement rather than compete with one another. Any experienced programmer knows to use both, instead of being seduced by the abstract simplicity of methodologies based on only one.

    I see it as an issue of "step size". XP and other iteration-oriented methodologies work best in systems where functionality can be added in small increments without requiring deep structural changes every time. A very large class of programming tasks, including GUIs, meets this requirement. XP tends to fall down, though, in cases where a huge number of things all have to work in concert to get any positive results at all. OS kernels come to mind. Decomposition should be the first tool you reach for in those cases. Maybe you can apply XP or other iteration techniques once you've broken things down, but there's no way around the fact that you have to break them down first.

    Another difference is that XP is experiential and interactive, while other methodologies attempt to be more predictive. We all know the problem of trying to predict the unpredictable. However, prediction is not entirely without value. A thorough familiarity with the problem domain, combined with some elementary application of statistical principles, can yield predictions that are startlingly accurate for most projects. Those predictions can be used to achieve near-optimal resource allocations throughout the life of the project, instead of keeping "excess capacity" available for the project's peaks and troughs. Much of standard methodology is about making such predictions as accurate as possible. Nobody expects them to be perfect, but the better they are the saner life will be - not only for managers and customers but also for developers who won't have to put up with absurd expectations during an extended "crunch time" at the end of the project when everything they punted on comes back to haunt them.

    I guess what I'm saying is that XP is half a solution. It's great, get the word out by all means, but adopting XP will not solve all "software sucks" problems and in some cases it will make things worse. If you know anything about horizon effects and hill-climbing problems from AI, you should know the dangers of incrementalism, and XP is an incremental approach.

  • The problem isn't usually the implementation, but the lack of proper architecture and definition... once the problem is clearly defined, any good programmer can solve the problem. Getting the puzzled divided into the proper sections, and making sure that all of those pieces fit together in a nice way - that's tougher.

    Software engineering isn't about the "passed in this stuff, do a bunch of stuf and spit this out" as much as it has to do with defining what will be passed in, what is spit out, and properly controlling those interfaces. Since you have already given them a small, defined problem, the Sotware Engineering portion is taken out of the equation. It's architecture, control, and testability, rather than the specific methods to a given function.
    --
  • I've hit the +50 karma cap. Does that mean I won?

    No, it means you, like myself, now can feel free to post drivel because there is no negative feedback! Yay! What a great system!

    (ex- ~150 karma)
  • I always write my test cases first. Well, I write the first test case :) Then once I've written the code I think of a few more test cases and add them to the test unit. So for example, if I have a class called Power, I create a class called test_Power and add a function to test each of the functions in the Power class. I then put a main func in the test_Power.cpp file and put the tests as the first thing in my make script. Just the other day I had an interesting one. I had to go down and up two sorted (stl) lists and build sets of the data within a certain range. Then I had to do a set intersection of the two sets and return the resultant list. For my test case I generated random data and pumped it in. The result was scary. I would do a make and get a segfault. Sometimes I would immediately see the problem and go and fix it, do a make and get another segfault. Moral: throw enough random data at a function and it will expose all your bugs. So after the segfaults are fixed you're left with the cases that run to completion but give the wrong results, which is even more annoying. So then you usually have to fire up gdb and figure out what exactly went wrong. Oh, and you can get carried away with this. Sometimes you think: I'll run the tests overnight and see if it fails any tests on some obscure case and just when you think it is rock solid it will fail a test after 10 hours of running. You have to be careful using random data too cause you're test data might be so random that is nothing like what will actually happen when you start using that function. ok, I've rambled enough.
  • Yes.. it is not flawless but it is better than coding the function and then saying "oh, that'll do.. I guess that'll work" and then some blatantly obvious test case crashes it and causes a segfault that the user just sits there staring at dumbfounded. Oh, and writing the test case first makes it easier to write the function and thus increases productivity. Surely you are aware that hunting down bugs is the biggest time drain in development?
  • The key to XP is that he (Kent Brock) insists that you do all these things to extreme (thus the name). So you should write automated tests, intergrate quickly, pair program (yes, that's pretty lame but you can replace that with a less extreme "peer review"), etc. All this stuff works together to create tight feedback loops that get you to market under budget and before schedule with quality software.
  • it is an interesting point. The warranties would have to be significantly vague however, no-one expects bugless software, that's just too damn hard. Maybe when we have good verification techniques this could happen, but that will require good specification techniques :)
  • I know guys that have written very good database oriented systems in VB. They're M$FT geeks but they can produce a product.
  • no, as in they cant code for anything except microsoft products.
  • oh and M$ft geeks learn to use Microsoft products by paying for books.
  • how many hundreds of years have we been building bridges and houses? The problem with formal training of Software Engineers is that the stuff that academics think that software engineers need to know is a lot different to what industry thinks they need to know. If anything, software engineering should be like an apprenticeship.

    Oh and the reason why we call people "geniuses" is because they are a minority that have higher intellect (or whatever the hell you want to call it) than the majority of the population. So I think pretty much everyone (except you obviously) knows that they are not hiring geniuses, nor do they expect geniuses (actually that's one of those things about geniuses, you never really expect to run across them).
  • Your statements are wrong. You can't just rely on unit testing alone to fix all the bugs or "suckiness" in an app. It takes a lot of time to test the simplest app, time usually the programmer doesn't have. Envision "Quality Assurance" that does a helluva lot more than "unit testing".

    How about usability testing? While the coder may make a program that he/she finds logical to use(not necessarily easy to use), the general public(unless you're just writing the software for yourself) may find it extremely difficult or impossible.

    Your statements about non-coders should stay away from the coding process(or perhaps I should say development process) sounds a bit elitist.
  • It turns out that the company I work for, the group of people who actually implemented it, and the company who actually runs the cellular system - all did not like the CALEA law. We didn't want to have to implement it, we didn't want them able to do the tapping, and the service provider didn't want to have to deal with it. But those aren't acceptable choices.

    The "tapping" in the system I worked on is actually set up pretty well. I'll describe things the best I can from what I know...

    To the system, the module that is used to do the tapping appears to be just another module that calls are routed to. So it's pretty transparent there.

    To tap a person's phone, law enforcement must show up at the service provider site that the suspect is located in. They have to present a warrant, which states whether the just get call identifying information (who calls whom), or if they actually get to listen in also. Service provider personnel, not law enforcement, provision the appropriate subscriber for surveillance. And law enforcement have to provide the actual box that lets them decode call information/listen to the call.

    The system always errs on the side of not providing information. It doesn't go out of it's way to hunt down information for failed calls, for example - if it's easily accessable, the information is provided, but it doesn't make any extra effort.

    The system ONLY routes the information for that specific call to the law enforcement tapping module. They will never get call information for a call that would not be covered by the warrant.

    We made effort to make sure their tapping was high quality, reliable, efficient, etc. But we always tried to give them the minimum information we had to. So for at least one specific cellular system, I can say you won't have to worry about them being able to arbitrarily snoop in on your calls. On the other hand, if the judges are granting warrants without good reason, then it's a whole new ball game...
    ---

  • Process and Testing (Score:5)

    by Saige ( 53303 ) <evil.angelaNO@SPAMgmail.com> on Tuesday January 23, 2001 @11:03AM (#487096) Journal
    As the article said, those two are by far the biggest steps you can take toward making good, quality software.

    I recently helped to add that CALEA surveillance garbage to a certain cellular system that was kinda news recently due to working with Sega on games for the subscriber unit, etc, etc. I didn't want to do it, most people I worked with didn't want to do it, but we still took the time to do it right.

    We followed software processes, tailored to eliminate unnecessary steps, and adding ones useful to us. We did quality unit testing on everything we touched, including functions that had been around for years. We re-wrote any DOL and function comments that were hard to read or out of date. And that was most of the old ones we touched.

    We took the time to break old functions that had grown complex (20+ cyclomatic complexity) into smaller pieces.

    Guess what? Not only were we just about on schedule (even with the extra time fixing problems left by other people), we found defects that had been sitting around that nobody knew about, and within maybe a month from the time we hit the system test lab, the area of the box we worked on was more or less defect free.

    We put more effort into process and testing than people had before, and had one of the best quality releases the department has seen. In fact, we've been spending months trying to find things to do because time that was set aside for us to fix defects found in testing and the field has been idle, because they haven't been coming in.

    We're not talking about minor changes either. 13 people, months of work each. The other feature that was in the release at the same time as us was smaller, and had fewer people, yet more defects, and took longer.

    A process for the sake of process, well, isn't a good idea. One that is based on doing things that work, and changes with feedback, becomes a great thing to have.
    ---
  • Why is it that geeks feel the urge to call celebrity geeks by their first name only?

    Because the geek's brain is capable of optimizing away the second part of the label when it is not necessary for proper human dereferencing.

  • Frank Lloyd Wright (Score:5)

    by pos ( 59949 ) on Tuesday January 23, 2001 @12:18PM (#487104)
    As somone who has quoted Wright in my sig for some time now (See the article dept.) I feel I should point something out.

    Wright saw things as a whole object. He spent months thinking about the construction of Fallingwater and visiting the site. He drew the first concept draft in about 3 hours. (he actually called the client to come over and see what he had drawn before sitting down to draw it) It changed Very little from that initial drawing. Most experts at the time said the horizontal balconies would not stay floating out into space the way they do and would collapse. The workers were constantly changing the plans because they did not have faith in Wright's design. (Modern analysis now shows that these workers acually ended up weakening the structure)

    As someone who has actually walked through fallingwater, I think one could easily say that the design is the most elegant, natural design you could possibly want.

    To apply Wright's ideas to the concept of software engineering: I would say you either have to be very gifted in how your brain processes/sees information, data and functionality, or create a system that is whole and complete through lots of careful adjustments and evolution. The latter seems to be the common OSS approach however the former is the more respected/impressive way. :) I suppose one could argue that even Wright evolved his prarie style and his catilevered/fallingwater style over several hundered homes. I guess I can see some similarities between Wright, Torvalds, and Wall among others. (inspired design, excellent execution, and refinement over time)

    I think the important lesson here would be that all of these people create something that stands as a whole unified concept that doesn't sprawl out where it doesn't belong and is fundamental enough to change the way other people see the world or problem space. They all thought about their designs A LOT! They are all artists and craftsmen.

    Wright's work inspires me and fills me with awe, as does perl and the linux kernel. Does your software?

    -pos

    The truth is more important than the facts.

  • Unit testing isn't all it's cracked up to be (Score:4)

    by soaper ( 63056 ) on Tuesday January 23, 2001 @11:32AM (#487108)
    "The most powerful weapon in your toolbox is comprehensive unit testing"

    It's this kind of thinking that causes too many of the problems you are trying to prevent.

    According to _Programming Productivity_ by Capers Jones, unit testing, will only find 25% of the defects. At its best, unit testing finds 50% of the problems. Compare this to, for example, formal inspections, which find 60% of defects on average, 70% at best. Modeling and prototyping (build one to throw away) can find up to 80% of defects.

    None of these methods will build a completely defect-free program, but by combining a number of them, you can get extremely close (99%).
  • The reason a semi-natural-language interpreter hasn't been done (AFAIK) is probably due to the difficulty and varied results of natural language parsing w/regards to language meaning (see article on wearable translator).

    It's a great idea, but natural language capabilities are to computer scientists what Pluto is to NASA -- you can see it there but it's still pretty much unattainable.
  • This is the problem with Mozilla: rather than a few very well isolated, simple, small modules, it is a big glop of code.

    <Warning>OOD ahead</Warning>

    IMHO, Mozilla should have had:
    A Renderer class, which would have HAD_A:
    1. Transfer object reponsible for getting data (via HTTP objects, FTP objects, etc.)
    2. Image object responsible for rendering images (via GIF objects, PNG objects, JPG objects, AVI objects, FLASH objects, etc.)
    3. Script object responsible for executing scripting languages....

    You get the idea. Each top-level type of object (Renderer, Transfer, Image) would look for other objects to implement the different modes (by scanning a directory for DLLs/.so's/whatever). Thus, if I want to add Gopher to Mozilla, I need only make a very simple object that does the Gopher protocol, and drop it into the appropriate directory.

    This way, you can split the project into a very large number of very small modules. I can write my Gopher object without worrying about what's going on in the Flash object. I can test my Gopher object with a very simple wrapper that does no rendering, and thus is very amenable to automated testing from day 0. You can get a working HTTP browser before the FTP system is ready. You can get three people working on GIF renders, and pick the one that is best. You can start getting user feedback sooner. THAT'S where the power of the distributed development movement comes in.

    (NOTE: just because I would use an OOD approach, does not mean you MUST use C++: I've done OOD in assembler.)

    The biggest rule I've learned in my decades of programming is "Break the problem down into smaller problems. Repeat until the pieces are small enough to be solved in a few pages of code. Write the code. Test the code. Repeat until done."
  • The main reason software sucks is that software companies aren't meant to put out good software, they're meant to make money.

    This whole "tech slump" is due to the demise of many good ideas (and many bad ones as well) that never came to fruition due to VC time constraints.

    The people that are funding the companies care about ONE thing : return on investment. They expect it within 6 months, and set the Milestone dates accordingly. Developers aren't pushed to write good, usable, stable software, they're pushed to nail milestones.

    Features get cut, QA doesn't get done, documentation is scarce, errors pop up, all because companies are pushing just to get something out there, not to finish a quality product.

    The article mentioned above is useless without business models that will implement it.

    My boss is constantly trying to "teach me responsibility," which means "you are responsible for being here 7 days a week, 12 hours a day."

    What he doesn't understand is that it is his responsibility to make sure that I don't have to be here that much. It's his responsibility to make sure that we have reasonable goals and reasonable deadlines.

    In most VC deals these days, developers are not present. The business people don't trust them, because they are "those people that are getting behind again." Developers are often unshaven and occasionally they display personality. These are not good things to VCs, they want nothing but money back ASAP. They don't want to mess around with vagaries, it's all about money.

    Realistic investment should be the main goal, not instant ROI.

  • they can be just as good, if not better than, a software engineer

    ... at writing software that sucks.

    they work cheaply

    ... writing cheap software that sucks.

    IMO, formal training often reduces the ability to think creatively

    ... sounds to me an awful lot like "I have no formal training".

    once you are taught "the right way", it's hard to break new ground.

    ... so the next time I'm sick/injured I should skip the doctor with the MD (formal training) and "break new ground" with the "creative" guy?

  • Out of the two best programmers that I know personally, one has a doctrait, the other dropped out of a fine institution.

    ...and out of the two best programmers that I know, one is my brother, therefore, 50% of the programmers are my brother ;-)

    Sorry, but with a sample that large (2), don't try to draw conclusions...
  • The Rochester Institute of Technology (RIT [rit.edu]) has a Software Engineering program [rit.edu] that will graduate its first class this May. It is a spin-off of the CS department. (See also here [rit.edu])
  • I agree on generics.

    I disagree on peformance unless you are talking specificly memory footprint. In terms of memory footprint C++ still has a real advantage today.

    In terms of actual number crunching though Java and C++ are roughly on a par today. In some things, such as arraya cces, C++ stil comes out in front, in other things, like inlining of recursion and monomorphic virtual methods or allocation/deallocation of short-lived objects, Java beats C++ handily.

  • Re:leaky roofs -- cheating contractors (Score:3)

    by catseye_95051 ( 102231 ) on Tuesday January 23, 2001 @03:14PM (#487136)
    I spent HS and college in Wright's backyard, Madison WI. My folsk still live there.

    They sent me an interesting article a few years back. It seems some archietcture professors ahve been doing some digging into Wright's more ntoeable failures. ity turns out his design in every case was correct-- it was contractors cheating on the quality of the materails that caused the problems.

    (It was fairly common at the time for less then honest concrete contractors for inatance to water down their concrete mix feeling this was "good enough". Over the entier course of s tructure they could shave a fair bit of additional revenue.)

    As to your "what Wright would say", I noticed no quotation marks. Is this conversation in your minds eye or do you have a direct Wright quote and attribution for it?

  • Most programs need to be carefully prototyped. VB is often critized for the over-simplification that it enforces, but it's a valuable tool for rapidly developing classes for testing and evaluation of the design.
    Considering robust design takes more time initially, but once a solid model is decided on the implentation is relatively easy. I recommend the book "Design Patterns: Elements of Reusable Object-Oriented Software" as a great place for young developers to learn how to think about complex programs.

  • We're still trying to figure out the best way to build software, unlike most of the mature engineering fields that have had anywhere from 100 to 1000 years of practice.

    To some extent I agree with this. However, what I've seen so far is that the biggest obstacle to software quality is management's unwillingness to allow the engineers to take the time to do things right. Interestingly enough, I hear pretty much exactly the same complaint from friends of mine who are in other engineering discipline.

    I should also note that you're making a rather different claim than TechnoWeenie did: He claims that the basic foundations of software engineering (i.e. computer science) are much less stable than those of civil engineering (i.e. physics). You, on the other hand, are claiming that the processes we build on top of those foundations are not yet stable.

    I agree that a formal education isn't absolutely necessary to be a good engineer. But it certainly doesn't hurt. It's particularly valuable when you're dealing with other engineers (assuming that they're similarly educated), because you'll find that you simply have a much better developed "common language" for communicating with them.

  • Overall, an interesting read. I have a few comments to make though...

    Tests cover everything that could possibly break

    Absolutely impossible in todays world, unless you're writing a "hello world" application in an ancient operating system (DOS) with no multithreading or distributed components.

    When a bug appears, the programmer writes tests to demonstrate it.

    Good,

    After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features.

    Not good. Although the statement made is simple and seemingly true, it holds less and less value as developer count and software complexity increase. It would take an expert in the software to *Truly* understand what impact a code change *might* have on the rest of the product. A developer in todays world rarely has a *full* knowledge of the product he/she is working on and cannot form a valid judgement as to the overall impact, (although for the most part they usually are very intelligent...).

    Make it easy for users to report failures.

    I agree.

    After writing a test, write the simplest possible code that could pass it .......... .........Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future.

    I totally 100% disagree with this statement. It is ALWAYS more costly to implement change or new functionality later in the software life cycle. Possibly, at best, it may help reduce time in the long run but it definitely will not take the same amount of time.

  • I'm pretty sure that Capers Jones has never measured the defect rate of Unit Testing done XP style, with test-first automated testing of every class (and almost every method) in a continuously integrated project. No conclusions can be drawn about the effectiveness of XP Unit Testing based on the measurements of traditional ad-hoc Unit Tests followed by Big Bang integration. What XP advocates is much closer to what you are calling "Modelling and prototyping" than what you are calling "unit testing."
  • "Use cases" is compatible with normal English, while "stories" is jargon? Somebody's been spending way too much time in meetings, methinks...
    1. Fire the lickspittle program managers / marketroids who promise the world to the customer without having a clue on what is realistic. Listen to the engineers when they say "we're pushing too hard". Consider the end game -- we can get to a solid final release via lots of buggy "final" releases and chaos or by lots of interim releases which are not advertised as final, and which are easier to kick out the door than "final" releases.
    2. Send the entire team to an in-depth design patterns seminar. Even if you are not using OOD or DP, it will get people thinking about design, design artifacts (diagrams), and collaboration.
  • and no mention of strong typing, Ada, or the like.

    Not even an "Ada was a babe" thread.

    Clearly, strong typing isn't everything. But neither is any other single component of software development. You need an arsenal of tools to do the job right, beginning with your brain, and you need to know how to use them.

    But a weakly typed language takes a whole slew of potential errors and makes finding them a matter of human diligence, debugging, and auxiliary tools like lint.

  • As long as non-coders are involved in coding... (Score:4)

    by Crackos ( 137764 ) on Tuesday January 23, 2001 @11:06AM (#487172) Homepage
    ...software will continue to suck.

    Most people in software development these days are clueless. Having a university degree, college diploma and/or MCSE does not make one any better at coding, from what I've seen. Programming is something that requires both inate talent and experience.

    Second, making development environments supposedly more accessible and "fun", while stripping away useful language constructs because they are "too complicated for the average programmer", only makes for sub-par software. Try making a 30-screen database app in Visual Basic. Actually no; don't ever try that. Just beleive me when I say that it's damn near impossible to produce a good product that way!

    Finally, most new programmers are thrown into difficult tasks without much background knowledge at all, and very little if any mentorship. Still they're expected to produce exemplary results. Sure it's fun to be "challenged", but that's not the way to have a good end result.

    What's important is allowing people to gradually gain experience in programming, to guide them along the way, to show them how to improve their skills, and to give them the proper tools to get the job done. This is how it's done in every industry, except for that of software.

  • First Names... (Score:4)

    by Electric Angst ( 138229 ) on Tuesday January 23, 2001 @10:57AM (#487174)

    Okay, I just noticed this sentance...

    Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.

    Why is it that geeks feel the urge to call celebrity geeks by their first name only? You sound like thirteen year old girls reading Tiger Beat magazine!


    --

  • There is a difference (Score:3)

    by Srin Tuar ( 147269 ) <zeroday26@yahoo.com> on Tuesday January 23, 2001 @02:41PM (#487184)
    The difference is that building a bridge or an engine takes huge amounts of capital, and very few if any of the people who study the "physical world" engineering will get a chance to design and build a bridge, or to fab thier own microchip before being weeded through an educational system.

    On the other hand, software engineers with a home computer have all the tools they need to go full life cycle. They can get hands on experience doing everything a professional engineer would do. They can learn from their mistakes, and explore techniques and possibilites.

    All the knowledge they need is avaiable online. You can buy books for any level of software enginnering learning cheaply, if you prefer dead-tree medium. There are huge online and IRL communities to give you free help as well.

    College is porbably irrelevant so far as becoming a good software architect goes. Noone can make you learn; Its something you have to take for yourself.

    I know this first hand- Ive been coding my entire life. When I looked at the curriculae at a few colleges offering degrees in CS, I had to laugh. They teach almost nothing.

    So I went straight into the industry- got a job. Ive met PhD's I wouldnt wipe my shoes on. It seems like programming skill is inversely proportional to academic accreditation.

  • I would LOVE to live in a house designed by Frank Lloyd Wright. No architectural degree - he studied civil engineering briefly.

    A couple of famous people in the industry you may have heard about: Bill Gates, Larry Ellison, John Carmack - no degrees. Are you going to tell me you are a better programmer than John Carmack? Do you really think you have a better handle on software engineering than Microsoft's Chief Software Architect(funny, but yes, thats his title).

    Something like 100,000 software jobs open up every year, while our universities only graduate about 30,000 people with CS degrees. So why not have industry-standard apprenticeship programs. What about bright people who change careers mid-life(I fall into this category). I plan on eventually getting my degree, but were talking 4-5 years of taking 1 or 2 classes a semester. I have to work, and engineering schools generally are not geared to handle working adults. Big problem, but the unis are not addressing it.

    You may be making life easier for yourself by using the degree to separate the wheat from the chaff. But don't delude yourself - you will miss out on hiring some good people by your own limiting criteria.

  • A tip.. (Score:3)

    by PopeAlien ( 164869 ) on Tuesday January 23, 2001 @11:01AM (#487195) Homepage Journal
    everytime someone has a *great new idea* for a feature (Animated dog with sunglasses to help people with the process of pasting 3gig mpg's into their word document) look at them blankly and say ..'what?'..

    Here in Canada, it is your right to have things told to you in French.. This is usefull if you don't understand french. Repeat until they give up.

  • The right tool for the job (Score:3)

    by Deanasc ( 201050 ) on Tuesday January 23, 2001 @12:03PM (#487228) Homepage Journal
    I'd rather have my software programmed by someone who's actually faced my problem in the real world. You can have your CS degree (or Software Engineering degree) but if you're going to write programs that calculate the electron cloud around a complex ion you need to know chemistry, physics and calculus. Trouble is few people know how to do this sort of thing well and write code. Most of the programs I've seen were written by non-CS majors who needed the program badly enough to write it themselves. They're quick and dirty with only one way to do things in the interface but they work and usually don't crash taking out the OS with them.

    The real issue here is bells and whistles that are not central to the programs function. It's nice that Word can mailmerge an address list from an Outlook or Excel file but since I'm not in the mass mailing business I really don't need the feature. It's there and there's nothing I can do to get rid of it. It should be a plug-in for those who need it. (Professors where I go demand all reports emailed as a Word attachment so not using Word is not an option yet.)

    Any one can make shelter. It's a primal instinct that man has. Some thick branches, leaves and mud and you have a house. All you really need an Architect for is to make bigger fancier more expensive houses with features that don't always work properly. Like fire alarms that go off when you use the oven. Like hidden water pipes that sweat condensation which drips into a hidden electric box shorting out the current and burning down the house.

    Now a good Architect knows how to avoid these kind of problems but sometimes a builder just buys house plans and lets the plumbing contractor rough in the plumbing and the electrical contractor rough in the wires and hopes they don't burn anything down when the software is shipped. (oops I mixed my metaphor.)

    So really what I'm saying is too many cooks and not enough guidance from the top is what spoils software. Marketing can't give a manager a list of contradicting or confusing features and expect a committee to crunch out the code in time for the ship date. That is how houses burn down. But it wasn't our fault the fault lies with the pipe vendor who didn't make the pipes out of anti-sweat copper. However if you go to our website we have a patch for your security system so that the fire alarm doesn't go off when you turn on the stove.

  • What about existing software? (Score:3)

    by JWhitlock ( 201845 ) <John-Whitlock&ieee,org> on Tuesday January 23, 2001 @11:06AM (#487231)
    This plan of action (make test function, make code, verify code, repeat) seems to work well for brand new software. It answers the question, "Where do I start", with a great answer: start with something you can test. Sounds very much like the scientific method, and seems to work in the real world.

    But, what do you do when you have an existing piece of software? Most software is maintained, not created. If a system is already using unit testing, then you can be assured that your changes and additions do not break preexisting code. But if there is no unit testing, then there needs to be an extreme effort to integrate it into the code. This isn't productive - you are adding no new features, and, until you have completed the test suite, you aren't sure that your test code isn't breaking something!

    You can argue about future productivity gains, but sometimes those that give the money don't care about future gains. In my business, we make local changes to large systems (modifications to aircraft simulators). The existing self-test functions are inadequate, but we aren't being paid to make the whole system better, just to add our part. There isn't even assurance that we will do future work, so it is possible that our testing features will assist a competitor!

    Interesting idea, I'll use it on my pet projects, but I'll need to see a proven path for existing systems before I go to my boss and ask for a procedure change.

  • Re:Software Engineering will make software suck le (Score:3)

    by Riplakish ( 213391 ) on Tuesday January 23, 2001 @11:20AM (#487237)
    Please do not confuse the acquisition of a piece of paper from a certified educator with compentency.

    The percentage of less than compentent people without college degrees is probably the same as ones who have them. I personally know of a small village of people who attended college and basically skated to graduation with a decent GPA just by glomming all the answers from friends, boy/girl friends, family, etc. I also know of an equal amount of people that learned their craft by OJT, research, and dedication to knowing everything necessary in order to the the job right.

    There are many reasons why someone can be skilled at a job, in this case Software Engineering, and not need a sheepskin in order to do the job right.

  • history and suggestions (Score:5)

    by q000921 ( 235076 ) on Tuesday January 23, 2001 @03:28PM (#487254)
    About 20 years ago, there used to be programming environments that supported XP, runtime safety, incremental development and testing, and rapid development. They were things like the Lisp machine and the Smalltalk-80 environment.

    Don't get me wrong: those systems had their own share of problems, not the least of which was that they required expensive hardware to run well. They also lacked some of the niceties and safety check of modern programming languages (by which I mean languages like ML, not C++).

    So, what can you do? Don't blindly use C/C++ for everything. Those languages have their place, but they require you to spend a lot of time on stuff that isn't related to getting the job done. Learn something new, and learn about the history of all this. Here are some suggestions:

    • Learn about functional programming with Haskell [haskell.org] and OCAML [inria.fr], and SML/NJ [bell-labs.com]
    • Learn about logic programming with one of the Prolog implementations.
    • Read up on CommonLisp, Flavors, CLOS, and the Lisp Machine Window System. You can get CommonLisp implemenations at cons.org [cons.org]
    • Read up on Scheme and get a Scheme programming environment. PLT Scheme [plt-scheme.org] looks pretty good.
    • Read up on Smalltalk-80 and its programming environment (you can get a so-so Smalltalk-80 implementation at Squeak [squeak.org]).

    While those systems may or may not help you in your day-to-day work, they teach a lot about what programming can be.

    For your day-to-day work, consider using languages and environments like Python, Perl, and Java. They aren't quite as convenient as the more academic systems I mention above, but they still let you focus much more on the problem rather than the mechanics of programming.

  • Most of us don't have this option... (Score:4)

    by Bonker ( 243350 ) on Tuesday January 23, 2001 @11:05AM (#487257)
    For those of us who code, develop, (or even make graphics) in the workplace, we often do not have the luxury of making our work not suck. The reasons are threefold:

    1.) Time. This is caused almost totally by sales and marketing pressure on developlers. As release cycles shorten and deadlines loom, the questions developers ask of themselves stop being 'is it good?' and 'is it usable' and change to 'will it compile with no errors?'

    2.) Management. This speaks for itself. When your boss demands that you create a crappy product and you do what you're asked, you have made a crappy product. This is a pretty painful burden to bear in the webdesign world. I once had to design a site for a gas grill company according to the owner's rather dubious tastes. It's pretty horrid: http://www.tiernanoutdoorproducts.com/ [tiernanout...oducts.com]

    3.)Imitation. This almost belongs in the paragraph above, but when products become successful, there is a drive to imitate them. Take Winamp for example. What audio programs do *not* offer skinning now? Unfortuneately, this can be taken the wrong way. Look at the whole WIMP movment in GUI's. While it's nice to have a graphical interface, *everyone* spends time on the graphics and leaves out really useful features like a semi-natural language interperater. How nice would it be to type "Copy all jpgs with 'sitename' in the filename to 'sitename' directory" rather than a more arcane command or without having to worry about command typos? For the beginner, this would almost completely eliminate the learning curve to using a PC. Nobody spends time on this because there all still busy imitating MacOS.

  • Issue (Score:4)

    by geomcbay ( 263540 ) on Tuesday January 23, 2001 @11:16AM (#487271)
    One issue that this article doesn't bring up, and that many software engineering books ignore, is that sometimes all of the processes in the world won't help your software be more stable because of reliance on other software.

    What I mean by this is, outside of embedded programming of small devices and game console programming, nobody writes programs 100% from scratch anymore (and even in embedded systems and consoles this is changing as they add standard OSes and libraries and JVMs to support the programmer).

    So, not only do you have to worry about YOUR code not sucking, but you have to rely on all the DLLs or .so shared libraries you use not sucking, the underlying OS not sucking (sure, Microsoft has been the biggest name guilty of this in the past, but every OS has its share of kernel bugs, including Linux and *BSD), the JVM not sucking (heh heh, good luck on that one) if using Java, the C++ compiler you use not sucking and adhering to the standard, etc.

    This problem actually seems to only be getting worse as the world moves increasingly towards net-based software. Anyone who has written Java for the client (either applet or full blown application) can tell you that write once, run anywhere is a joke because each different JVM has its own set of annoying and incompatible bugs..Likewise even simple scripting tends to be incompatible between different versions of the same browser (Netscape and IE both guilty) let alone different vendor's browsers.

    Unfortunately there's so much suckage that is ingrained into current systems (and no, its not confined to Microsoft platforms, don't kid yourself) that some amount of suckiness is unavoidable no matter how careful you are.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close