Slashdot Mirror
Making Software Suck Less
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.)
-- Linus Torvalds
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.
-- Michael Abrash
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?
> 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/
Did he choose the colors or did you? Specifically, I mean the "View our on-line privacy statement" link, with the foreground in the neighborhood of 0xA80000 on a background somewhere around 0xAD0000.
Just curious...
(User volpe, posting AC since he already moderated in this thread.)
What everyone is complaining about is an inherent and integral quality of software. Software is an arbitrary sequence of commands for a generic piece of hardware. It cannot work with zero chance of failure. The user interface will always fail to please certain users. If you disagree, offer an example to prove me wrong.
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.
----
----
Open mind, insert foot.
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?"
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?"
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?"
My condolences on the death of your website. But seriously, I always wished time and management would allow one to design two web sites. 1) this is the one you told me to do 2) this is the one I think you should have. Now go compare them and see what YOU think. Of course, if the customer has crappy taste....what a waste of time. Often when I've had the opportunity to do something like this...ppl do swing around.
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
Send mail here if you want to reach me.
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
Send mail here if you want to reach me.
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
Send mail here if you want to reach me.
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
Send mail here if you want to reach me.
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.
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.
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.
That quote should be attributed to Donald Knuth, not Abrash.
*CRY*
--
We may not imagine how our lives could be more frustrating and complex—but Congress can. – Cullen Hightower
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.
--
We may not imagine how our lives could be more frustrating and complex—but Congress can. – Cullen Hightower
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.
--
We may not imagine how our lives could be more frustrating and complex—but Congress can. – Cullen Hightower
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.
--
you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
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.
Send your friends messages of love at fuck-you.org
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
Michael Bergbauer (michael.bergbauer@gmx.net)
A random stranger? No. Someone whose past work I've seen and liked; quite possibly. I am planning to live in a house designed by someone without a degree in architecture (and quite likely no degree at all). Does that count? The house is about 350 years old.
I don't know how long architecture degrees have existed, but the Architecture department at Cambridge was only established in 1912, so the designer of the house I live in at the moment (at least the Georgian and Victorian bits of it) probably didn't have an architecture degree either.
Incidentally, the Cambridge Architecture department has a fairly cool paper on using Quake for architectural design.
--
rant
We used this method when I was contracting at Deja.com, and several times we delivered much sooner than expected, and the expectations were typical.
One problem is that XP calls for pair programming, and a lot of teams are really too small to always have a pair. In those cases, you deal; write a small chunk of code, test and commit quickly, and try to have a partner on the next cycle.
XP isn't rigid; you have to tweak it to your needs. If you find yourself objecting to it on the basis of areas where it doesn't fit, try the bits that do fit and see what it buys you.
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.)
-- Ed Avis ed@membled.com
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.
Potato chips are a by-yourself food.
...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.
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.
Potato chips are a by-yourself food.
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.
-- Jeff Paulsen
You don't use continue or break statements anywhere? Just because they don't have an explicit label doesn't mean they're not GOTOs...
Just junk food for thought...
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.
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
One of the reasons software engineering is hard is because you can not easily draw analogies. People have been building houses and bridges for thousands of years; people have been building websites for less than a decade.
The methods that work well for software projects - like XP, the spiral development cycle, patterns, OO - are young, and constantly evolving at a rapid pace. My PC from 4 years ago is a doorstop; the house I live in is 130 years old. Our local MacDonalds is full of Cobol programmers (many with CS degress) serving fries.
One of the main reasons my work can be difficult is that there is no easy way to explain to non-software folk why certain things are hard and other things are easy - to them, it all just looks like misspelled typing. The comparison between "software engineering" and "civil engineering" is partly valid, but in many ways a sofware developer is more akin to the guy laying the bricks than to Frank Lloyd Wright.
N
It's all very well in practice, but it will never work in theory.
The advances are somewhat slower than those in computing.
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?
Some stuff changes, some doesn't. The stuff the potential employers always ask for is the stuff that changes more quickly. Perhaps the employer mindset is part of the problem.
What about someone who's highly trained in one field ? That person could well be a genius. I am finishing a PhD in math, and a lot of the stuff I have covered is similar to what is taught in high level CS courses. I've been able to teach myself the rest by reading books and writing code. I've worked on projects with CS grad students and they are not substantially better programmers than I am, though it's certainly true that I've had to play catch-up by doing a lot of work on my own.
As for your standing offer, if the architect had a respectable degree (for example, mechanical engineering from a good school), I may consider him, even if he didn't have a degree in architecture. In the absence of a degree in architecture, I would look for experience and reputation, and I believe employers in the computing industry also tend to do the same.
By the way, there's a long standing challenge for any of the other "better trained" students at my school to come and work at the same part time job I'm holding. My boss is still searching ...
You're right, there are two completely different issues here. My main objection was the original posters claim that the problem was a lack of specific training (if he didn't mean to claim that, he's welcome to jump in and correct me). I'm not a great fan of specific training, I've seen too many people do well outside their "field of training" to be convinced that we need more of it
That's a fallacy. The best "proof of skill" we have is experience. Short of experience, a related degree is the next best thing, the more closely related the better. Someone without specific training will obviously need to acquire the specific training from elsewhere.
However, it's not necessarily true that more specific training helps that much. I've observed people migrate between math/physics/computer science without that much difficulty. As I've stated in other threads, I'm a PhD student in math, and I've had little trouble keeping up with and overtaking those with CS degrees. Learning how to think is more important than learning what to think (the latter is easy to do on your own, the former is not)
Companies can and do filter -- but they don't do so by ignoring anyone without a CS degree. I can see why CS graduates might wish for this, and might feel that they're entitled to all the best development jobs. Believe me, they're not. A lot of CS students nowadays are the college-algebra type. Anyone who's not up to taking calc in freshman year IMO is just in the wrong intellectual ballpark for anything substantially more advanced than webmonkey work.
Despite your great ideas about how people should hire, companies are smart enough to choose (for example) smart science majors over dumb CS/IS majors. I recently got a letter from a company that were looking specifically for math and physics PhDs to program for them... Why ? Because they're smarter than the get rich quick wannabees that are starting to crowd out CS class rooms.
Anyone can learn how to use PHP or ASP, but understanding finite state automata, Turing machines, Markov chains, writing proofs, etc is a little more difficult. IMO, only very bright people can manage this. It's certainly true that you may find the occasional "goodwill hunting" (did you see that film?) archetype, but they're the exception and not the rule.
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, Mozilla, and even Apache 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.
--
how to invest, a novice's guide
System tests yes; unit tests should be written by the programmers writing the code, as they write it.
~Cederic
In all honesty, and speaking as an owner of "Extreme Programming Explained" (Beck), "Extreme Programming Installed" (Jeffries et al) and "Planning Extreme Programming" (Beck, Fowler), I think that the Refactoring book is more useful than all three. And I'm currently using (ok, trying hard to use) XP on my current project.
~Cederic
Ok, my comments on testing here were about testing, not necessarily about XP.
I write business software. We write a system, deploy it, and end up supporting it for a few months/years.
The initial time to develop does get hit by having to write tests first. But not dramatically - once you are over the initial learning curve, you get into the habit of writing simple tests, and you can do so very swiftly.
On that first project, you'll get some benefit from your tests - you are inevitably going to have to go back and make changes to code you've written a couple of weeks, or months ago. And the tests on that code will instantly tell you whether your changes have introduced a bug or not.
But after you ship your first release, and start supporting the code base, you are into a major win territory. Someone finds a bug; you write a test that exposes the bug, then change the code so that your test passes. And you know, you can feel it in your bones, that you haven't introduced any new bugs, because none of your other tests have failed. (If they have, then you go and make the changes to the code - or to the tests - needed to make them pass.)
I've said it already somewhere else under this article, but if your boss wont let you do stuff like that which has such obvious benefits to your medium to long term productivity, it's time to find a new boss anyway.
Having said all that, if you're writing one-off reports for your boss to run, then you wont get longer term benefits from tests. What I'm going to question is, how one-off are those reports - 90% of software gets used beyond its initial anticipated function, and for a far longer lifespan than intended. And if it's being used, you will be expected to support it.
btw, I just made that statistic up. sorry.
~Cederic
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
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
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.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
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.
/ \
\ / ASCII ribbon campaign for peace
x
/ \
not to mention "brilliant non-orthogonal" is oxymoronic.
thi (who was fired from last job, you can guess why)
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.
Need a Python, C++, Unix, Linux develop
I once had to design a site for a gas grill company according to the owner's rather dubious tastes. It's pretty horrid
Hey, didn't your client pay you enough to type in the !DOCTYPE ??
:-p
But really, I feel sorry for you... visually it sends me screaming for cover.
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?).
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?
The title and the summary didn't mention this was going to be an XP feature or I would have skipped it. What's the point of a summary if it doesn't accurately summarize the article?
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.
now we need to go OSS in diesel cars
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
Remember Amalek.
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
Remember Amalek.
http://www.apa.org/journals/psp/psp7761121.html
-jon
Remember Amalek.
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
Remember Amalek.
-jon
Remember Amalek.
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
Remember Amalek.
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
Remember Amalek.
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
Remember Amalek.
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
Remember Amalek.
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
Remember Amalek.
They already have it figured out.
BareBones software "Software that doesn't Suck"
http://www.barebones.com
heheh
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!
cpeterso
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.
cpeterso
> 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.
--
Sheesh, evil *and* a jerk. -- Jade
> 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.
--
Sheesh, evil *and* a jerk. -- Jade
My Theory of Responsible Software Design:
If you're having fun doing it, you're probably doing it the wrong way.
- It requires all team members to be better than the average programmer working today. In other words, they have to have enough experience and expertise to know what tests to code for.
- XP acolytes insist that you have to do all of XP or you aren't doing XP. It's amazing how these little words can weasel it out of all failures. In essence response to examples where XP fails are met with "well, that project wasn't really doing ", therefore XP can't have failed because they weren't doing XP.
Skip the XP silver bullet and become a true software professional. Understand the requirements. Call BS on stupid requirements. Know how long it will take to do something when you are asked to estimate, and explain the risks that might cause the schedule to slip. Then keep that schedule -- which means knowing how to estimate right. At any time during the development cycle, be able to say if you are on schedule or not, what you've done and what's left to be done. When (not if!) requirements change after the schedule is set, explain accurately how those changes will affect the schedule. Write documents. Yes, including commenting your code, but especially explaining how the stuff all works together. Finally, learn to recognize when a project is doomed, and bail out.Yes. Frank Lloyd Wright was one of this century's most innovative and influential architects and he never had formal instruction.
My point is that a piece of paper says you can memorize facts and problem solving techniques long enough to pass a test or write a paper. No more, no less. A degree doesn't guarantee the apptitude of an applicant.
~~Galen~~
In X Window, especially under Linux, the state of user interface inconsistency is INSANE. Even basic services, such as the clipboard, don't have a consistent implementation from program to program. (Observe the different keystroke and mouse operations for cutting and pasting across Netscape, Emacs and OpenOffice, for example.)
If that wasn't enough, you have companies such as Helix-oops-Xymian falling head over heels to Clone Microsoft First - as if Outlook was the ideal UI.
Nothing being done in Free Software today is doing anything to solve this problem with toolkit warfare, desktop warfare, UI warfare and so-on. There is nothing coming even in the FAR future that will put an end to angrier and angrier fruit-salads manifesting themselves all over your screen, just because the developer is too arrogant to follow a simple UI convention.
Picking your favorite examples of "easiest-to-grok" user interfaces is misleading, because it makes you think there's a trend or a possibility that a UI Utopia is not far off. This will never be true, because a GUI desktop is percieved, by the user, as a single application with many modes. The Cool Edit mode may be well made, but the Mozilla mode is an unmitigated disaster. The latter poisons the value that could have been established by the former.
This means you only need one badly designed UI to spoil your whole desktop. Chances are there'll be more than one, chances are one of them will be an important tool.
Regards,
Chris Wenham
Regards,
Chris Wenham
Disenchanted.com
I have to agree with whoever said they would also have failed in real life. In real life, you would've been asked to implement the linked list
without even knowing what the hell the specifications of it were. Do you think at any software development firm, they tell you how to code the
thing?
THIS IS HIGH SCHOOL! The whole POINT is to teach you HOW...
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....
---
Play Six Pack Man. I
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?"
ours is no to reason why ...
ours is to code and cry
Wit hsoftware its the design phase not the coding that is the most important. Any monkey can code but finding someone who can design a good piece of software is hard.
Often times time constraits force people to take shorcuts they shouldn't to release buggy or incomplete software. Thats the real problem , no one is taking the time to do it right the first time. They think, oh i'll just post some patches on our website, or i'll get them on the upgrade with that fix. Lack of ethics and lack of professionalism and lack of time all contribute.
The other big issue is communication, many times the clients needs are not fully understood or the project manager doesn't know what questions to ask or assumes information is known.
When these things are solved perfect software may be a possibility.
this space for rent
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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 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.
Slashdot - News for Herds. Stuff that Splatters.
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.
--
"It's tough to be bilingual when you get hit in the head."
How is exhaustive unit testing supposed to work? In any project that I've been involved in (all small, less than 100 KLOC), exhaustive testing would take anywhere between millions and trillions of test cases. It's the unexpected/untested corner conditions that nail software and the ability to find every possible variable that could effect software operation is next to impossible in a sane amount of time.
In a typical unit, there may be 25 variables all with perhaps 10 useful values that should be tested. (For example, for ints, I use a large negative value, a small negative value, -1, 0, +1, a small positive value, a large positive value, minint and maxint (amazing the number of programs that manipulate parameters without checking for integer over/underflow), one below the largest expected value, the largest expected value and one above the largest expected value) That makes 10^25 test cases!
Isolating programs into small enough independent units to make testing possible is usually a pipedream, especially in anything to do with GUIs, where there are usually 5 different ways to do anything, guaranteeing that every element of the GUI is connected to every other element.
Dealing with error conditions alone is a nightmare. Faced with GUI code that can generate a possible error condition every 5-10 lines of code, most programmers just give up and punt.
For a lark, I once did *proper* error handling in a few hundred line program. I gave up at over 3,000 lines of code (of which about 1/3 was dealing with error conditions that occurred when error conditions occurred...)
Just my observations from the trenches...
Non-orthogonal is fine, as long as it is complete. Unless you were just being a troll?
Become a FSF associate member before the low #s are used
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?
Heard of DWIM? I don't want my computer to infer what I want from it's half-assed understanding of English...
Very interesting comment. You said you were adding CALEA to a cell phone network. Unless I am mistaken, this is a federal-mandated packet-level tapping that allows law enforcement authority to copy all packets going through a certain telecom operator and have them forwarded to the comfort and safety of their offices, without even having to go put a tape in a recorder. Is that right?
Now, can you please tell us how widely CALEA is deployed? Also, is the access to the tapping function well secured? Or can any cop click on a mouse and listen to anyone?
while(feds == involved)
{
paranoia++;
}
--SysKoll
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
Unless you think that ./ers don't care about telecom tapping laws?
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
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)
It's 10 PM. Do you know if you're un-American?
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.
How we know is more important than what we know.
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?
How we know is more important than what we know.
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.
How we know is more important than what we know.
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 :)
How we know is more important than what we know.
I know guys that have written very good database oriented systems in VB. They're M$FT geeks but they can produce a product.
How we know is more important than what we know.
no, as in they cant code for anything except microsoft products.
How we know is more important than what we know.
oh and M$ft geeks learn to use Microsoft products by paying for books.
How we know is more important than what we know.
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).
How we know is more important than what we know.
Amazing these days almost anyone is an "engineer" no matter what they do. Engineer to me means someone who follows the scientific method to solving problems and later proving that method again. The later is called "regression testing".
Funny word eh? It's seems to be a funny word to the OS community. I can count all the projects I know that have decent regression testing on one hand. To the point... Reg testing is not fun. Devising test suites are not fun. Running through then X number is not fun. Recording variences in said tests is not fun. Anyone who's an Electrical Engineer knows exactly what I'm talking about. It's boring and repetative work. Change ONE thing you're rechecking everything all over again. For the demands making, running, and recording such tests is one of the big reasons why your casual hacker won't even attempt such a thing. It's usually the project leaders/core that HAS to implement this and if they dont do it no one else will. Thats part of the quality issue. Others include like the gentleman who posted the article said/quoted. Not planning features per a scheduale or pushing in features last min. etc etc.
It all really comes down to how organized the core is and if the structure they create can attract the right people.
Peter
--
www.alphalinux.org
www.alphalinux.org
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.
Processes are important, but it would not hurt at all if there was an OO language that was fast, powerful, elegant, didn't require a virtual machine, and had something of a C-ish flavor to it. Dream on...
In the case of your average software developer, both of these are happening. Good programming practice gets put on the back burner because they *need* to ship.
yep.
One of the great things about the last project I worked on was that our group manager told us that the schedule was HIS problem to work out. We were to tell him how long it would take to do something right, and he'd take care of making sure we had the time to do it.
You know what? Since we were never getting the schedule shoved into our faces, we did things well, and pretty much on time.
---
"You know your god is man-made when he hates all the same people you do."
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!
Umm... what kind of unit testing are YOU doing? All the unit testing we've done has been "self-contained" - as in we haven't needed to do anything to the code being tested to do so. All the work on testing is done in seperate test drivers, stubs, and makefiles.
For some reason, the idea of changing code that's being tested to do the testing sets off major warning bells to me.
If it's because you don't have any small pieces of code that are easy to access individually to test, then well, that's a sign that complexity is a serious problem.
---
"You know your god is man-made when he hates all the same people you do."
you aren't sure that your test code isn't breaking something!
Umm... this is a quote from the original message. If your test code is seperate, then it can't break something.
And you don't have to write tests for everything all at once. We just wrote tests for the functions we actually touched ourselves. There were plenty more that needed them, but because we didn't modify the code for our release, we didn't worry about the tests either.
Yes, it did take a lot of time. Yes, I spent a few weeks writing test driver after test driver after test driver until the tedium was getting to be a big problem. But the code was better because of it. And those tests are now there, and they won't have to be written again, just edited with new features. (Assuming that people don't ignore them for a few releases until they reach the point of being obsolete. But then again, I'm getting out of here soon for completely unrelated reasons, so I really don't care that much if they do that)
---
"You know your god is man-made when he hates all the same people you do."
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.
---
"You know your god is man-made when he hates all the same people you do."
I actually graduated from the University of Victoria (Victoria, BC, Canada) with a CS degree and an emphasis in Software Engineering. There has been a full blown Software Engineering degree available there for about 2 years now. The program teaches patterns, design methods, architecture, and all the other goodies one would expect.
www.csc.uvic.ca
Check it out if you wish. The program is actually quite good. It is getting crowded these days but I loved that school.
E/.
--
************************
************************
What, me worry?
In my experience repeatedly installing and uninstalling software makes a system suck. Each (un)install screws up the system configuration a little bit, adding, changeing, or deleting. Sort of like running text thru the fish multiple times. The end result is a system that doesn't work anymore.
OSs are not designed to accomodate the (un)installation of software. There are hacks, e.g. RPM, that make (un)installation easier, but the cruft in the system accumulates unchecked.
I'd like to see an OS designed from the ground up to make (un)installation as easy and reliable as possible. The goal would be that installing A, installing B, then uninstalling A would be indistinguishable from just installing B. If this were always true no matter how poorly the A and B (un)installers were written, software would suck less.
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.
I would argue that the state-of-the-art in software engineering has changed quite a bit since MMM (not Minnesota Mining and Manufacturing) but that it's still right because people haven't learned. Managers still do things like adding more people to a late software project. Customers still ask for everything they could possibly use, reducing the probability that they will get anything to use at all. It's still possible to get through a CS degree at even very presitigious institutions like Harvey Mudd without having read MMM!
All MMM does is prevent you from making some of the most common fatal mistakes, such as I've listed above. People still make them (I make them, when I'm not careful), and avoiding them helps your chances for successs a lot. However, as Steve McConnell points out in SW Project Survival Guide, merely avoiding the most common mistakes is not enough to ensure success, just that you won't fail because of that particular mistake.
It seems that the difficulty in teaching SW engineering comes from the reluctance of academics and SW companies alike to recognize proper development methods as being important. I took a semester of SW development at Harvey Mudd, and it was incredibly helpful. Now, at least I can shout out, "Wait! That's suicide!", but I have a lot more to learn about how to do things right.
Walt
>> Unfortunately there's so much suckage that is ingrained into current systems (and no, its not confined to Microsoft platforms)
>Part of the problem with the Windows API sucking so bad, is that once a bug is found in a kernel function - M$ can't go fixing it, lest they break all the old apps that code around for the bug!
Actually, they do break them from release to release. When writing enterprise software (not me, but an uncle of mine) one frequently has to work around different revisions' bugs. I remember him complaining about how there were four windows platforms, Windows 3.0, 3.1, 3.11, and WFWG!
Walt
Correct me if I am wrong, but isn't this exacly what the mozilla project's Tinderbox and smokering test do?
Accountability is important when code breaks. =)
-pos
The truth is more important than the facts.
The truth is more important than the facts.
-Frank Lloyd Wright
Wright's engineering was well ahead of anyone else's at the time. He was building what his contemporaries (and certainly his contractors) considered to be impossible. While the story of the extra steel supports is true, the builders also installed an entire stone wall under one of the balconies to support it. It was later removed when the Kaufmanns realized that Wright had soon after removed the top layer of stones and the wall had never actually been supporting anything for years. I have heard that the extra steel reinforcement added weight to the terrace and was responsible for the weakness. I guess there are several accounts of the situation going around.
:)
;)
The sagging on the main cantilevered terrace was mainly due to an error. The concrete was cast at true horizontal and not slightly upward as it should have been to compensate for gravity once the wooden supports were removed. One corner of it has drooped almost 6" since then! Wright was furious about that one too.
When I went to see it they had removed one of the main flagstones in the livingroom and replaced it with plexiglass so you could see the cracks in the support beams. They were also measuring the stress that the tour groups put on the balconies using little shock sensors.
The sad thing about any supports they will have to put up is that they will almost definitly run vertically and will partially spoil the visual effect of the house. The bookshelves that the Kaufmann's son added to his upstairs bedroom have vertical supports and add a subtle "not quite right" feeling to the room that is only really noticable when someone points it out to you but definitly tangable.
Anyways, thank you for the link and I will try to hold my idols somewhere a little closer to the earth. I promise.
-pos
The truth is more important than the facts.
The truth is more important than the facts.
-Frank Lloyd Wright
As somone who has quoted Wright in my sig for some time now (See the article dept.) I feel I should point something out.
:) 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)
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 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.
The truth is more important than the facts.
-Frank Lloyd Wright
...gotta get Myers' orange book. It will change the way you think about testing.
There are 11 types of people in the world: those who understand unary, and those who don't.
I think this quote summarizes the theme that is central to all of your posts on this thread: that those in the field without a degree have no training.
It should be obvious that if said people are in the field, they obviously have some sort of training, as programming is not a profession that you can easily bullshit your way through.
I find your differentiation between 'programmer' and 'software engineer'. Please explain.
Tim
There are 11 types of people in the world: those who understand unary, and those who don't.
I find your differentiation between 'programmer' and 'software engineer'. should have read:
I find your differentiation between 'programmer' and 'software engineer' suspicious.
oops.
There are 11 types of people in the world: those who understand unary, and those who don't.
"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.
just my blog and pix
The biggest problem that companies have is that they do not understand the difference between an Engineer and a programmer. Well guess what, there is one hellva big difference, and anybody that says other wise is a lying. I do not mean to insult people who do not have any formal training, but yes the formal training is important. Most software sucks is because you did not have anybody clearly understanding the problem and laying the direction with the correct technology.
I am sorry to say, but that is what I was taught in school. Sit back and evaluation the situation as a whole. Most programmers can't/won't think big about the solution as a whole; they just want to jump in and start writing code.
Just my $0.0000000002
> outside of embedded programming of small devices and game console programming, nobody writes programs 100% from scratch anymore
That might of been true of 5 years ago - games would be re-written from scratch each time, but certainly not true from 3 years ago. Us game programmers try to leverage as much code re-usability as we can. With the average game taking 1.5 to 2 years, and millions of dollars to produce, we can't afford to just "throw-away" all that development time!
> Unfortunately there's so much suckage that is ingrained into current systems (and no, its not confined to Microsoft platforms)
Part of the problem with the Windows API sucking so bad, is that once a bug is found in a kernel function - M$ can't go fixing it, lest they break all the old apps that code around for the bug! Linux takes the opposite approach and will break things, so they are better designed/coded in the long run. (i.e. think device drivers from 2.0 to 2.2 to 2.4) A better solution, IMHO, but it creates havoc until everyone fixes all the driver code.
Part of the other problem, is we're using a 10 to 30 year old languages (C/C++) to design large systems. With the power, and speed, we make it to easy to "shoot your leg off." How many memory leaks have we had to track down because of pointers getting trashed, etc. While I love C++, sometimes I wonder if the language would be better off with more safety-nets. (No not Java) But as soon as we choose flexibility and abstractness, we loose speed. Something that us game code / programmers are allways trying to find a nice balance between. "Scripted vs Native language, Intepreted vs ByteCode, etc"
The other big problem is a changing design spec. How would the carpenters like if your house was half built, and then you told them, "Uhm, can you put in a swiming pool?" What will they say: "Sure, but it's going to cost you time and money" -- something the boss/management/marketing does seem to understand.
Cheers
Degrees per se are not relevant to being really good at software. Knowing at least the basics of data structures, algorithms, algorithm complexity and OO or other relevant methodologies is important but formal degree programs are not the only or even the best way to learn these things. Those basics are given in a few courses. The rest of the CS degree program is often irrelevant to success at software engineering. I have known plenty of highly credentialed CS people who simply cannot design and code. And I have known people without any CS degrees who are some of the best software people around.
Whether we like it or not, software is still largely craft and art and/or we don't teach the right engineering techniques to actually succeed at it.
Software engineering is NOT architecture or building bridges. A large part of the problem comes from pretending it is the same kind of activity. Unlike these other domains, software requirements vary as a function of user experience and environment and technology changes over time. Attempting to build a software system as if you could really fully flesh out the design, code it once, really deeply test it and be done is a formula for utter disaster. What is needed is more seeing the process as something quite a bit more flexible. Some other whose name escapes me suggested a metaphor of software as a flower garden. You lay out the garden to please all the users of it that you have gathered requirements from. But you expect and design for going back and pruning here when things grow out of hand, shoring up and adding there, moving this piece from here to there for aesthetic reasons and so on.
This requires more than simply good factoring and component technologies. It requires tools for monitoring the health/aesthetics/conditions of living systems and for modifying them over time to increase the desirability of the system. Getting everything working just so under these scores of pages of system requirements and assumptions doesn't help when many of those assumptions are obsolete before the system even ships much less a few months down the road.
But this is also too strong a statement. Some software can be done more like architecture or bridge-building. But much of it cannot. Even more wisdom is needed to know the difference.
<Warning>OOD ahead</Warning>
IMHO, Mozilla should have had:
A Renderer class, which would have HAD_A:
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."
www.eFax.com are spammers
The Evergreen State College in Washington state has a program called Student Originated Software that attempts to address this problem. It is a Software Engineering class (well, its a full year program) that draws students from comp.sci., liberal arts, and natural science backgrounds and puts them in a fairly realistic SE atmosphere. They must solicite for projects, then design and implement them. The focus is on cooperation, organization and design, not Comp.Sci. fundamentals.
TESC
I suppose I'm not too threatening, presently, but wait till I start Nautilus
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.
THIS is what people are talking about --
The question was who would you hire today, the unknown with a degree or the unknown without?
I know that if I knew NOTHING else about a person other than one went to UC Berkeley or MIT for computer science, and the other wasn't college educated, I'd chose the college educated one. Now... if the question was would you choose a super-famous and talented programmer over one with a UCB/MIT degree, you'd obviously chose the talented guy. The thing is, that's a very, very small group of folks.
yeah.
willis.
there is no thing
what else could you want?
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?
Sometime back in the late '70's my computer science profs preached that "Requirements is the first phase of programming. You've got to know what it's going to do before you can program it."
When asked what is a requirement they answered "A requirement is defined by its test."
So in order to test first you have to have your requirements under control. Good advise weather you're programming an Athlon in C++ or a 1963 CDC cyber with hollerworth cards.
An error caught in the requirements phase is 10 times easier to fix than in the design phase. An error caught in design is 10 times easier to fix than in implementation.
-
All generalizations are false, including this one. Mark Twain
Our version of XP is to have 2 or more people sit around a screen looking for the bug/fault. *and* we are six-sigma compliant...
For once, Windows actually makes things easier ;)
Since Windows programs are controlled via messages, you can simply write a program that sends the same messages to the app that the user would generate if using the program manually. It's basically a glorified macro.
I haven't done any GUI work in X (I detest X more than I detest MS Windows), so I'm not familiar with how it handles GUI interaction.
Nathan
The obvious way to have software that doesn't suck is to use BBEdit .
I don't think "integrate it into the code" means changing the existing code to make the test suites. I think he means that if you have a large existing codebase (without test suites), it will take a huge amount of time/effort to write the test suites for it. This is a legitimate concern since you'll have to write test suites for your entire program before you can add any new code as the previous poster noted.
"The obvious is that which is least understood and most difficult to prove." -- A fortune cookie
I assumed he meant "your new code isn't breaking something!". I'm not saying that building the test suites isn't a good idea ( in fact I'm trying to get my current company to go in that direction ), it's just the time it will take that is the main concern since we have a very large codebase.
:)
That aside, just writing test suites for the functions you touched won't catch all the possible new broken code if the functions have any side-effects, so you've got to be very carful in what you don't write a test suite for initially. Baby steps are the most palatable way of doing it though
"The obvious is that which is least understood and most difficult to prove." -- A fortune cookie
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...
Opus: the Swiss army knife of audio codec
An intuitive, almost natural language CLI. Hmmm... sounds pretty nice. In fact, it sounds an awful lot like AppleScript (for less marketing speak, see here). At one time they even had translation between languages. While not a full CLI, it could probably be made into one. It certainly has almost natural language syntax.
-----
"People who bite the hand that feeds them usually lick the boot that kicks them"
Higher Logics: where programming meets science.
The Rochester Institute of Technology (RIT) has a Software Engineering program that will graduate its first class this May. It is a spin-off of the CS department. (See also here)
Using your sig line to advertise for friends is lame.
The issue is incentives. If you don't reward somebody for doing behavior X, then most will simply stop doing behavior X.
The problem is that good software is expensive and time-consuming to write, but everybody wants a $99.95 box with all the trendy features.
The public is simply getting what they pay/ask for.
Table-ized A.I.
In fact, the book was written by an unlicensed, untrained author. Hopefully in the future we'll have a licensing program to prevent such dangerous half-baked ideas from reaching the public.
EE is definitely not changing at the pace software is. Everything up to analysis of AC circuits is from the 1930's or earlier. This includes the whole conceptual framework of linear systems and signal analysis, which is much more important than the technology-linked areas of study.
Electronics is from the '70s, because transistors fundamentally changed it. But Electronics is not nearly as important as circuits and signals.
DSP is from the '70s. OK, there are later contributions that matter. But once you understand the math behind IIR and FIR filters, the rest is just fleshing-in.
As for digital circuits, I don't know when the building blocks of digital logic were developed - probably in the vacuum tube era. Has anything happened since the '70s that matters to a college student? Remember, TTL vs CMOS is a trivial difference to someone studying digital logic.
A better way to look at this is to ask what happened to the engineers educated just before inflection points. Those who learned vacuum tube electronics shortly before transistors became widespread, for example.
It could be done, though. If one tenth of the energy put into GUI development had been put into the development of a natural language shell, we'd have something pretty awesome.
I'm thinking of a very straightforward pattern matcher, much like an adventure game. The key is to evolve the pattern vocabulary whenever user input isn't recognized. How could we do this? Have the program send unrecognized commands to a server, where they'd be looked at by volunteers who would try to write new patterns and rules. Not in real time, of course - the pioneering user would unfortunately get an error message.
This approach has privacy implications, but if developed carefully over a few years it would probably handle anything Joe Sixpack would throw at it.
I still have a standing offer: will anyone have an architect without a degree design a house they would then live in?
I think I heard about this.....isn't it one of those new "reality" shows? I believe it's called "Who wants to be an architect?", and it's going to be on FOX after the Super Bowl.....
I'd comment more on this thread, but I haven't completed my degree in "Effective argumentational posting on Slashdot" (my thesis is on the 'first post' phenomenon and it's relationship to the price of tea in China). Therefore, I probably have nothing else to add that would be worth your time.
Cheers!
"fist in the air in the land of hypocrisy"
JAVA
No wild pointers. No memory over-flows. Stronger OOP design structures.
I fiddn I spend a much much smaller amount of time debugging Java programs, with more stable results, then I ever got in C or C++.
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.
The thoughts.... They came freely to me, and I give them freely away. - Wendell Berry
There will never be quote "perfect" software. As the title says, it can only suck less. Many features that some people love, other people hate, and some really important features can simply not coexist with other less important features. Someone will always be unhappy with a piece of software, which is why we have variety.
I am !amused.
I see where your going with this, but any serious code will be tested by people other that the people who developed it. This approach of testers trying to catch developers out and developers trying to avoid being caught out, does lead to a total quality ethos, and utimately better software.
How's this for semi-natural?
tell application "Finder" to copy (file whose (name contains "sitename") and (file type is "JPEG")) to folder sitename
Ok, I realise it still has a way to go before being usable to my mother, but AppleScript comes the closest to what you want that I've seen... =)
O.K., let's take something more recent - genetic engineering - You're the CEO of a new company who is going to engineer some bacteria to produce a hormone for you. Would you hire some-one who didn't have any experience and was cheaper (but who said they were top shit), or someone who had spent a few years of their lives in the stuffy confines of university learning a bunch of things you figured might be out of date already, things like cell structure, chemistry, biology and scientific method. Going to university isn't like reading "Learn VB in 21 Days" a few times over. You learn things that will never go out of date (like math). The application of those things may change but the core principles remain the same. It is possible for someone to learn the "generic" things that university teaches without going to university, but university is supposed to add a bit of certainty. Software engineering has been around for over 50 years. To think that you can learn nothing from the experiences of those 50 years is crazy.
Its going to get better!
Sound like a victory of optimism over experience.
I really have seen no marked improvement in generally available software over the last ten years.
There are a few exceptions: Internet Explorer is better than Netscape -- but then neihter is that much better than Mosiac.
My general experience of software is that the people who thought up the origonal idea generally write the best implementation. The imitators just add bells, whistles and bugs. So XEROX ViewPoint was better than windows. Lotus was better than Excel and DB2 was/is better than Oracle.
The marketplace however seems to reward the imitators rather than the inivators.
Old COBOL programmers never die. They just code in C.
If the head admin for Microsoft ran *NIX, would (s)he be considered the root of all evil?
The evidence is the college degree."
Apparently your coursework didn't cover a logic class (sorry, can't help but snipe :) ).
"It's a hoop to jump through; a painful, stupid hoop sometimes, but a hoop nonetheless"
It seems a sad state of affairs if this criteria is really the best you seem to think you can do.
"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"
To some degree, but not much. Let's remember a few things
- Many "top tier" universities have incredible retention rates. This is due in large part, certainly, to the fact that people there are good academians and score well on standardized tests. However in my personal experience, and those of friends who went to other "top tier schools", is that many "top tier" programs do everything they can to babysit and get people through. I'm not saying the coursework isn't challenging, but getting bad grades at most "top-tier" programs is very difficult. It's much like being in an "Honors" class or gifted program -- People assume you are smart, and tailor your grades accordingly.
- Real-word development is far different than the majority of any CS program's I've seen or heard of. Most CS programs focus on theory and math. We could argue endlessly over the value of this, but when trying to judge someones suitability for a certain techie job, this is apples to oranges in a big way. Rather than go on about this, I'll just say some of the very best folk I've worked with have (gasp) Liberal Arts degrees (in worthless Humanities kind of junk) and gleaned their computer knowledge without formal education.
- Almost any formal education that's worth half a grain of salt presents you with the basics and some help, but the vast majority of it is up to YOU to figure out with your fellow students. Any work environment for a new-guy worth half a grain of salt should be providing a similar (albeit more specialized) environment.
- There is nothing any formal education can teach you that you can't learn yourself or with the help of others (I'm not saying a formal education can't help the process but...)
-Work experience greatly outvalues any degree, certification, or what have you in a very short amount of time. I'm assuming when you say "just starting out" you mean people with zero work experience, in which case, alright. However this is about the only case where a degree should buy any power -- I.E. "Something versus nothing". The oft used example of "Two people who're exactly the same in experience, one with a degree and one without", never ever happens. The dilimeter there should be a rigorous interview process with competent interviewers. If you REALLY find hiring decisions coming down to who's got what level of degree from where, your practices need serious overhaul.
-I've found that most people who get excited about someone with XX degree or certification are those that like to boast about it themselves. Ego (not necessarily bad), and sometimes because they don't have much else to go on themselves.
-Similarly, most diehard espousers of formal education usually are people currently in college or recent graduates. Most people spending 4+ years in a program want to feel what they've done is worthwhile (whether it is or not - your perception is your reality) and that they have an edge. Unfortunately sometimes this feeling of "this was really worthwhile for me" turns into "this is the only thing worthwhile to start with". As the years grow on and your accumulated wealth of knowledge and understanding begins to dwarf that which you knew at 22ish in younger, you tend to get a different perspective.
Just to clarify - I'm not anti-college. My experience was, for the most part, a good one. However I find harping formal education about as annoying as harping about a particular religious faith as the only path to spirituality. Education != Formal schooling.
Now let's bring your analogy a little closer to reality: Would you rather have your house designed by someone with an architectural degree and has never built a house, or someone who has no degree but can show you 10 homes s/he's designed? When our fictional people both have 100 homes they can show you, do you care at all? If so, perhaps you should be spending a little more time considering the quality of their previous work rather than comparing rankings on the quality of archtectural degree programs. Regards
Every person is unique and you have to judge each person on a case by case basis. To not do so is stereotyping. This is common among snobby college kids, and big businesses. Not everyone who goes to college has greater skill. The real danger is the perpetuation of these lame generalizations.
I know many people who have worked hard on top of going to college, myself included (University of Memphis while working full time at McDonalds was not easy). By snobby college kids I wasn't trying to say that you have to be rich to go to school. I am referring to the elitist behavior that many grads take. Just because someone has a black belt in martial arts does not mean he can beat the stuffing out of anyone up that does not share that distinction or even gone through any formal combat training.
Also as far as bridge building goes, I personally don't know anybody who grew up spending thier whole lives building bridges but I know many who have dedicated the majority of thier existence to computers. My friends father is an incredible mechanic. He never went to a school to learn it, but he beats the pants off of anybody in town and the smart people take thier cars to him instead of to the butchers at the local garage. He makes quite a living out of his home. They repair place should have hired him but instead overlooked him because of his lack of formal training. Now addition to missing out on a good employee they are now losing many customers to him. They have even threatened legal action against him to try to scare him out of business. Computers are similar to auto repair in that they are both technical in nature and easily accessible for the average person to learn/gain experience in if they have the will to. Although college at least for me was valuable, there is nothing magical that it offers that can't be learned outside its walls and many people do just fine without it.
Scary part is we know what those last names are.
Plus, if your manager asks you what you are doing, and you answer, "Writing tests" then he's going to love you.
Not any of the managers that I've been around. The only thing they wanted to know was if you were done yet.
- then if he doesn't agree these are good things then it's definitely time to find a new job.
That is exactly what I did.
Wasn't the waterfall model such an attempt to bring the unruly art of hacking software into line with more established forms of engineering? Sadly a lot of existing techniques in other fields (such as the rigid front loading of design) just don't work so well in the flexible field of software. However, I feel newer methologies such as XP formalise the process just enough to add some structure to porjects and are more of a step in the right direction. I've noticed many people on slashdot attribute working reliable software to a fast code/test cycle which XP encourages...
Testing is not a universal panacea. The most rigorous of functional testing regimes will not expose the flaws in a system design (for example, how would unit testing find race conditions which only appear in the complexities of a production system?)
Good software comes from good design. A badly layered system probably can not be successfully unit tested, because each part of the system relies on all other parts. Badly designed systems are often unmaintainable because any change may cause failure in some unrelated other part of the system.
Good design is an art as well as a science. One cannot arrive at a good design by mechanically following a set of rules, however one can apply some principles to help. Principles such as:
There are surely many other principles which can be applied. I know when I code, I am continually weighing the benefits of one principle over another, and making value judgements. I think it results in pretty good and consistent code on the whole. Not perfect, often the design is faulty, but the first step in better design is to recognise the faults of the current design. And so iterate, and improve.
Carnegie-Mellon's Software Engineering Institute
While I was interning last year several top-level programmers were sent there for seminars. Granted, they all had been CS majors in college, and it wasn't a degree program, just a seminar, but CMUs undergrad CS courses are starting to incorporate some of the ideas from SEI.
God does not play dice with the universe. Albert Einstein
Those who fail to understand communication protocols, are doomed to repeat them over port 80.
Extreme Programming also suggests using two programmers per computer. Suggesting that to upper management would fly like a lead kite in every organization I have been in. Heck, I'd questions it's effectiveness myself.
I spent about 2-1/2 hours one day reading the Extreme Programming web site when someone else mentioned it here in the past. I had to stop after I read about using two programmers per computer. It was just too extreme.
badtz-maru
AMEN
I sympathize with you 100%. I hate being forced to make flashy, slow, badly designed sites. Even if I recieve good design specs to work with, the design is mangled by the time the site goes up. Once I build the beta version, someone will inevitably say "why don't you add two more buttons here, and put this in there, and make this move, and..." So I incorporate the changes and tweak and redesign where I can, but then reason #1 (time) comes in and I no longer have time for a redesign, and....
Well you know how it goes.
-Erik
Under capitalism man exploits man. Under communism it's the other way around.
So how do you make Free Software suck less? Should I be able to sue Linus when the kernel crashes? Or is all FS perfect already?
Just trying to open someone's head! I mean "mind!" Open someone's mind, um, to the possibilities! With explosives!
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...
.......... .........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.
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
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 believe you are right.
:)
Personally I know a lot of software engineers who think they are God's gift to the software industry and they often bash "non-educated" software developers. It's like that degree wildly boosted their ego.
Then again, I also know software engineers who are real nice people.
Use what you know, learn what you don't know, have an open mind. Now, wouldn't that define a good programmer?
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...
I would...if they could prove to me that they knew what they were doing. Do you think that having a piece of paper that says your an architect makes you a *good* architect? It's experience, talent, and the ability to continually improve that makes the difference between a great architect and a mediocre one. To suggest that college is what makes one a good architect is ludicrous. College merely gives one the opportunity to learn about architecture. It's the individual learning about architecture that makes the difference.
I'm a software developer by trade, and I am continually working on learning more and improving my skill set. I'm actively studying software design and architecture, and I'm a associate member of WWISA (World-wide Institute of Software Architects) whose goal is to turn software architecture into a more professional discipline like building architecture. I also don't have a college degree, but I have surpassed others I've worked with who do have one. College is great for teaching you how to learn. College is great for exposing you to things you may not have otherwise been exposed to. That doesn't mean college is great for everything or a reliable indicator of one's work quality.
Let's reword your question to be more appropriate:
Will anyone have an architect with the appropriate background and skill set design a house you would then live in?
My answer is a resounding YES.
Couldn't resist replying to this post - the truncation of the subject line (when adding the 'Re:') has an interesting effect :)
I/O Error G-17: Aborting Installation
In fact, it has the easiest-to-grok-instantly user interface of any program I've ever used. Sonic Foundry's Acid is almost as good. My theory: these programs have to be comprehensible to musicians, so they *have* to be easy to use...
InstaPundit! Ahead of the Curve Since 30 Minutes Ago
My basic point # [1] is: remain ever critical of management. Usually the best you can hope for is that they get you the resources you need and don't demand too many non-productive metrics. That they remain responsive to and respectful of the primary contributors (yea right).
I don't pretend that SW projects should run open-loop, but they should also not run on the misinformed and out of date dogma of some program manager. A good project manager (that most rare of rarities) can fend off the interventionist idiots with appropriate communications to them. Figure out what they are worried about, and find a way to communicate the progress which is being made on that issue (or tell him what resources are needed to improve progress, or to improve reporting).
Failure is not an option, but neither is unhelpful intervention.
In a smaller way, your answer is also found in the 6th of Henry Spencer's 10 Commandments for C programmers... no doubt this will spawn groans from partisans of other languages.
The Ten Commandments for C Programmers
Henry Spencer
The mind naturally weakens in some areas after 40, but it makes up for it in others. Being able to pick a tool that can help you make up for thoses losses is a strength, in my book.
Never used ML. Hardware engineer, by trade. Got it back when compsci was starting to emerge as a separate field from EE and Math.
The living have better things to do than to continue hating the dead.
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.
The living have better things to do than to continue hating the dead.
True and False.
Non-coders are really good at bashing an application till it breaks. Not having any idea whatsoever about how it works inside makes them try clicking and typing things that most geeks would overlook.
It takes a special cross-breed of geek and artist to design a good user interface. One has to know what the underlying code does, while also making the interface "feel right". Hardcore geeks typically make very functional but very unintuitive UIs. "If you don't find it user-friendly enough, then you're not a real user", or so they say. Just look at any UNIX-type shell for a fine example. ;^)
As a computer, I find your faith in technology amusing.
As in they work for MICROS~1? If so then, they're with the only company in the world that actually gets decent tech support for MICROS~1 development environments. The rest of us have to search through the horrid "Knowledge Base" on the web and attempt in vain to contact techies via email. Try doing that some time. No wait; don't ever try that! Go to the comp.lang.* newsgroups. You'll get flamed by a bunch of elitist programmers who believe that all answers are contained in the FAQ, but it's much less frustrating than the MICROS~1 web page!
As a computer, I find your faith in technology amusing.
...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.
As a computer, I find your faith in technology amusing.
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!
--
Feminism is the wild notion that women are human beings.
There are opensource projects underway that let you model your app without spending $$$$ before. Take a look at ArgoUML. Get yourself a book like Martin Fowler's "UML distilled".
No one would hire an architect or mechanical engineer who didn't have at least a piece of paper from a college.
Architecture and mechanical engineers have had centuries to develop well-thought-out standerds for doing things. Computer Science has had about 30 years.
Do you really think Microsoft actualy hires people that haven't gotten that scrap of paper? They have plenty of money to do so (yes, BillG never did graduate, but thats just BillG). They have no reason to hire anyone else. Yet, their software sucks.
And just what do CS majors learn? I've taken a High School CS course for AP and I'm not sure how I came out of it not hateing programing. For instance, when it came time to learn about linked lists, the book talked about what a linked list was. Then, it talked about what a linked list was. Then, it talked about what a linked list was. It never really said how to code the blasted thing. Not surprisingly, everyone failed the linked list test.
I don't hold out much hope on college, being that AP courses are designed to place you at or above the level of a college-level course.
------
Not a typewriter
You took a high school class and from their you can extrapolate out the entire scope and range of all CS curriculum in world?
Go back and read it again. It's an AP CS course. It's taken so you can skip college-level courses. It should be quite good, but it sucks.
Besides which, I was creating quite a few great programs on my Apple //c when I just learned how to read (6-8 years old). Sure they were in BASIC, but I learned more during that time then I ever did in that class.
------
Not a typewriter
I have to agree with whoever said they would also have failed in real life. In real life, you would've been asked to implement the linked list without even knowing what the hell the specifications of it were. Do you think at any software development firm, they tell you how to code the thing? If they already knew how, they wouldn't be hiring somebody to do it for them.
We're not talking about making a web server or something like that. It's a linked list, a fairly basic data structure everyone should know about. It also didn't help that neither the book or teacher talked about using '->' with structs until we saw the test. Bad teacher or book, you say? Yes they were. But I have yet to see or even hear about a CS book/teacher that was good.
Oh well. In a few minutes, I go off to my first day of Java Programing class at a techincal college. I already know quite a bit of Java (a little time and you can teach yourself anything), so taking this course should be quite enlightening.
------
Not a typewriter
He didn't say the language portion of the test, he said the Linked List portion of the test. I would assume that the rest of the course taught the language syntax
Not quite. It didn't teach the use of the '->' operator on structs until linked lists came up. Since no one could figure out linked lists, no one could figure out how to use a '->'. This is a failure to teach basic C/C++ concepts.
After I wrote the above comment, I left for my first day of Java programing class in college. I walked in, was handed a sheet with some code on it and told "type it and compile". Sigh.
Fortunatly, there was some notes on the back telling people to add some extra functionality that wasn't in the cut-and-paste code. Although I could handle it fine (with a few minutes of searching through some Javadocs), I wonder how many others were having problems.
------
Not a typewriter
I know quite well how to code a linked list now, but not then. As I've stated in previous posts, the '->' operator was not taught until linked lists came up, thus making the coding part very difficult.
As it goes, CS undergraduates do learn general concepts like this (they get harder!!).
I hope so. I spent 1/3 of that class listening to boring, repetitive lectures with poor analogies to real life, 1/3 coding projects (and doing it much faster then everybody else), and 1/3 browsing the net while I waited for everybody else to catch up.
------
Not a typewriter
HOW is not something you teach in a CS class.
In a perfect world.
I have a certain outlook on CS classes compared to being a self-taught hacker. The hacker learns brilliant coding skills by doing it, is excited when they figure out how to optimize their programs in a new and great way. The hacker is someone who may like ASM, not because there is any reason to, but just because you can. For a hacker, any problem is solveable as long he/she has the time to work on it. However, its paid for in the short term because it takes a long time (much longer then the standard college CS course would be) to get those skills.
The CS student, on the other hand, learns a more structured way programing. This isn't all bad, as it often is able to make up for a lack of being able to Think In Code like a hacker might. This means learning time is shorter, but its paid for in that there is no joy in doing it.
I prefer to blend the two together. As I've said, I taught myself BASIC on an Apple //c when I was just learning to read. But I also wanted to take a CS course in high school (and now college), even though I knew it goes somewhat against what I had already taught myself. Through this process, I hope to get the perfect blend of hacker and CS student.
------
Not a typewriter
You could have shortened the article by stating the following: Software today sucks. If you would like proof, go visit linuxgames.com's top 10 holiday game list.
Expect this to change in the future. The reign of propreitary consumers operating systems and applications is in check right now.
I think you meant to say, nothing that you hold valuable.
Dont get me wrong, I think that learning the easy half of C++ is important. I think getting a few months of insight into an assembly is important. So is an introduction to basic data structures and algorithms. Producing a dinky piece of software with some classmates may be of marignal value.
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. 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.
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.
Math is great and all, but I havent seen anyone even lay down a framework for a purely mathematical programming environment. The basic process of life is still optimization. (optimization in the broadest possible sense: assignment, procedural logic, conditional logic)
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.
What has a degree got to do with programming ability? I don't have a degree but I've worked with many incompetents who do. Anyone with a logical mind can be a developer, in fact some of the most talented people I've ever worked with don't have degrees. Computing isn't like mechanical engineering, you can learn it a great deal easier, and all this 'only graduates need apply' is just needless posturing.
I have had formal training. I've been on many courses, run by people that actually work in the industry, as opposed to university professors. Just because you've learned C and systems design at university doesn't make you better than someone who learned it on a course and has actually used it in the industry.
Your analogy is flawed. An architect has to design a whole building with no margin for error. A software engineer starts by doing simple changes to existing programs, going on to writing their own, specifying a few programs as an enhancement to an existing system, and then after proving themself in those areas they will be allowed to design systems with the aid of a more experienced colleague. No degree really prepares you for this as companies vary wildly in their development methodologies and 3-4 years in a university is not as good as 3-4 years actually doing the job.
I am not a programmer, so I don't pretend to know that much about coding. I do know this much, as the need for software that can intigrate with more, and also be tailored to specific need rises, the complexity of writing such software also rises. We are only human and will always make mistakes. What makes us different, is that we can learn from them. It's going to get better.
Of course, that's just my opinion, I could be wrong.
Software programmers spend too much time learning code and not enough time learning Human Computer Interaction concepts. I want to code all the time myself, but when that happens I revert to planning as I try to think of the user. They are the ones that must suffer with the system.
The system makes complete sense to you, because you have developed it and understand the logical model. Developers must make it easy for the user to develop their own logical model of the system and give the user "locus of control"; which means they believe they are in control! Ya trick 'em, it is so easy to do.
XP
managers...why god invented purgatory
Could you run that by me again?
forth ?love if honk then
I don't know you Jon but I doubt you understand code. I'm not trying to be an asshole or anything but this issue is relatively simple:
People who haven't slaved over code have no place in "Software Engineering" discussions!
I know that everyone uses software && I'm sure it bothers you that you have to reboot constantly because of a changed network name || hardware configuration && you see blue screens. I understand that it is bothersome to lose unsaved documents... however, non-coders (&& to an extent even casual coders) clamoring to bring about "sound engineering principles" to software design && construction are not helping anything. You couldn't understand what coding is like... what being buried in code is like... what getting vertigo from falling into a screen of code is like. Let me tell you that it's not like building a bridge. Can you understand that? It's not like designing a house. It's not like repairing a car. Your antiquated analogies are like sand in the vaseline.
There are also very logical reasons why a CS || IT || CE degree can be completely worthless. Your "standing offer" proves it's own foolishness: You don't have hobbyist architects || surgeons || engineers because they necessarily lack the skills to perform the position's responsibilities professionally!
Coding on the other hand can be lerned by a janitor teaching herself at home every night for free. She can rapidly become proficient enough to be indistinguishable from any programmer with a CS degree because there is very little hidden programming knowledge. If she can read (&& she's willing to be utterly geeky) then she can lern to hack Perl. There are cadavers everywhere to train on (so to speak) which you won't get arrested for cutting up && experimenting && lerning on.
Software development is not classifiable yet because it is not like anything created (|| engineered) which we've had to deal with on a large scale before. First of all, software is soft! It changes after it's deployed. It changes constantly. Why is that (you might ask)? Well the ultimate purpose of a particular software project is rarely (if ever) accurately foreseen. This means that you must design something without knowing what it will be (admittedly there is a spectrum of haziness). When a civil engineer approaches say an overpass, she already knows the exact friction coefficient of concrete, the tensile strength of rebar, the average speed a car will be going which determines the acceptable range the turn can bank, etc. etc. This stuff is rigorous because it is constant. It is successful because it is universally applicable. Here's a good example: All buildings need a stable foundation. What can be said of all software like this? All software needs an interface? GUI || CLI? Neither! The only things common to all software are code && coders!
Now all buildings do have components && builders but they all obey other rules too. Physical properties && characteristics of being constructed in real space. Software isn't like that tangible stuff. It's actually imaginary. The way you design a language compiler may have absolutely nothing in common with the design of an email client even if done by the same designer so why do people assume that there must be rules that could be followed to make all code better? It's because they don't know what coding is like. Yeah you can learn design principles && apply them sometimes. They even are very helpful sometimes but there aren't answers! There's no right way to design code. There's no right way to write code. It is an oddity of the digital era that the world is unprepared to accept the volatility of software. Software can be dependable && stable. The process to making it so has never been for any non-trivial task.
You trust in top-tier universities because they make hoops for people to jump through? Well they've been reliable in the past right? Well they do research so they should know better than others right? I know several excellent coders who lost interest in college because of the misguided "specification" && militant enforcement of "accepted software engineering principles" which were obviously asinine. Graduates don't necessarily know how to solve programming problems any better than anyone else (especially if the only problems they can solve are the ones that were taught). Someone who likes to do it will do it much better.
You ask how to judge someone's skills... simple: run what they've done. I'm done. TTFN.
*BBC*PipTigger
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.
No, Thursday's out. How about never - is never good for you?
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.
air and light and time and space
You took a high school class and from their you can extrapolate out the entire scope and range of all CS curriculum in world?
It's this kind of self delusional intellectual wanking that makes open source look so bad. Some manager somewhere read that and thought: "These linux kids a fucking morons". Now when I try to convince people that linux/apache/perl is the way to go the ghost of every halfwit moron post like that stands arrayed against me...
As a community, can we try to look at things when we say them and think about it and not be total tools?
The part about being told what a linked list is but not how to code it is icing on the cake.
Software Engineering is not about coding style - its about the software processes and mangement.
Sure there are formal methods like VDM that have methods for generating code from specification but its not always the best way to do it (imho).
Software Engineering is not concerned with coding style. But you should comment your code and you should use OOP where appropriate. Oh and we've been told that GOTO's are evil but I still use them when I occasionally get my BBC Micro out out of the cupboard. (I don't use goto's anywhere else though).
Moderators - This is exactly what XP is all about
Please mod this guy up!
And they'd fail in reality. Think about it. For a project you are given requirements, not how to code it.
They don't even have to be vauge (well, I don't consider this vague):
The program does what it is claimed to do.
He didn't say the language portion of the test, he said the Linked List portion of the test. I would assume that the rest of the course taught the language syntax.
If all you can do is reiterate source code you've seen, you shouldn't be a developer. We don't need more developers that just know how to use cut & paste or wizards, but ones that can solve problems.
Frankly, I think the previous poster sounds like so many others - a man in state of full cognitive surrender in the face of rampaging hordes of ineptitudes, trusting in universities to seperate the chaff for him. 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.
Moreover, Quake appears on 4-5 platforms (Win,Mac,Linux x86,Dreamcast, [PS2?]). That level of portability doesn't come accidentally; moreover, you think snarled code is fast - sometimes it is, but more frequently it's crap. Your 6-month timeline seems a little short, too. A successful engine is licensed out for the next 12 to 18 months; surely there is some support there, and some of the code, and at a minimum the lessons learned thereof, carry over onto the next one...
Your fetish for the degree doesn't make the degree valid! We are trying to prove what qualifies a skilled programmer, who works well on teams and writes stable & maintainable code. Can you prove that CS graduates do this better?!?!
It says them to you. I reserve my own judgement until more evidence is in. You define your own hoops.Now listen. I loved college. I don't begrude the years that I spent there(I went BS Physics). But the outside world is much more complex, and we spend much more time in it than we did in school. Very rapidly, your flock of well-trained graduates discern themselves, and knowing how to learn, rather than what you are taught in uni, is orders of magnitude more important. I have found no way to determine which people working with me are the tinkers, and which are not, solely by their education, much less the tier of their school. How is it you can divine so well people's fates and skills by this small data point??
I don't know, what are your hiring needs? How do you find people? What kind of word-of-mouth and reference checks can you do on them? What kind of code testing do you do? Do you mentor beginning employees?In re: to your other question, I have other skills, but the "Daddy paid for Yale, why can't everyone else do the same" attitude really annoys me.
Sure. Are you buying??If your tests aren't telling you what you think they are, then doesn't the whole idea of test first sort of fall into a big gaping hole in the ground?
Not meant to be a troll, just curious.
DO-178B has a bunch of different verification "levels" depending on the criticality of the software to be written. I spent a couple of years developing for a Level A certification, which is the highest level, used for the most life-critical software. The process is based on common-sense practices-- independent code review, testing, formal requirements specification and design analysis-- taken to an extreme level of anality. It works well: the resultant software is not bug-free but remarkably close, and any bugs that escape the various rounds of review and testing are very likely to be inconsequential.
However, this process is *extremely* expensive to implement and the software takes a *long* time to develop. It requires developers unusually skilled at formal analysis, and lots and lots and lots of developer time spent on review and testing. Thus it is not suitable for the mainstream market.
But we *could* improve software quality in the mainstream if we could make independent code review and formal design analysis easier and more effective: for these practices are the really crucial parts of DO-178B. (Unit testing is actually, in my experience, much less useful, because it tends to miss the sort of feature interactions common in complex systems: the Foobar feature works in mode A but not in mode B, or under light load but not under heavy load, etc).
> Adding a feature will take the same amount of > time whether you do it now or in the future. I have to disagree. Six months from now, you will likely have forgotten many important details about how your system works. It will probably take you longer if you postpone, as you will have to spend time regaining context. I often find that if I am working on a particular problem, then get pulled away for a week or two, I will have to burn several days, just re-learning the idiosyncrasies that I had previously known so well.
This is the second time you've said this. It makes me wonder if you've ever hired a "software engineer."
I agree there's an incredible lack of professionalism in the software industry and, especially, a lack of the kind of advance planning and structure that others have mentioned here. This is a topic that's been talked to death on Slashdot, and all I have to say is, software is not bridge building. Not at all. More like scientific experimentation.
But: have you ever personally hired a 'trained software engineer,' say, one out of Berkeley or MIT or Georgia Tech? Was it your experience that they could program in a structured way, as a part of a team? My experience in the past five years has been the exact opposite. University trained software engineers, versus 'off the street' people with logical minds and the ability to work in a team, have often lost out -- mainly, because they write code that is intensely poor in style, and (frankly) often lack the communication skills to work and collaborate with others. As someone else put it: programmers often can't deal; in my experience, universities are hiding places for the programmers who are least able to deal.
Oh, and can we stop calling them "software engineers?" They're not engineers, they're programmers!, which is a fine but quite different thing.
What makes this XP stuff so good? It cant possibly be the first technique to advocate rigorous testing. Or is it? That would be really scary...
The last project I did used a number of the principles of XP. I think that the term 'XP' is too scary however, and that its seen as a all or nothing deal.
My personal view is that XP makes use of Evolutionary Development (as opposed to Development By Design). In Evolutionary Development there are two principles at work :
Coding (Mutation)
Selection.
All methodolgies do Coding. However the way we look at coding varies. In most methodologies there is an assumption that a project is Developed by Design. Most developers are aware of the process of developing requirements, specifications, coding, and conformance testing (ie to the specification). Most developers are also aware of how this apparently logical approach is never how successfull projects actually work. All my successfull projects have been a mixture of planning and evolution, where the initial development is planned, and thereafter small incremental changes are made to the working system.
The XP books I have read describe how to do XP development - but didn't seem to provide a good account of why XP works. XP works because it removes the assumption that all the design needs to be done up front. It allows for evolution, where code is both written and selected.
The mechanism for selection in XP is Unit Tests and Peer Programming among others. Point is that these selection pressures are not present in 'traditional' developments.
These forms of code selection are not nessasarily the only methodologies which can work. Another example is Open Source - where only good source code survives. What do we mean by 'good' source code? We mean source code which continues to be used. The point is that bad source code - ie that is buggy and poor quality - tends not to be used.
Whatever method used, it is important that selection be applied in very small increments. It is no use taking a whole application, radically changing it, and testing/rejecting only at the end. With XP you check your code against unit tests on every checkin - which means that poor quality code can't get in. On a higher level you are releasing the code to users on a very regular basis. This ensures any user interface issues are found and 'selected' out of the code pool early in the development, and not given the chance to become imbedded in the application further.
One last note : when I talk about using 'evolution vs design' I am talking about a high level design, not the design you might do for an individual function or method. We will always need some degree of design. My point is that computer systems are now becoming so complex that our faith in our ability to Design from the ground up needs to be examined.
XP is one such attempt. I hope this puts XP in a clearer perspective,
There is the old joke regarding delivery of cutome designed goods:
There is more truth to this than many folks like to admit. For example, here is this story recently posted on the Computer Stupidities webpage: In any Case we have a lot of people who want things delivered in internet time. But the number of people who are profoundly expert in a particular software are rare. The result is that the competitive pressure forces the the balance towards fast delivery amd low cost.High Quality goes out the window.
There is an interesting story of a gentleman who wrote perfect code for a particular project. You can find the story HERE The parent page is also interesting, and worth checking out.
The bottom line is that it is a stoty of a guy who knows something sufficiently well that he was able to spend most of his time designing it, and made sure that the design was correct and perfect from the start.
Most places would have a heart attack at any thought that your would approach it this way in the first place.
I am still thinking on the proper conclusions to draw from all this.
"It is a greater offense to steal men's labor, than their clothes"
(directed to hardburn)
Here's how to do it.....!!!!!
A linked list consists of nodes connected by links :
| a |------->| b |------>| c |-->null
shit! that must be difficult!
(well, not really)
Look, if you want to get anywhere in life... just dive right in and work it out for yourself. Don't just look around and be content that because no-one else has a clue, you don't have to try.
Its OK not to have a clue, but its not OK to be content with it.
As it goes, CS undergraduates do learn general concepts like this (they get harder!!). This is so that no-one gets tied into any one technology. A concept can be applied anywhere with a little thought and study, but you can't compile Haskell using javac.
A university education is worth it;
1. for the experience (wine, women, wasting etc)
2. for a good "well rounded" view of the concepts
involved.
Its the old "Give a man a fish and feed him for a day. Teach a man to fish and feed him for a lifetime" situation.
There is a fourth reason, though wizard programmers tend to pretend that it doesn't exist.
4) Truly amazing procrastination
Does posting on slashdot during office hours count as procrastination?
I should be coding now!
Kilroy was here!
IMO a lot of industry courses are relatively useless because they teach how to program a specific language or a specific API. Degree courses usually aim to teach how to solve problems with programming.
I think that's true of a lot of university subjects but in my experience it's generally not true of computer science.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.
at the university of waterloo, where i go, there's a software engineering option for a cs degree, which forces you to take three large-program-structuring classes, plus a mix of social, business, and other related classes.
i believe that's along the lines of what you were dreaming about..
when the rain comes, they run and hide their heads. they might as well be dead.
I'd like to see that study, where is it?
TK
Actually, the only thing that the possession of a college degree guarantees is that the holder graduated college. It says nothing about the person's ability to work (hey...I know more than a couple people who coasted through school), or to think critically (again, I've a couple friends who have advanced degrees who can't think well linearly, or critically), or to stay on task (ADHD anyone?).
;-)
What matters most, to me, at least, is the person's ability to do what they can do. I don't care if that person has a piece of sheepskin. what I do care about is whether or not the person can deliver.
So...would I let an architect design a house without a degree? Sure, but I want to see what they can do. I want to see what they have done in the past.
That's my situation. I'm a guy who has been messing with computers for almost 15 years now, personally. I've been an extremely informal help desk for my co-workers for 10 years. But, I don't have a college degree. So it's been omre than difficult to find a job in the industry I want, and I know full well, with rock-solid certainty, I can do. I attribute most of this to "degree predjudice". But that's my own personal rant.
-jimmie
All I have to say about
http://www.tiernanoutdoorproducts.com/
is this:
AHHHHHHH!!! BLINKING TEXT!!!!! BAIL, BAIL!!!
Discipline is first,
Organization is next,
Then test, test, and test!
Donate background CPU time to fight cancer.
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.
I've hit Karma 50 and gotten a Score:5, Troll... I win!
However, I failed to mention that the code in question is in procedural Fortran (a dialect of Fortran 77), without data structures, and destined for a real-time environment. Most function interaction is through global variables (a datapool), and the code is somewhat tweaked for real-time.
None of the existing test are really computer based. They all require human interaction (story-based tests, comparing plots, watching for lights). It would be a significant effort to determine interfaces (all global variables look alike), and to even determine what the units are.
Unit testing would be nice, but it isn't really object-oriented code. It would take some real trickery to make it look object-oriented enough to use unit-testing, and, once you have made those changes, then how do you know you are testing the same things? For this type of code, it is a real possibility that the test functions would cause significant changes to existing code, or there would be code forks between existing code and test code.
It's also not possible to move to better languages. We have scripts, we have Fortran, and we have assembly - that's it.
It may not be as bad as other maintainance projects, but there is a significant amount of non-OOP code out there, and I'm not sure unit-testing will map well on all of it.
Here's a link to the book at Amazon. At $45, and hardback, I may wait until I get through a few other books, or at least read one of the starter Extreme Programming books first.
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.
While the engineering tools we use and the environment we work in may change rapidly, I believe the underlying 'science' changes more slowly.
The architect or civil engineer also deals with fast changing building materials and fashions, but the core science remains, underpinning all they do.
For example, the internet is just another distributed environment with it's own toolset, that is slowly and painfully re-learning some lessons the big iron guys learned in the 70's. Or what about that infamous quote that Linux is 70's technolgy?
What my CS degree taught me was how to THINK about a problem BEFORE trying to fix it. The actual engineering tools side they taught was almost useless when I went looking for a job in the real world, but the 'science' gave me transportable skills that have enabled me to leap between environments with minimal pain.
I hope I never have to work with you. Illegible code is the bane of my life. I've worked on very large scale systems that have modules up to 35 years old. You try maintain 35 year old, undocumented, spagetti code and see how you like it.
I try to write stuff that anyone can read and understand, bcause you never know what idiot's going to be looking at it in 30 years time.
Agree with you on the pencil and paper bit, but if I was 17 years old and coding as fast as people twice my age (and many times the experience), I'd be wondering what I was missing...
The practical physics involved in architecture or mechanical engineering doesn't change radically in four years. I don't think mechanical engineering is a good comparison to software engineering. Even calling it engineering somehow implies a more rigorous set of guidelines than programming actually has. I like the architecture comparison better--there's a little bit of art to it, not just the strict mechanics of gravity and materials. And in that light, I would ask, when's the last time you ran into an architect who didn't have to put in years of apprenticeship scut-work before getting to work on the big, cool projects? They may get the degree at a college, but they get the experience in the real world. Same thing with programmers. Most of the real knowledge and best practices are acquired outside the classroom. Unschooled does not mean untrained.
That said, I agree that a little more discipline would not hurt most programmers. But I think XP is a good step in that direction.
No relation to Happy Monkey
Everyone should write code (and I would define "code" in this sense to include documentation) that anyone can read. (OK, maybe your grandmother can't read it, but any competent programmer with a knowledge of the problem you are trying to solve should be able to follow your logic.) That doesn't necessarily imply there should be arbitrary, ironclad rules about indentation policy or variable naming or forms of idiomatic expression. But writing code for yourself is absolutely a prescription for disaster; aside from the obvious possibility that someone else may someday want to maintain or extend your code, you have to consider the likelihood that even you will be unable to follow your own code six months or six years down the road. (I've experienced this agony firsthand many, many, many times in nearly 20 years of on-and-off programming. I'm usually pretty good about documentation and unit tests at this point, but once in a while I get lazy and slip and I kick myself for days afterward when I realize the trouble I could've saved myself if I hadn't been sloppy.)
To use your own analogy to natural languages, writing code should be not unlike writing an essay. That is, a writer chooses a way to make his points that his readers will be able to understand. That does not by any means preclude the writer from having an individual voice and choosing phrases that he happens to like, as long as he gets those points across. But an essay that only makes sense to its author and is unstructured gibberish to anyone else is pretty much useless. Same goes for code. You need to wake up to the reality that code has, in addition to its purely objective end (i.e. perform this task), a strong communicative purpose.
"Biped! Good cranial development. Evidently considerable human ancestry."
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.
Well, most of the time was spent trying to deal with the, IMHO, extremely non-intuitive way messages are processed by said OS. I mean, here I am carefully cleaning out the message queue to prevent the same function being called twice, and my call ::PeekMessage() triggers handling of the message I'm trying to remove before it gets processed.
Anyway, the details are unimportant (but if you know a better way to do this, let me know), what matters is that I have to work in an environment where non-intuitive, sometimes even bizarre behaviors, pop up unexpectedly.
The lower level you are, the less you have this problem, though even Linus must have processor and hardware architecture quirks to deal with. But for everyone, the end result is that quite reasonable assumptions are occasionally false.
What's more, the rate of change is such that when we learn to deal with anomalous behaviors, they're likely to change. The anomalies will then bubble up from the hardware level to affect all the layers above it. As long as Moore's law holds up, the rate of change will make it extremely difficult for software to suck very much less.
Oh, there are absolutely things we can do, but there effect is going to be limited. It is the price we pay for rapid advances in computing power.
What's a sig?
The above is true to some extent. No, technology doesn't change engineering process, but software engineering process has changed radically in the last 20 - 30 years. 30 years ago, Top down and structured analysis and design was king. Today, most people coming out of college have never even heard of it.
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.
Engineering is about discipline, but it's hard to be disciplined when the industry changes it core methodologies every 5 years.
Being a good engineer doesn't require a degree or even formal education. It requires someone capable of learning. In some states (and countries) you are required to have a degree (and experience, and a number of other things) in order to use the "Engineer" title, which is fine by me for the most part, but don't make the mistake of assuming that someone that hasn't been to college isn't educated in the processes of engineering.
Lots of engineers screw things up, and lots of non-engineers get things right.
If you need web hosting, you could do worse than here
You're missing the point, really.
A degree doesn't guarantee that you have a brain, only that your parents had enough money to buy you one. Yes, people of lesser means can work their asses off to get a degree from a good college, but that doesn't mean everyone with such a degree has earned it.
Filtering based on degree doesn't limit you to only qualified people. Qualified people have experience, and that should be the filter.
If you need web hosting, you could do worse than here
The problem with software development is that people who don't know what they are doing are controlling it.
If management knew what they were doing then...
They wouldn't hire programmers who don't know what they are doing.
They wouldn't just go through the motions of following the process-of-the-week just to say that they have a process.
They would tailor a process to work for their organization by picking and choosing intelligently aspects from many software development processes.
They wouldn't hire overpriced consultants (who have supposedly read books on software development processes) to tell them what process to pick.
They would hire architects to design systems before letting coders start their work.
They would hire QA professionals who understand testing terms like unit testing, black-box testing, white-box testing, code coverage, regression testing, etc.
They would read books on software development processes.
They would read books on software management.
They would read books on software.
They would read books.
They would be able to read.
I've got a 'few' complaints.
Software Engineering, that's I've seen dislikes the concept of returning from the middle of a function. It's great in principle, a return acts (sorta) like a goto.
In practice, it sucks.
There are several piece of code that are quite elegant (and fast) if we detect the error and just stop processing. Without the ability to return, we need to create a RTN variable and constantly check this variable to see if we're supposed to execute any additional code. (Yes, I'm not kidding.)
It sucks.
Worse...some software engineering people want to adapt the languages to 'their style'. Ever hear of an elseif? They want to be able to fire business rules like this:
if (condition) expression
elsif (condition) expression
elsif (condition) expression
elsif (condition) expression
fi.
Heh...reminds me of ksh. I don't have a problem with this type of logic, especially if it's necessary. But why MAKE the language to this if you don't need to? (Besides, I still prefer)
if (condition)
... if (condition)expression
... else (condition)expression
else expression
The first can claim to be dervived easily from business logic...the but 2nd shows the boolean logic (remember that?). Perhaps other think in business logic, but when I'm writing code, I think in boolean. Besides, your using a language, why not use the full functionality of that language? Why invent elseif where a switch statement will work?
Design to the language. Don't force the language to the design.
Oh, and did I mention that software engineering doesn't care about the speed of execution? It's real goal is to take business rules and put them into code. The idea of making the code run smoothly, quickly, cleanly....out the window.
</Software Engineering Rant>
That said, I like the idea of extreme programming. (I still think more skullsweat needs to be put into the idea of project engineering - I could write a book at this point. sigh).
It's pretty much worthless to tackle something and find out what you thought would work won't. It's also going to the section that you spend most of your time on - it'll have a direct impact to whether or not you meet your deadline date or not.
Second, while the idea of testing first is admirable (and I do agree with it). I have run into problems that were untestable. For example, allocated memory in C isn't defined as to what will be in there...if you access it, there's no telling what you'll get. How can you set up a test for this that will fail?
Unlike Eric Green, I don't know that you're full of [BLEEP!] - you could be joking. Like him, however, I do think that Software Engineering can be fun. Here's an analogy to explain why I believe that:
I'm a big basketball fan and I've played a lot of pickup games. When playing you see a lot of guys who try to make the big flashy play. It could be a behind-the-back pass or a near-impossible shot, but its obvious that flash is what's important to them. It doesn't matter that they missed that shot 3 times before that, threw the ball out of bounds twice in a row, or only play defense every other time - they're having fun.
Then there's other players who play defense, take high-percentage shots, and will set the occasional pick so someone else can score. These players also have fun, but they realize that its always more fun if you win.
Obviously, you can't win every time and sometimes you need to try new things so you can get better. But, if you are serious about developing software, you need to play to win (for the projects you are serious about).
To understand what's right and wrong, the lawyers work in shifts ...
The problem is not that companies hire programmers without college degrees. It's that they hire incompetent programmers. The two are not the same thing. Holding a degree doesn't make one a good programmer, it just means that one is good at a certain (narrow) type of academic exercise. Whether or not one produces good code is a completely different question. My experience has been that companies hire incompetents because their interview process is not adequate to weed out the lousy applicants. Plenty of terrible coders have college degrees, and all sorts of certifications. The bottom line is that there is no substitute for allowing experienced technical people to control the hiring process. That said, I don't agree with the posters who say that college doesn't teach you anything. I think a lot of people who haven't been to school are not disciplined enough to learn the theoretical basis for what they do on their own. That's not to say that it's impossible, just that those people who do manage to teach it to themselves are the exception. Again, an interviewer has to know his stuff well enough to be able to tell the difference. I agree that software engineering is not CS. System administration is also not CS. Many of your points apply to hiring sysadmins as well as coders. In an industry that changes as fast as ours, it's unrealistic to expect that the college system will be able to produce a steady supply of competent practitioners of our arts. Some graduates can hack it, some can't, and the same is true of people with little formal education.
Get Microsoft to stop making software.
Let's break this topic WAY down:
1. If you don't know where you're going, you'll never get there.
In software, this means start with the Final Test (which is often called the Customer Acceptance Test, or the QA Pre-Ship Test, or whatever).
Until that test has been written and approved, don't even start the design. Write no code.
2. Find the hard problems.
This is part of that ugly stuff: Gathering Specs and Requirements (they are different, you know). Requirements Analysis. Initial design (only the broad strokes).
When you start finding "tough" problems, assign those to rapid prototyping efforts while the rest of the design proceeds in parallel.
3. Throw away ALL code that is written without a proper design to guide it.
That means ALL Rapid Prototyping code. For those hard problems, once you find a solution, immediately reverse engineer the design from it, and DISCARD THAT CODE!
4. A good design will allow even newbies to do 99% of the code.
It cannot be stressed enough: A good design saves time, money, frustration, problems and every other pitfall in the code development process. It isn't a "silver bullet", but it is the closest thing we have to one.
I had to prove this over a DECADE ago on two projects that were over budget and behind schedule almost from the start. On both projects I literally hired high school students and college freshmen to write the code. My job was to finish the design and test the code my programmers produced. They succeeded in spades.
5. Shit happens.
Features creep, budgets and schedules shrink, people come and go. Shit happens. If you are EVER surprised by this, you are either in the wrong profession, or are living with your head in the ground.
The weakest parts (greatest risks) of ANY project can often be identified well in advance, and must be closely monitored. Having "a" solution for each of your problems is seldom enough: Your highest risk areas need MULTIPLE solutions, so a fall-back is available when the primary fails.
6. Multiple perspectives are mandatory.
Seeing things just one way limits you to a black and white world, to travel along a single line. A second perspective gives you the freedom of a 2-dimensional plane. With a third perspective, it becomes possible to circumvent almost any obstruction.
What am I talking about? Simply this: Seek and understand the perspectives of others, especially those that differ markedly from your own. Understand them to the point that you can literally see them through their eyes, and argue their position for them (without playing Devil's Advocate).
Perspective allows you to push your horizon (your known limits) further away. Which in turn means you can see and react to problems far earlier.
While it is important for teams to agree on the direction to pursue, it is important to acknowledge that this is NEVER the "only" directiion available. I would recommend NEVER making a decision until at least two or three alternatives are available. This is especially true for the "easy" or "obvious" choices.
Sometimes, radical improvement and innovation demand bypassing the "easy" and "obvious". Unless you look for alternatives, you'll never find them. And you will repeat the same mistakes over and over (but in different ways).
Which is why, oddly enough, I seldom re-use code that I or my teams have written. By approaching things from a new perspective, I find old code always looks broken, no matter how good it looked at the start.
I should mention I have spent the last 20 years creating real-time embedded systems, often for safety-critical applications (such as nuclear power plants). Much of the above may not apply to a Web page or a Java applet, though I suspect it will apply quite well.
Ok, just one more:
7. The best tools are inside your head.
At all costs, avoid dependencies on any specific set of tools. Be flexible enough, and knowledgeable enough, to make effective use of whatever tools are available. Be willing to use them in ways their creators may have never imagined. (I once used an FPGA hardware simulation tool to help design and debug high-speed complex state machines.)
If a project is fighting about the tools to use, it may already be a lost cause. Tools are important, even vital, to the software development process. But no single tool or set of tools will turn a bad programmer into a good one, or allow incompetent managers to magically become competent.
A well trained and capable brain is worth more than any pile of tools. And a really good project team can succeed with little more than a text editor and a white board.
I'm done now.
If you are going to be an engineer, you damn well better attend college. Show me the man who can become a competant electrical engineer without classes, and I'll show you a man who has wasted five times the time he would have used in class. Show me a modern physicist who never attended college... or a mathematician.
So the moral of this story, kids, is some fields are technically demanding and others rely more on artistic talent etc.
"Any connection between your reality and mine is purely coincidental." -Slashdot
Having just written a paper about the future of Open Source Development as an enterprise solution I want to point out what I think is the major problem in OSD. Unlike developemnt in the Microsoft world (...Sun world) OSD lacks a codified base of design metrics akin to COM, DCOM or CORBA. The ANSI ruleset connot be used as a design metric, it was never intended to.
Until we all can write it all down and get together in agreement on some simple (or not so simple) rules I think we will always get crappy code. The current development of the OSDN is a step in the right direction.
In teh event of an actual emergency this space might provide useful information.
Because you arrogant asshole coders that read this site think you're gods just because you can code and that you don't need commented code and solid project design BEFORE a line of code is typed and any other 'suit/manager' stuff. It's some game to you people, not a profession. It's a little contest with all of your quake buddies to see who can write the most l33t single line, cryptic, non-commented or documented code. I have news for you all. Software sucks because of you and your unrightfully inflated egos.
The problem is the same with any relationship - lack of communication. With closed software, you have no easy way to connect with the engineers who are developing it. You have no way to give direct feedback, or incentives to get them to pay attention to the "users" needs (except a pink slip if they don't listen to the product marketing manager). With open source, at least you can do something about it yourself (if you can hack). What we need across the free software (or open source if you prefer) industry is a simple way for users to give feedback directly to the authors. Feedback in the form of $ and suggestions. Today, commercial enterprises are there to take money and suggestions, but we need ways to get these businesses to be as transparent as possible, taking as little out of the dialogue and out of the cash flow. They feedback and profits should be decentralized, going to the real creators, which are both the users who define new needs, and the engineers who create the machine interface. MandrakeSoft is trying to do something along these lines, and has just created an experts marketplace so that users can give back to technologists. Soon enough, there will be direct links from software products coming out of communities directly linking with a system like MandrakeExpert. This will finally give users a simple way to "give back" directly to a person who has "given" to them. Check out http://www.mandrakeexpert.com. All of the commercial open source companies need to remember why they exist. The exist because of the thousands of gifts that come there way from users and developers. The commercial companies need to invest more of their investors capital trying to figure out ways to give back to these communities that give them life. Otherwise, the communities will stop giving, and they will all become proprietary companies.
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:
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.
The easiest way to make software suck less is to force software companies to provide a real, truthful legal warranty for it when it is sold.
Software would cost more initially but less in the long run since the purchaser would not have to pay as much for after-sale support simply to get the software to perform as it is advertised or written in the manual.
The Milwaukee School of Engineering (MSOE) in Wisconsin recently started a software engineering program, mostly to attract potential CS students who would attend state schools. This year is the first year that MSOE will have Software Engineering graduates, IIRC. They still have computer engineering for students who want a hardware/software background.
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/
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.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
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);...
Software Engineering is the full process of developing software, coding is only a part of this process. It also includes; macro & micro design (including data & elements of process design) ; unit, integration & systems testing design, it may perhaps also include detailed analysis & development; the commissioning & deployment. Many 'programmers' would not know where to start with many of these.
If they DO know where to start then they are making the transition from Programmer to Software Engineer. However, I don't think that you need a formal qualification to be a Software Engineer, ability from knowledge and experience of the whole process I've highlighted above, is what makes grade.
IMO, formal training often reduces the ability to think creatively -- once you are taught "the right way", it's hard to break new ground.
This post demonstrates the posters Prejudice (envy?) against Software Engineers, it also shows a who is 'thinking within the box'.
I'm hoping this is just a troll and you really don't believe in anything you just posted. While this idea at a glance looks correct, when you really start to think about it, you realize that people have different needs and uses for a computer. Just looking at the big picture of computing, there are many different types of computers and operating systems available for those computers. This might help you understand why different systems are needed.
Lets say you are in charge of a printed publication in a school. From what I've heard, PowerPCs running some kind of MacOS are a good choice for people in need of desktop publishing. A librarian who works at a public school, working on a yearbook, may choose to run down to the store and pick up one of those colorful iMac computers as it may be the best tool for the job.
Now on the other hand, you have a programmer working on the desktop publishing software that the libarian uses. Personally I have found that UNIX-like systems are the best systems for me to write code on. I may be writing a program for Windows, but the actual code gets written in a telnet window and thus on a totally different system (probably running gnu/linux).
How does this relate to software? Take the GNU system for example... There are many different combinations of applications (and soon kernels) that can make up your OS and this turns out to be very flexible. Flexibility is a good thing, even if it means the thinning of available programmers.
If you really don't like free software, then don't use it. There is an operating system for people who think like you do, it's called Windows. While you're at it, use Microsoft Office, Microsoft Outlook, Microsft VC++ (or whatever it's called), and Microsoft Internet explorer. Join the drones and have fun!
On the other hand, if you like making your own choices in life and not having someone named Bill make them for you, I would suggest a free OS such as GNU/Linux.
Of course the difference between architecture or civil engineer and a software engineer is that the laws of physics don't change every couple of years. 90% of what a civil engineer learned 20 years ago is still valid. 90% of what a software engineer learned would be irrelevant (what internet?).
Since a software engineer has to re-learn his craft at a much faster rate then the other examples, the relative value of a degree some years in the past is much less.
This same problem faces universities trying to create a software engineering school that is teaching to an ever moving target.
Software engineering is a good thing, and I've seen it really pay off. But certification is either unnecessary or counter-productive.
Certification works best in technically stagnant fields like architecture and civil engineering, and there, mainly to restrict the supply of architects and civil engineers. The pace of change in software (and, to a lesser extent, software engineering) is too rapid for that. In any case, certification is more often a barrier to entry to a profession than a means of consumer protection.
I've got the CS degree myself, and lots of pieces of paper saying I know how to do this and that. Their only real value is to soothe nervous clients. Most of what I've learned that's of value was learned outside the degree and certification programs, and could not be learned in such programs. Colleagues of mine with degrees in other fields, or no degrees at all, are just as good, or better, software engineers than I am.
Remember, NOBODY who founded the CS field had a CS degree. There weren't any then. That includes Turing, Von Neumann, Wiener, Hamming, Knuth. I could go on.
Get your teeth into a small slice: the cake of liberty
But, how long were people building houses that didn't collapse and bridges that didn't tumble before masons discovered through trial and error the basics of design that work, vs. those that don't? and how long before such was codified into professional code and civil law?
And, how many civil construction firms force designers and builders to finish a highway bridge with a sub-standard design or poorly chosen material? Not too many, and if they did, it wouldn't be certified for use, and they might find themselves in jail for their trouble.
In Addition, the properties of the basic materials used in construction don't change. Materials scientists will for sure create new ones, but I doublt you'll see a construction crew forced to discard all their hard earned knowledge in 'how to frame a house using 2x4 timber' just because MicroWood released a new version of wood that is incompatible w/ previous releases.
Or something like that.
Display some adaptability.
Phred
Guys, we've known for a LONG time that there are a set of things that need to be done in order to make stable software. None of that is anything new.
So the problem is not that we don't know what to do. It's either that it's not sticking in people's heads or that there are outside forces that are preventing this.
In the case of your average software developer, both of these are happening. Good programming practice gets put on the back burner because they *need* to ship.
Gentoo Sucks
What I resent is not the implication that college graduates are better qualified (I think that the average college graduate programmer is more skilled than the average programmer that didn't go to college. This doesn't preclude the existance of very skilled non-grads and incompetent grads.) I pissed off when people tell be that college some how sucks the creativity out of people. That is obviously untrue. Do I need to provide a list of succesful, creative college grads to back that up or what? Give people credit, we are capable of seperating the useful from the useless, even in our classes.
---
"Against stupidity the very god themselves contend in vain" -Johann Schiller
Oh by the way, even college grads make typos...
---
"Against stupidity the very god themselves contend in vain" -Johann Schiller
You want to know why software sucks? This is why today's software sucks:
Frank Lloyd Wright in today's software design environment
Imagine Frank joining a building design team as a newhire on Monday. He attends a design meeting:
Boss: Hey everyone, we have a newhire whose name is Frank Lloyd Wright who's a software engineer.
Frank: Hi everyone.
Boss: So let's kick off some issues on our new Fallingwater project...
Engineer #1 (John): Hey, we've been building functional cinder block outhouses for decades now using the functional method, and dammit, it worked for the last 30 years. Ignore that last project we worked on where we had to knock down the whole house just to add another bathroom. I see no reason to use any other method of designing this building and you can't tell me any new design method will work.
Engineer #2 (Joe): I've just read this book on designing building by patterns. Listen to just me as I tell you how to design this whole building. At least wait until I get to Chapter 3.
Frank: Um, I had this vision of using an architecture where every part of the building has a specific purpose, there were specific interfaces between the components, and they all fit beautifully together, along with the external environment. I've done a number of projects that...
Engineer #3 (James): [butting in] That's fine Frank, but we have to build this building in the same manner as the last building, so we don't have to change the documentation.
Boss: (who just happens to like #1): I think John has the right track for building this Fallingwater project. Let's get together two days from now to see how things are progressing. Let's keep working on that design document we've been doing for the last year and a half.
Next design meeting (two days later):
Boss: Hey everyone. Before I start, let me say Frank is leaving us to work at another company starting next week. Let's have a going away lunch tomorrow, OK? Let's continue...
Sentence:
Boss: Hey everyone, we have a newhire whose name is Frank Lloyd Wright who's a software engineer.
Should Read:
Boss: Hey everyone, we have a newhire whose name is Frank Lloyd Wright who's an architect.
Sorry. Damn.
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.
Frederick P. Brooks once wrote a famous essay in which he claims that there is no silver bullet that can solve the software reliability crisis. It is interesting to note that the reliability of the human brain increases with complexity whereas that of computer programs grows proportionately with complexity. Why is that? Is there something that the brain does that we can duplicate in our software? I suggest that Brooks may have done the software engineering field a disservice. There is indeed a silver bullet out there and the brain is proof. I propose that the US goverment and the software industry enact the equivalent of the Marshall Plan to find this silver bullet before the crisis turns into disaster. MOBE 2001
.sigless since 2003
My software doesn't suck. It was made to be sold by professional coders at a place called "Microsoft," and not by open source hobbiest. Because of this fancy "software for money" model, the products are high quality and made to run on over 70% of the computers ever made. Certain other programs of mine were made by idealists from "IBM" and "Sun," and while they are more buggy and confusing, they are much better than similar programs from the "GNU" company.
Hey freaks: now you're ju
I've taken a High School CS course for AP and I'm not sure how I came out of it not hateing programing. For instance, when it came time to learn about linked lists, the book talked about what a linked list was. Then, it talked about what a linked list was. Then, it talked about what a linked list was. It never really said how to code the blasted thing. Not surprisingly, everyone failed the linked list test.
I have to agree with whoever said they would also have failed in real life. In real life, you would've been asked to implement the linked list without even knowing what the hell the specifications of it were. Do you think at any software development firm, they tell you how to code the thing? If they already knew how, they wouldn't be hiring somebody to do it for them.
Also, Microsoft software does not suck for a large portion of its users. For instance, my mid-50's parents. All they care about is being able to type up a letter in Word evey once in a while, print out an e-mail from Outlook, or buy a plane ticket online viewed in IE. Windows does all of that perfectly fine. They don't care about cool features, optimizations, or having a robust OS. If the computer crashes, they just reboot. They aren't losing ultra-important data, nor do they need to have their computer on 24/7. They want a simple user interface, icons to click, and the sense that they got something done. They don't think any of it "sucks" at all. And they certainly don't want to deal with an Linux install or anything other than what has already been simplied and laid out for them. Microsoft software only sucks to the people who can analyze it and for people who have run into problems with it. For my parents, Windows and Office are truly useful.
Also, you should note that AP classes do NOT cover everything in a college curriculum. Depending on the university, you miss out on a LOT by taking the AP credit and not re-taking the class at the unviersity level. Of course, this does depend upon the school. The type of CS classes you take in college depend vastly on where you go. And believe me, there are some schools that will hit you with things your AP CS teacher didn't even dream of touching.
I don't know about your high school, but I stopped being spoon fed after middle school. HOW is not something you teach in a CS class. In a biology class, you are teach how a cell divides; in chem you are taught how a reaction takes place. But teaching you how to implement a linked list takes out all the application. So you've been given the code for a linked list. What did you learn by being handed that code? It's the process of doing the implementation yourself, of doing the coding yourself and figuring out what works and what doesn't, that trains you to be a programmer.
CS classes at my high school were not about teaching how, they were about teaching a way of thinking to get to how. You are given the tools - the definition of a linked list, and the syntax/logic of the language. The learning part comes from you putting the two together.
I have to agree that at a High School level, it's very difficult to find good computer science teachers. Most good programmers are not equally good teachers, especially to an age group as difficult to teach as high schoolers.
Personally, I'm at a university taking CS courses because frankly, I'm not motivated enough to learn anything without the pressure of a gpa on my back. I'm a slacker by nature, so forcing myself to attend an Ivy League has really made me get off my ass and learn. I'm also a audio/visual learner. I learn by listening, and by associating what i see (lecture) with what I do (homework). I don't believe that getting a CS degree necessarily makes me a better progammer than somebody without a degree. But I do believe that I'll gain skills going through the university life that those who do not go to college miss out on. And I have had some EXCELLENT professors in the CS department. Well, two, to be exact. And it was worth the ridiculous tuition I pay to have the privelege of being taught by those two professors.
As for good CS books - CS is an art form. You can't really learn it from a book. You can pick up a book on drawing, you can read all you want about techniques and materials, but in the end, you need to actually sit down and DO it. And no book will ever really be "good" at teaching programming, because programming is a process. Books will never measure up to simply trying out something to see if it works. There are good books out there to be used as references, and good books on the structure of languages, algorithms, and data types, but I don't think it's possible to write a book that teaches you how to program.
Agreed! (now for my plug....) In the CSE program I'm in, we are required to take extensive math classes. REQUIRED. At least 3 semesters of proof-based classes, then a very difficult math-based algorithms efficiency class. And the results are dramatic. If you can logic your way through a complicated proof correctly, you can logic your way through any implementation thrown at you. Or at least, you have been trained to logic your way through.
Even Ricki Lake admitted that.
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
The problem is that "programming" per se is often not taught in Universities, but its hoped that you will just majickly "pick it up". I read an article recently (can't remember the source) that proposed the following programmer "litmus test". It's just a basic task that one should be expected to know how to do if you use C++ at all.
Try it!
Given a class CFoo, subclassed from a base class CSuperFoo, write the copy assignment operator. The only members of CFoo are two pointers to instances of a monomorphic class CBar.
A possible declaration might contain
class CFoo : public CSuperFoo
{
private:
CBar *m_bar1;
CBar *m_bar2;
};
You may assume the other classes are implemented fully and properly. Also, the pointers have "own" semantics not "alias" semantics.
When you think about it, any C++ programmer should be able to do this. Everytime you make an object, you might need to copy it. And its often the case that a structure such as this can occur in C++ programs. Have a crack, reply below with an answer. Don't feel bad if its incorrect though, in the article they mentioned that no one they interviewed could give a correct answer.
Makes me wonder is a problem with programmers, the language, or our education system?
It's not training, testing, discipline, or a rush to production that makes a difference in many cases. A lot of engineering produces things that suck because management and engineering want it that way for economic reasons, namely that there are people who want to buy things that suck. Many people want to buy cars with no air conditioning. They may prefer cars with solid plastic seats if they existed.
By the same token, a lot of software doesn't suck, even if it doesn't do every magical thing that everyone wants. We expect more and more from software so we impose standards on the user interface, intercommunications, archiving, performance, reliability, etc. Software is so flexible that it doesn't have to be high standard in every area the very first time. It's not like a house that no one wants to upgrade in a major way every year. Software users are happy to use software that is under construction. That's not the mindset of house users.
We should expect standards to improve. The amount of energy expended to produce software is very little so software producers feel little compunction. Software production is a downright fattening exercise. However, software usage is not low energy. If software outputs suboptimal data or directives, a lot of energy is wasted doing physical things that ought not be done or that ought to be done somewhat differently. We haven't had as much ability to tell whether suboptimal software might be-after all for the longest time we were running machines that go slower than 100 MHz and spent most of the time disking to virtual memory. Now we can get more real-time feedback to guide us in building better software the first time around.
Use the table. Long pips are for weenies.
Know your pads. One time pad: good for cryptography. Two timing pad: where to take your mistress.
Most of the named techniques make sense in context, but their grouping under a single name encourages cultish thinking and counterproductive politics - things which will at best delay and at worst sink your project.
Sanction lazy reasoning like "unit testing is good because it's part of Extreme Programming" instead of "unit testing is good because it quickly reduces defects" at your company's peril.
The promotion of jargon like "stories" adds to the confusion. (The previous "use cases" is not only conventional but also compatible with normal English.)
Finally, some people like to divert the focus from their and the group's actual productivity by talking about "mindset." In my experience, such people are usually obstacles to getting anything done. We have one of these clowns at my current company - he's barely done a useful thing in the last eight months, but he's sure talked a lot about mindsets (not XP, but other preferences) and absorbed a bunch of our unwilling time.
To be clear: I take issue, not with any of these ideas (which are in fact useful), but with their assembly into a sacred cow with private language and a Capitalized Name.
I often think that people who ask: "Would you hire an architect to design a house for you without formal training?" don't read the newspapers.
One of the most visible engineering projects in Britain recently was the Millennium Bridge across the Thames which had to be closed the day after it opened because it was not stable. People with degrees and awards for Architecture and Engineering forgot to check the most basic things about a suspension bridge, stiffness and damping, and so made fools of themselves. The number of award winning architects that design buildings with leaky roofs (in Britain!) is too large to list.
I have spent a lot of time in the industry fixing other people's code, and have seen awful code written by people with advanced degrees in software and fine solid code written by self-taught amateurs. Often programmers only use their formal training for ways to deny the existence of errors in their programs. It seems to me that the most valuable traits are the knowledge that your are fallible, the determination to find your mistakes and fix them, and an attachment to the basics of the art.
In general, managers and teachers are more impressed by flashy add-ons than solid basics, and the results are programs, and bridges, that fall down on the job.
I'm not sure how you can say any of this. How is English, with it's complex myriad meanings that make it so difficult to learn, better than Esperanto, or Loglan for that matter? Just because it has become a de-facto standard in no way means it actually is better. Or would you argue that Microsoft must be the god of all software packages since it is used so extensively?
As for your statement, "as long as everyone writes stuff that they personally can read", that would create a lot of potentially useless code. Imagine that someone write a wonderful word processor, everyone loves it and begins to use it. Then imagine that the writer of the software dies and suddenly everyone notices that the author wrote the software using his own proprietary language. Now, either everyone can spend (waste really) months learning his new language to update the software, learn to live with the current version for the rest of their lives, or write a new wordprocessor from scratch. Imagine how much time could have possibly been saved if the original author had instead invested some time to write easily understandable, well documented, managable code. Everyone would benefit.
--David
Chaotic, naturally evolved languages work best - like the english language compared to esperanto. When it come to code, as long as everyone writes stuff that they personally can read (and if they have half a clue they will) then its no big deal if it doesn't confirm to your old CS professors unfounded ideals. Let GOTO's stalk the land!
Principles in these matters are just invented artifacts.
You know exactly what to do-
Your kiss, your fingers on my thigh-
You know exactly what to do-
Your kiss, your fingers on my thigh-
I think of little else but you.
The big problem with intrdoducing schemes like Extreme Programming is that they are usually met with a chorus of scoffing from coders. Nobody likes writing unit test plans for every piece of code they write. Most coders want to dive straight into the code and ask questions later. So the big challenge is to convince coders of the huge benefits of such schemes, even for teams of experienced coders who are often harder to convince. If the coders aren't fully convinced that its a good thing, they'll put in a half-assed effort, or they'll try to debunk it, and it won't work.
How to convince them? Theres only one way I can think of - first hand experience, being put through a full software development cycle with Extreme Programming style procedures in place - and at the same time, motivating the coders to give this new thing a proper try. A big ask.
Programmers don't suck either... it's the programmers who think they can teach that suck.
In my limited experience the best programmers are mathematically trained.
Why?
Because, for your average computer enthusiast/hacker/nerd/geek, a computer science course is boring and moves s o s l o w l y.
The maths course, on the other hand, moves far more quickly and trains you to think in increasingly less obvious and more contorted ways. At the end of the three years of degree, a lot of the mathematicians take a diploma in CS, (1 year), which covers all the computing in the 3 year CS course.
The result? Mathematicians, trained to pick holes in their own logic at every step for an intense 3 years, armed with all the knowledge from the CS degree, make the best programmers, and they write the most reliable code.