Ah, that's heartless, dude. Think about your poor parents, complete noobs who can barely turn the computer on, literally suffering because they can't access the internet! I mean, God, without the internet all they have left is cable TV and the newspaper. How would YOU feel if you had to watch TV to get your info? God... What a fate (shudder).
I understand the impulse to run screaming, but you have to take pity on your parents and help them out. Remember what THEY had to put up with: first, a couple of years of changing your toxic diapers, then ten years of your psychotic, animal-tormenting childhood, then your demented, sex-fiend puberty, the college phase in which you wanted to be an anarchist and almost got thrown bodily from your chemistry class, your goth phase and all those animal sacrifices... Hell, with all they put up with, what's a little tech support?
Plain vanilla glass is a poor solution because it can be very easily broken. once glass is broken, water gets into the house and rapidly decomposes it (look at any number of old, abandoned homes and you'll see what I mean).
Plexiglass may yellow, but it is very difficult to damage (I had suggested a 1 inch thickness, which is bulletproof). Thus, it is a better solution to the problem (building a home that can last for centuries) than plain vanilla glass. One might also point out that even if plexiglass yellows, it will still keep out the water that leads to a home rotting from within.
As far as better solutions go, perhaps a thick, laminated tempered glass would work. It would probably be significantly more expensive though.
I think the reason companies will keep pushing for a more componentized future is economic. They're already outsourcing all the programming jobs (well, they're outsourcing everything else too) so once all programmers are as inexpensive as possible, to make them even cheaper they'll have to simplify development. That's all there is to it, I think. I don't think companies care about bugs particularly, unless the bug actually impacts sales.
So, basically I think it's about eliminating labor. But, I'll still be programming, even if it's in my bedroom.
"> I find my complete irrelevance to the universe to
>be entirely invigorating.
That's funny, because most people despair to be in such a situation."
Really? Why?
I've always thought it was kind of liberating that no matter what I do, accomplish, or fail to accomplish, in a hundred years no one will even remember that I ever existed. Oh, I suppose that if I decide to have kids, my great grandchildren might remember me in some way, if only as an old, yellowing picture in a dusty book. But other than that, I am completely confident that everything about me will fade into dust just as my physical body will, and that ultimately, nothing that happens in this life matters even a little bit.
This is a Good Thing. It means we're truly free to live our lives the way we want to. Our ultimate, inevitable, and total obscurity is a blessing you're underestimating.
BTW: it is true that SOME people attain fame, or infamy, and are remembered for hundreds of years. But, there's a flip side to this. Future historians, trying to flog their new book, may entirely misinterperet everything you do, misquote you, make you look like a total knob... Even if your future PR is generally GOOD, there will still be some people who try to discredit you for no better reason than that it burns their ass that you're known and they're not. So my thinking is, it's more relaxing to be a complete unknown than to be known. At least, you don't have to worry about someone making an ass out of you posthumously.;)
Hang on, you missed the whole point of the conversation. Someone asked how he could build a house that would last *FOREVER*. That's what we're talking about here.
For the reasons you list, I RENT, ok? This is just a theoretical discussion of how to build a house that archeologists will be scratching their heads about in a thousand years or so.
Well, a tree's root system tends to extend out as far as its branches do, right? So if you gave yourself at least 100 feet between the outer walls of the house and the treeline, you might be ok... Besides, I was thinking of a foundation that was poured as a huge, several-foot-thick slab with everything sitting on top of it, not the 1 foot thick foundation wall type in most American homes. MY foundation would be a huge, solid brick. I don't think the roots would affect it all that badly.
One idea I had for creating a roof slab was, dig a hole in the ground in exactly the dimensions the roof slab will take (or in multiple sections if one section gets too heavy for a crane to lift), dig the hole six inches deep, pour the first inch, then set the reinforcing rods and pour the rest, setting rings in the soft cement so that you can hoist it into position. Then, hire a crane once you've got all your pieces molded, and hoist them into place, fixing them permanantly one at a time.
I'd probably arrange the interior walls so that I could have the roof slabs lay across them, supported by the walls. They could be pinned and mortared into place with rebar and concrete.
I like your idea about using concrete for the angled part of the roof... So, you could theoretically have the interior walls' tops angle, which would let the roof angle and water wouldn't accumulate. If you put one of those snow kits on the outer part of the roof, you wouldn't have as much snow accumulation, either. They sell them here in NY. Basically, they're metal cladding with vertical fins; the snow starts to melt and then slides off the roof because it won't stick to the metal.
Several people have mentioned the clouding of Lexan; one said plexiglass works a lot better. But I like your idea best, use a glass outer pane to protect the lexan from weathering and the Lexan for strength.
Building what amounts to a modernized castle has always been a fantasy of mine. Ijust want a small one, maybe the size of a four bedroom cape. I'll never afford one, but hey, it's fun to dream.
Pretty good ideas! Tudor architecture's pretty cool, btw: I've always thought it looked great. And, I love the idea of spiking the interior wood surfaces! Hilarous! I can see a future philistine working now:
"HONEY! Bring me the Sawz-all, I'm going to cut down all this ugly oak..."
(WHIRRRRRR..... ZZZZZZZZZZZZZ.... PING! SNAP!!!)
"HONEY! Call Dr. Forrester, would you? I seem to have had a mishap! Oh! And, bring me a bowl of ice and a quadruple martini, would you?"
Windows that won't open??? Nah, you can make the frame out of steel, coat it with a polycarbonate based paint, and have nice windows that swing open like french doors. They'd be easy to secure, too, just latch 'em in the middle. The polycarbonate would keep the steel from rusting.
Of course, MY preference would be along the lines of the old "arrow-slit" model, with the plexiglass fused to the stone all the way around. But, then, they don't call me "crazy" for nothing.
BTW: I do indeed have aesthetics. They're just not yours. It takes all kinds, remember...
Well, if you're going to spend all the time it would take to build the castle I described, you'd probably want to take the time to make it beautiful, by using marble tiles in the floor, and granite stone tiles for the walls... You could probably achieve any of the following looks without too much trouble:
1. Medieval castle (marble and granite tile, lots of iron fixtures, etc)
2. High-tech futuristic (keep inner surfaces smooth and clean, paint them bright cadmium white and use all steel and chrome fittings for everything, deco furniture, etc)
3. James-Bond type secret lair: Similar to number 2, but dimmer lighting and more "evil".
4. Rustic: Use lots of aged, polycarbonate-treated oak for the interior, granite rocks for wall covering (log-cabin style), lots of animal skins and trophies around.
You can have a pretty amazing pad if you've got the bread for it (sadly, I do not, but now you know what I'd go for if I did -- number 3!!!).
Step 1: use stone and concrete. The Romans used stone and concrete extensively, and many of their public works projects are STILL standing two thousand years later. Today we have reinforced concrete, which is even stronger than anything the Romans had. Also, this will make it prohibitively expensive to tear your house down if anyone gets any bright ideas about turning your property into a parking lot in a hundred years.
Step 2: Use concrete for interior walls, floors, well, basically everything. What's the first thing to go in old houses? The roof. And, when it does, water gets into the house and the whole structure rots. A concrete roof will keep water out, which is the most important thing if you want the house to last.
Step 3: Don't use glass for the windows. You can get a 4x8 sheet of inch-thick lexan or plexiglass, which is bulletproof by the way, for 175 bucks down on Canal Street in NYC. It's an extremely resilient material.
Step 4: Don't build the electric and etc into the walls. Design the house so that everything is retrofit, i.e. bolted onto the surface. That way you can always strip it out and replace it later. Note that you can't do this with plumbing, but no plan is perfect. Go for PVC pipes there; at least they won't rust.
Step 5: Paint EVERYTHING with a polymer-based paint to waterproof it.
Step 6: make sure the house sits at the base (or top) of a cliff or some other construction-inconvenient location. Then plant LOTS of oak trees all over the place. Within fifty years they'll turn into a nice forest. This has a couple of benefits:
A) if anyone tries to build on your property, the tree huggers will come out and Hayduke their machinery. They'll also spike the trees, which makes it reeeeeeeally tough to chainsaw them down safely.
B) Even if the local town board figures out how to get around the environmentalists, it'll cost 'em a fortune to knock down all those trees and make room for a wrecking crane to go for the house. They'll give up and go somewhere else.
Step 7: Cultivate the area around the house into a wetland, then make sure every environmentalist in the area is aware that it's there. Then, get the EPA in to declare it a wetland. This is way easier than you might think. It makes it just about impossible for anyone to build anything there ever again.
STEP 8, the MOST IMPORTANT STEP: Put the whole property into some kind of legal trust, so that you don't even really own it anymore and no one can sue you for it. Then, set up the trust so that it just passes along to your children, and so on. Your descendents will have use of the house forever, basically, but won't be able to sell it. In the process, make sure there's enough money in the trust to pay the taxes for at least the foreseeable future.
What do you think? I can't afford to do this kind of thing, but then, I rent an apartment and I'm into the whole "once I'm gone the world will forget I was ever here" thing. I find my complete irrelevance to the universe to be entirely invigorating.
Assembly is a bad analogy. I think that it's much more fun to program in C++ than in assembly, and it offers just as much room for artistry. The thing is, once upon a time tools were primitive (e.g. assembly, no offence intended) and now they are already mature. New innovations won't be about changing the way in which an instruction is specified (other than syntax changes as new languages get invented) but rather, in the provision of prebuilt tools and widgets. So, our future really isn't like our past. The next tool will not be to Java as Java is to assembly. Instead, the next tool will be more like a 4GL which provides a huge library of prewritten Java code, with a code-builder which assembles the solution for you. At that stage, you're not even programming, really -- you're just configuring makefiles (in whatever weird, futuristic way this is done).
And like I was saying, there will still be people who can roll raw code. The evolution to structured and OOP has already taken place. Programming per se isn't going to change much anymore.
Valid points all, but I still disagree with your pessimism about the future of programming. You seem to be confusing "economically successful or widely popular" with "fun to work on". It may be true that the most "vibrant" open source projects are the ones that compete successfully with commercial products, but most of the thousands or tens of thousands of open source projects in the world were just written for kicks, and don't compete with anything. They just *are*. Get away from the idea that the proper motivation of a programmer is money or fame. That fork in the road leads to a lot of disappointment. Take the road less travelled by, and program for the hell of it. You'll be happier.
Listen: why should I care if my project is "competitive"? All I care about is if it works, it's relatively elegant and bug-free, and I enjoy working on it. When I want money, I go to work and build systems for my boss, ok? I do the fun stuff on my free time.
When you say there's "no fun way to program such a beast" you should take a step back and reconsider the true meaning of what you're saying. If it isn't fun to produce gigantic commercial software, why bother with it? Build something small, quirky and fun for yourself, and share it with your friends. By "Small" I mean a few tens of thousands of lines of code, maybe a couple of hundred thousand if it grows over time. You were talking about trillions. And, you're way too stuck on state of the art. It reminds me of the dot-com egomaniacs I used to work for; everything had to be BIG. Everything had to be a revolution. Ah, those poor saps are going to have a heart attack before they hit 55. They really need to relax.
Commercial programming is dead as a field in this country anyway: everything's getting outsourced, so this is a moot point. What I'm trying to illustrate is that no one can take programming away from you, no matter how many spiffy tools they build. You will always have the freedom to just start cranking away on your own projects. And, this makes the future a nice place to be.
Here's what I think we're going to be seeing in 2013:
Computers: there will still be general purpose computers, because people love them and aren't anywhere near ready to give them up without a knock-down, drag-out fight. But I think the main part of the computer will be extremely compact, and the rest will be very graceful. Right now, several companies are perfecting flexible, foldable LCD screens which will be absolutely everywhere within ten years. So I see desktop machines evolving into a very small, detachable box which can be set into a cradle, with some kind of connection to a large flexible LCD sheet stretched out in some way over a desk. Some of these screens will be very large, I think, because people will want to be able to watch movies on them and companies will pursue that.
Laptops: I think there will always be laptops, because their form factor is so convenient. But they'll be very thin and durable, and will use a modified form of the flexible LCD screen as a display. They might look like a 6-inch by 10-inch wafer, with a frame that can snap open and position a flexible LCD for use. We'll still use keyboards, because keyboards work really well. But they'll be very thin (although the width won't change; human hands are not going to shrink anytime soon).
Hard disks: dead. Gone. I see everything going solid state, with no moving parts. Instead of a hard disk, you'll have the descendants of today's Flash cards.
Combine this with the flexible LCD and you've got a laptop which can survive being thrown like a frisbee. Durable laptops started out as a military technology, with hard drives being shock mounted and LCDs being armored. Now, even the iBook has a shock-mounted hard drive. By 2013, laptops will be pretty hard to break.
PDAs: Pdas and cell phones will converge, of course. It's already happening. Waterproof, shockproof models will emerge with GPS built in. Just about everyone is going to have one, and hardly anyone is going to use land-lines (they'll be considered weird, and quaint).
Everything will be designed to work with a network. Everything will be integrated. I think that most people won't have a separate television and audio system, because everything is going to end up converging into one large, multipurpose device. So you'll have your home system and probably a laptop to carry around, and a combination PDA/Cell phone in your pocket.
I'm kind of looking forward to it, personally. It should be a pretty exciting period to be alive.
Very interesting post, although I still disagree with some of what you're saying ('course, this being slashdot, that's to be expected).
I think your estimate of the 1-5K magic size is too low, especially if you're talking about an OO program. I think the number can be much higher than that. Also, I think your concept of proving the code with something akin to a mathematical proof insinuates an artificial difficulty that is not necessary. Even engineers in physical disciplines don't rely entirely on mathematics. I had a professor back in my Mech. E. days, a really wonderful old guy whose hobby was working with large equipment. He used to say, you can make all the technical drawings you want, you can do all the math you want, but you really never know anything until you build a prototype and fire it up. The message, of course, is that there is no substitute for empirical testing. Simulation is only good as a proof of concept.
This applies to software engineering just as it does to mechanical. The idea behind software engineering is to apply physical engineering principles to software production, and I'm behind that 100%. But one major principle of physical engineering is, build a prototype and see if it works. TEST, in other words. So, coming up with a mathematical proof "proving" your program is without bugs seems kind of masochistic to me. Verification may be a useful step, but it's pointless to rely upon it solely.
So, moving from this point to my next one, one can become relatively confident that his program has no bugs if he comes up with a detailed testing procedure, and then, takes the time to sit down at the computer and literally try every one of the program's features, and then, try to deliberately crash it in every way he can come up with. Note that most gaming companies hire dozens of people to do exactly this. They bang on the games for days, finding every problem and potential problem, and writing up a big report (which, unfortunately, often gets ignored, but what can you do -- that economic issue again). So, my position is that if you have the patience to do it, you CAN find most (maybe not all -- maybe one or two will surface later) bugs in your software, even if that software is of significant size. And, if a bug or two surfaces later, you can always fix it then -- a software engineer has one advantage over his physical cousins: a recall costs him nothing, just put a patch on a server and let everyone know it's there.
So, I think the main thing we disagree on is how much complexity a human can handle. I'm more optimistic than you on that issue. I think we can handle quite a bit, if we're willing to spend the time to deal with it.
As far as there being room for improvement to software engineering, I concede that point whole heartedly. It's not that I think there's no room to improve; I just don't like the way people come out every month or so with some totally new way of doing things and claim it changes everything and we can ditch all the old ways. It's annoying to me. If something works, and you're doing well with it, why would you discard it for some new fad? It's madness. But I'm a curmudgeon, everyone says so. Only 32 and already a curmudgeon, saying things like "you kids today!" and "why, when I was your age we had to turn a crank to get the hard disk rotating..." God, it's a curse. Heh heh...
Now, about the future, I think you're right about how commercial development is going to be done, with a couple of caveats. First of all, I agree that the vast majority of programmers are basically going to be assembling components, using something like an advanced 4GL. Heck, it's already happening today. But I don't think that will be the end of traditional programming. First of all, someone will have to write the components. Sounds like a business opportunity to me. Second, there will always be academia, where pure research isn't going to involve gluing controls together on a form. Third, don't write off the open source community, which is motivated by the fun of
I'll surrender the point on videogames. It was a bad example. The only good estimate I could find about lines of code for games was for Quake II, which looked like it came in around 70,000 lines of code. So... You got me there.;)
On the other hand, your example of Linux being 30,000,000 lines of code is bad too. The biggest piece of Linux (which is made up of thousands of discrete projects, rather than being one giant project) is the kernel, at between 5 and 6 million lines of code. And, the first kernel was written by Linus Torvalds as a solo project. People love to brag about lines of code, but really it's just another statistic. You know... "There are lies, damn lies, and statistics" (Mark Twain).
But, that aside, I think you're seriously underestimating the number of lines of code one person can understand. Let me explain. You're stuck on the idea that one person can only understand 1,000 lines of code. Where the heck did you get that figure? I've got software projects I'm working on here that aren't that hard for me to follow, and they're pushing 8 or 9 thousand lines. I think I cut one down to 6,000 by removing image support (the person I'm writing it for only needed text). Hell, I just wrote a dll that contains around 2,000 lines, and it only took me a couple of days. 1,000 lines of code is an undergrad assignment, ok? So let's get away from that figure.
If you really want convincing, think about this: when ID software released the Quake II source code, lots of people downloaded it and started studying it. Now, that's probably 70,000 lines of code. And, people were able to understand it and work with it. If what you're saying is true, that ought to be impossible, right? But clearly it isn't impossible at all. How can we reconcile this with our current conversation?
If you look at the source download for Quake II, it's broken up into over 300 files, the largest of which is 4200 lines of code. Herein lies the secret.
It may be true that no one can understand any one piece of code that exceeds around 10,000 lines. HOWEVER, when you break that code up into functional chunks, suddenly far larger amounts of code are comprehensible. The largest file in the Quake II download was 4200 lines. Most were less than half that. So, if you were methodical, you could gain a decent understanding of the source code by reading, and taking notes on, individual files one at a time. As you gain understanding of each file, you document it until you end up with an understanding of the full project. Because of the modular way in which it is built, you don't have to have the whole thing in your head at one time. You concentrate on the subsystem you're working on. Follow? Ok.
Now, this is exactly why Object Oriented Programming was invented. Joe Programmer doesn't have to keep all 30K lines of code he's working on in his head at one time. He only has to worry about his individual object, provided he doesn't change its interface without looking up all the other objects that need it so he knows what else needs to change.
OOP, Components, and so on were all invented to solve exactly this problem. And, software engineering tries to codify an approach to designing your project so that all of the small chunks are manageable and can be assembled into a greater whole later. So one man can build twenty 4KLOC chunks of code and end up with an 80KLOC chunk of code that he can completely understand.
Will there be bugs? Of course. I'm not saying there won't be. That's what peer review is for. But, a little software engineering, a little OOP, and you can build some pretty big beasts in your free time. There's probably some kind of functional limit to what one man can do, even with OOP. Figure, 10KLOC per class file, max, a hundred classes... That's a million lines. It's doable.
So I don't think your idea that you can't write a bug-free big program really washes. Eventually, you CAN probably work all the bugs out, but you have to have more patience than you'll find i
Actually I've heard that the limit of what one person can reasonably be expected to maintain is 10,000 lines of code, and that's using object oriented programming. I've read articles online by people who have maintained code of that size, so I'm assuming that it's doable. And, I've seen many truly large programs that are relatively bug-free; look at the commercial game industry. Those projects are huge, and written by teams. Sure, they have bugs, but most games work pretty well by the time you end up playing them. So I disagree with your criticism about complexity.
I don't think the quality of a program drops automatically based on size; I think it depends on the organization that is doing the programming. Many companies don't really follow software engineering principles. One person mentioned "death marches", which apparently is a pretty common phenomenon. The book sure made it seem common enough. Consider: if you don't build at least some kind of initial design *and follow it* you end up continuously grafting on new pieces over time. You just can't take that approach without causing problems.
I can't disagree with your comment about scheduling, though. NO ONE I've EVER MET has had that one licked. I don't think the construction analogy holds up, though. Writing software is a very slippery endeavour, dependent not only on knowledge but on inspiration as well. Recently one person I know worked on a problem for a few days, then asked someone else to look at it -- and the second person solved it in thirty minutes. There's no linear way to predict how long something is going to take a given person. I don't think it's fair to consider this a problem with software engineering per se.
Ah... Don't take the comment about the ivy-leaguer personally. It related to an unpleasant experience I had with one once, although I enjoyed the end, where the ivy leaguer crashed and burned (don't worry about him, he bounced back, slightly more humble).
As to your point about your work experience, wow, you're pretty bitter. Where have you been working, so we can avoid it? See, this is why I stick to civil service and government jobs these days. No death marches, no weirdo bullshit to put up with, just normal, software engineering projects that are managed sanely. Although, I do wish our users would provide us with more details in spec, but I suspect that everyone has that problem.
As far as your comment about people getting set in their ways and never changing, I haven't experienced that. Some of our senior developers are already building.Net projects (with C#, which they said they had no trouble learning). I think the youngest guy in that group is in his early forties.
See, you can work with new tools, learn new languages, discover new ways of doing things, without giving up basic software engineering principles. Think about it like this: a physicist doesn't stop using the Scientific Method when a new piece of laboratory equipment is invented, does he? No, of course not.
So, why give up programming and project design methods which have been proven to work? They're analogous to the scientific method. Use the new equipment, but don't drop the intellectual framework of your field of study.
Again, don't take my opinion personally. It IS, after all, just an opinion.
"Ah! Permit me to retort!" (Now, if only I had the Samuel Jackson look down pat, it would be perfect).
Yes, I am a curmudgeon. And, I am very jaded, from working with some of the very ding-bats I complained about. But, you're off the mark on some of your points, and I'd like to mention why I think this is true.
First of all, TRUE software engineering works just fine. That is, if you have a team which is committed to the basic principles involved, i.e. design your solution first, unit test everything, use a rational testing process, document everything well... You will likely end up with a solid project. The PROBLEM is, hardly ANYONE actually follows the principles of software engineering!!!
Companies care only about the bottom line, ok? Even Microsoft has come right out and said that fixing all the bugs in a given piece of software doesn't really matter, because most of the phone calls they receive aren't about bugs, but desired features (I'm not sure if I buy their reasoning, but some MS flack said it recently). If you pay attention to most of the things people are writing on the web about their programming practices, and if you read the articles that are being posted to programming-related magazines, AND you read between the lines a little, You'll see that they're not talking about software engineering, they're talking about hacking things together with small teams (what do you think XP is all about?).
I can't speak for everyone, but in the time I spent in private companies, this seemed to be what was going on:
1. Some manager comes up with a new Thing (tm) that they want to add to a piece of software, or maybe a new Thing (tm) that is its own tool.
2. Some developer or small group of developers is handed a "sort of" spec to follow and told "go for it, I need it by XXX".
3. The developers basically just go ahead and hack it together, figuring they'll document everything later, when they're done. Since companies are trying to penny-pinch these days, half or more of the developers are likely to be contractors, and it's likely that many will have no advanced training in computer science (hence my comment about six-month wonders).
4. After some short period of time, the Thing (tm) is presented to management. It works, because the developers have figured out a small set of test data which ought to work okay for the demo. Everyone is happy, there's lots of back-slapping, etc.
5. So, now, the managers who were at the meeting all start scheming to put their names on the project. So each one comes up with some hair-brained Thingy (tm) which they can insist the programmers include.
6. The programmers bitch about it, but they can't win, so they graft in a half-dozen Thingys (tm) and they get the project to work. Sort of. There's another demo, and more back-slapping. There may be sushi, but only for the managers. The programmers are given a dry bagel, a packet of imitation cream cheese, and a plastic knife. They go back to their cubicles and play hockey with the bagel, use the cream cheese to glue up a poster, and put the knife in their desk drawer for later.
7. Ok, now the managers are pissed because all the other managers had the same idea and everyone has their own Thingy (tm). So a round of backstabbing begins, with managers claiming that their Thingy (tm) is better than the other Thingy (tm) and that this or that Thingy (tm) should be left out because it's "not robust enough yet". This goes on for a few days, until a new list of approved and disapproved Thingy's (tm) gets sent back to the original project manager, who is now no longer the project manager but rather a gofer for the higher manager who's "taken a leadership role" in the project to puff up his resume.
8. The programmers all try to kill themselves with the plastic knives, then give up and read Slashdot for two hours while they stew about the situation. Eventually they simmer down and a round of grafting and featurectomies takes place. The programmers work late, curse th
I'm glad too. I like meeting smart people; I don't meet enough in private life. And, it was a pretty lively debate, wasn't it? I haven't had one that good for a long time.;)
...are like $#@holes. Everyone has one, and they all stink. So I agree with this critique.
I'd like to add my two cents, so here it is:
Every year or so, some wingnut comes out with a "brand new paradigm" of software development, which is supposed to totally shake up all established practices and change the world overnight. And, it's all hogwash, but inexperienced programmers and the wannabes who take the six-month-special course in a back alley in NYC hoping to make it big in "Computers" all jump on the bandwagon and make life miserable for the rest of us. I've been programming in one language or another since 1991 (although I've been using computers since 1983 or 4); I started studying it formally in 1995, and I've been working full time as a programmer since 1998. And, in all that time I have never seen anything come out that does a better job than plain, old software engineering.
You know what I think?
I think that in this age of "bigger, better, faster, more" people who can't make a name for themselves by building/doing something USEFUL try instead to become "visionaries". So they pull some weird new way of programming out of their asses, serve it up to us like it's filet mignon, and sell books about how to change everything you're doing yet again. This constant change prevents companies from building stable software. How can you work all the bugs out of anything, when every five minutes you're changing all your processes? As if the huge amount of turnover, outsourcing, and downsizing doesn't make long-term software development hard enough.
The worst thing is, managers assigned to IT teams frequently don't know enough about software engineering to understand the difference between one paradigm and the next. So they end up running willy-nilly from one to another, changing boats midstream in a doomed, Frogger-like attempt to not get sunk in the next layoff. Any new book that catches the manager's eye mesmerizes him.
Heaven help the gullible manager who ends up with an aggressive little ivy-league grad that wants to make a name for himself. Then the manager's gonna be led by the nose. After all, what does a manager respect more than pedigree? It doesn't matter that the kid's balls haven't even dropped yet, that he has no experience on any real project, that the closest he's come to load balancing is two PCs in his dorm room, serving static web pages to one user who keeps hitting "refresh"...
GOD.
When, oh when, will people learn?
We've already figured out how to manage software projects. We've understood what works and what doesn't for at least a couple of decades. The field is fairly well researched, so there is plenty of material available about software engineering, and all you have to do is go look it up. There's NO NEED to keep trying to change the process.
Slashdot Mirror
Chazmyrr said: "Short answer: Don't do it."
Ah, that's heartless, dude. Think about your poor parents, complete noobs who can barely turn the computer on, literally suffering because they can't access the internet! I mean, God, without the internet all they have left is cable TV and the newspaper. How would YOU feel if you had to watch TV to get your info? God... What a fate (shudder).
I understand the impulse to run screaming, but you have to take pity on your parents and help them out. Remember what THEY had to put up with: first, a couple of years of changing your toxic diapers, then ten years of your psychotic, animal-tormenting childhood, then your demented, sex-fiend puberty, the college phase in which you wanted to be an anarchist and almost got thrown bodily from your chemistry class, your goth phase and all those animal sacrifices... Hell, with all they put up with, what's a little tech support?
Help them, man. They DESERVE it!
Plain vanilla glass is a poor solution because it can be very easily broken. once glass is broken, water gets into the house and rapidly decomposes it (look at any number of old, abandoned homes and you'll see what I mean).
Plexiglass may yellow, but it is very difficult to damage (I had suggested a 1 inch thickness, which is bulletproof). Thus, it is a better solution to the problem (building a home that can last for centuries) than plain vanilla glass. One might also point out that even if plexiglass yellows, it will still keep out the water that leads to a home rotting from within.
As far as better solutions go, perhaps a thick, laminated tempered glass would work. It would probably be significantly more expensive though.
Yes, but you fail to make any useful countersuggestion so your criticism doesn't really take us anywhere, does it?
I didn't say bug densities would drop. ;)
I think the reason companies will keep pushing for a more componentized future is economic. They're already outsourcing all the programming jobs (well, they're outsourcing everything else too) so once all programmers are as inexpensive as possible, to make them even cheaper they'll have to simplify development. That's all there is to it, I think. I don't think companies care about bugs particularly, unless the bug actually impacts sales.
So, basically I think it's about eliminating labor. But, I'll still be programming, even if it's in my bedroom.
alanak said:
;)
"> I find my complete irrelevance to the universe to
>be entirely invigorating.
That's funny, because most people despair to be in such a situation."
Really? Why?
I've always thought it was kind of liberating that no matter what I do, accomplish, or fail to accomplish, in a hundred years no one will even remember that I ever existed. Oh, I suppose that if I decide to have kids, my great grandchildren might remember me in some way, if only as an old, yellowing picture in a dusty book. But other than that, I am completely confident that everything about me will fade into dust just as my physical body will, and that ultimately, nothing that happens in this life matters even a little bit.
This is a Good Thing. It means we're truly free to live our lives the way we want to. Our ultimate, inevitable, and total obscurity is a blessing you're underestimating.
BTW: it is true that SOME people attain fame, or infamy, and are remembered for hundreds of years. But, there's a flip side to this. Future historians, trying to flog their new book, may entirely misinterperet everything you do, misquote you, make you look like a total knob... Even if your future PR is generally GOOD, there will still be some people who try to discredit you for no better reason than that it burns their ass that you're known and they're not. So my thinking is, it's more relaxing to be a complete unknown than to be known. At least, you don't have to worry about someone making an ass out of you posthumously.
Depleted uranium? What aisle of home depot is that on? It sounds expensive...
Hang on, you missed the whole point of the conversation. Someone asked how he could build a house that would last *FOREVER*. That's what we're talking about here.
For the reasons you list, I RENT, ok? This is just a theoretical discussion of how to build a house that archeologists will be scratching their heads about in a thousand years or so.
Sheesh, so literal!
The man asked how to make a house that would last for centuries. what's a little yellowing, when you can't break the stuff?
But I see your point. Maybe there's a type of thick, laminated glass we could use?
Well, a tree's root system tends to extend out as far as its branches do, right? So if you gave yourself at least 100 feet between the outer walls of the house and the treeline, you might be ok... Besides, I was thinking of a foundation that was poured as a huge, several-foot-thick slab with everything sitting on top of it, not the 1 foot thick foundation wall type in most American homes. MY foundation would be a huge, solid brick. I don't think the roots would affect it all that badly.
Wow... You sure like water.
Actually, that's a little wetter than I had in mind.
One idea I had for creating a roof slab was, dig a hole in the ground in exactly the dimensions the roof slab will take (or in multiple sections if one section gets too heavy for a crane to lift), dig the hole six inches deep, pour the first inch, then set the reinforcing rods and pour the rest, setting rings in the soft cement so that you can hoist it into position. Then, hire a crane once you've got all your pieces molded, and hoist them into place, fixing them permanantly one at a time.
I'd probably arrange the interior walls so that I could have the roof slabs lay across them, supported by the walls. They could be pinned and mortared into place with rebar and concrete.
I like your idea about using concrete for the angled part of the roof... So, you could theoretically have the interior walls' tops angle, which would let the roof angle and water wouldn't accumulate. If you put one of those snow kits on the outer part of the roof, you wouldn't have as much snow accumulation, either. They sell them here in NY. Basically, they're metal cladding with vertical fins; the snow starts to melt and then slides off the roof because it won't stick to the metal.
Several people have mentioned the clouding of Lexan; one said plexiglass works a lot better. But I like your idea best, use a glass outer pane to protect the lexan from weathering and the Lexan for strength.
Building what amounts to a modernized castle has always been a fantasy of mine. Ijust want a small one, maybe the size of a four bedroom cape. I'll never afford one, but hey, it's fun to dream.
Pretty good ideas! Tudor architecture's pretty cool, btw: I've always thought it looked great. And, I love the idea of spiking the interior wood surfaces! Hilarous! I can see a future philistine working now:
"HONEY! Bring me the Sawz-all, I'm going to cut down all this ugly oak..."
(WHIRRRRRR..... ZZZZZZZZZZZZZ.... PING! SNAP!!!)
"HONEY! Call Dr. Forrester, would you? I seem to have had a mishap! Oh! And, bring me a bowl of ice and a quadruple martini, would you?"
Windows that won't open??? Nah, you can make the frame out of steel, coat it with a polycarbonate based paint, and have nice windows that swing open like french doors. They'd be easy to secure, too, just latch 'em in the middle. The polycarbonate would keep the steel from rusting.
Of course, MY preference would be along the lines of the old "arrow-slit" model, with the plexiglass fused to the stone all the way around. But, then, they don't call me "crazy" for nothing.
BTW: I do indeed have aesthetics. They're just not yours. It takes all kinds, remember...
Well, if you're going to spend all the time it would take to build the castle I described, you'd probably want to take the time to make it beautiful, by using marble tiles in the floor, and granite stone tiles for the walls... You could probably achieve any of the following looks without too much trouble:
1. Medieval castle (marble and granite tile, lots of iron fixtures, etc)
2. High-tech futuristic (keep inner surfaces smooth and clean, paint them bright cadmium white and use all steel and chrome fittings for everything, deco furniture, etc)
3. James-Bond type secret lair: Similar to number 2, but dimmer lighting and more "evil".
4. Rustic: Use lots of aged, polycarbonate-treated oak for the interior, granite rocks for wall covering (log-cabin style), lots of animal skins and trophies around.
You can have a pretty amazing pad if you've got the bread for it (sadly, I do not, but now you know what I'd go for if I did -- number 3!!!).
-Phil
Step 1: use stone and concrete. The Romans used stone and concrete extensively, and many of their public works projects are STILL standing two thousand years later. Today we have reinforced concrete, which is even stronger than anything the Romans had. Also, this will make it prohibitively expensive to tear your house down if anyone gets any bright ideas about turning your property into a parking lot in a hundred years.
Step 2: Use concrete for interior walls, floors, well, basically everything. What's the first thing to go in old houses? The roof. And, when it does, water gets into the house and the whole structure rots. A concrete roof will keep water out, which is the most important thing if you want the house to last.
Step 3: Don't use glass for the windows. You can get a 4x8 sheet of inch-thick lexan or plexiglass, which is bulletproof by the way, for 175 bucks down on Canal Street in NYC. It's an extremely resilient material.
Step 4: Don't build the electric and etc into the walls. Design the house so that everything is retrofit, i.e. bolted onto the surface. That way you can always strip it out and replace it later. Note that you can't do this with plumbing, but no plan is perfect. Go for PVC pipes there; at least they won't rust.
Step 5: Paint EVERYTHING with a polymer-based paint to waterproof it.
Step 6: make sure the house sits at the base (or top) of a cliff or some other construction-inconvenient location. Then plant LOTS of oak trees all over the place. Within fifty years they'll turn into a nice forest. This has a couple of benefits:
A) if anyone tries to build on your property, the tree huggers will come out and Hayduke their machinery. They'll also spike the trees, which makes it reeeeeeeally tough to chainsaw them down safely.
B) Even if the local town board figures out how to get around the environmentalists, it'll cost 'em a fortune to knock down all those trees and make room for a wrecking crane to go for the house. They'll give up and go somewhere else.
Step 7: Cultivate the area around the house into a wetland, then make sure every environmentalist in the area is aware that it's there. Then, get the EPA in to declare it a wetland. This is way easier than you might think. It makes it just about impossible for anyone to build anything there ever again.
STEP 8, the MOST IMPORTANT STEP: Put the whole property into some kind of legal trust, so that you don't even really own it anymore and no one can sue you for it. Then, set up the trust so that it just passes along to your children, and so on. Your descendents will have use of the house forever, basically, but won't be able to sell it. In the process, make sure there's enough money in the trust to pay the taxes for at least the foreseeable future.
What do you think? I can't afford to do this kind of thing, but then, I rent an apartment and I'm into the whole "once I'm gone the world will forget I was ever here" thing. I find my complete irrelevance to the universe to be entirely invigorating.
Assembly is a bad analogy. I think that it's much more fun to program in C++ than in assembly, and it offers just as much room for artistry. The thing is, once upon a time tools were primitive (e.g. assembly, no offence intended) and now they are already mature. New innovations won't be about changing the way in which an instruction is specified (other than syntax changes as new languages get invented) but rather, in the provision of prebuilt tools and widgets. So, our future really isn't like our past. The next tool will not be to Java as Java is to assembly. Instead, the next tool will be more like a 4GL which provides a huge library of prewritten Java code, with a code-builder which assembles the solution for you. At that stage, you're not even programming, really -- you're just configuring makefiles (in whatever weird, futuristic way this is done).
And like I was saying, there will still be people who can roll raw code. The evolution to structured and OOP has already taken place. Programming per se isn't going to change much anymore.
Valid points all, but I still disagree with your pessimism about the future of programming. You seem to be confusing "economically successful or widely popular" with "fun to work on". It may be true that the most "vibrant" open source projects are the ones that compete successfully with commercial products, but most of the thousands or tens of thousands of open source projects in the world were just written for kicks, and don't compete with anything. They just *are*. Get away from the idea that the proper motivation of a programmer is money or fame. That fork in the road leads to a lot of disappointment. Take the road less travelled by, and program for the hell of it. You'll be happier.
Listen: why should I care if my project is "competitive"? All I care about is if it works, it's relatively elegant and bug-free, and I enjoy working on it. When I want money, I go to work and build systems for my boss, ok? I do the fun stuff on my free time.
When you say there's "no fun way to program such a beast" you should take a step back and reconsider the true meaning of what you're saying. If it isn't fun to produce gigantic commercial software, why bother with it? Build something small, quirky and fun for yourself, and share it with your friends. By "Small" I mean a few tens of thousands of lines of code, maybe a couple of hundred thousand if it grows over time. You were talking about trillions. And, you're way too stuck on state of the art. It reminds me of the dot-com egomaniacs I used to work for; everything had to be BIG. Everything had to be a revolution. Ah, those poor saps are going to have a heart attack before they hit 55. They really need to relax.
Commercial programming is dead as a field in this country anyway: everything's getting outsourced, so this is a moot point. What I'm trying to illustrate is that no one can take programming away from you, no matter how many spiffy tools they build. You will always have the freedom to just start cranking away on your own projects. And, this makes the future a nice place to be.
Here's what I think we're going to be seeing in 2013:
Computers: there will still be general purpose computers, because people love them and aren't anywhere near ready to give them up without a knock-down, drag-out fight. But I think the main part of the computer will be extremely compact, and the rest will be very graceful. Right now, several companies are perfecting flexible, foldable LCD screens which will be absolutely everywhere within ten years. So I see desktop machines evolving into a very small, detachable box which can be set into a cradle, with some kind of connection to a large flexible LCD sheet stretched out in some way over a desk. Some of these screens will be very large, I think, because people will want to be able to watch movies on them and companies will pursue that.
Laptops: I think there will always be laptops, because their form factor is so convenient. But they'll be very thin and durable, and will use a modified form of the flexible LCD screen as a display. They might look like a 6-inch by 10-inch wafer, with a frame that can snap open and position a flexible LCD for use. We'll still use keyboards, because keyboards work really well. But they'll be very thin (although the width won't change; human hands are not going to shrink anytime soon).
Hard disks: dead. Gone. I see everything going solid state, with no moving parts. Instead of a hard disk, you'll have the descendants of today's Flash cards.
Combine this with the flexible LCD and you've got a laptop which can survive being thrown like a frisbee. Durable laptops started out as a military technology, with hard drives being shock mounted and LCDs being armored. Now, even the iBook has a shock-mounted hard drive. By 2013, laptops will be pretty hard to break.
PDAs: Pdas and cell phones will converge, of course. It's already happening. Waterproof, shockproof models will emerge with GPS built in. Just about everyone is going to have one, and hardly anyone is going to use land-lines (they'll be considered weird, and quaint).
Everything will be designed to work with a network. Everything will be integrated. I think that most people won't have a separate television and audio system, because everything is going to end up converging into one large, multipurpose device. So you'll have your home system and probably a laptop to carry around, and a combination PDA/Cell phone in your pocket.
I'm kind of looking forward to it, personally. It should be a pretty exciting period to be alive.
Very interesting post, although I still disagree with some of what you're saying ('course, this being slashdot, that's to be expected).
I think your estimate of the 1-5K magic size is too low, especially if you're talking about an OO program. I think the number can be much higher than that. Also, I think your concept of proving the code with something akin to a mathematical proof insinuates an artificial difficulty that is not necessary. Even engineers in physical disciplines don't rely entirely on mathematics. I had a professor back in my Mech. E. days, a really wonderful old guy whose hobby was working with large equipment. He used to say, you can make all the technical drawings you want, you can do all the math you want, but you really never know anything until you build a prototype and fire it up. The message, of course, is that there is no substitute for empirical testing. Simulation is only good as a proof of concept.
This applies to software engineering just as it does to mechanical. The idea behind software engineering is to apply physical engineering principles to software production, and I'm behind that 100%. But one major principle of physical engineering is, build a prototype and see if it works. TEST, in other words. So, coming up with a mathematical proof "proving" your program is without bugs seems kind of masochistic to me. Verification may be a useful step, but it's pointless to rely upon it solely.
So, moving from this point to my next one, one can become relatively confident that his program has no bugs if he comes up with a detailed testing procedure, and then, takes the time to sit down at the computer and literally try every one of the program's features, and then, try to deliberately crash it in every way he can come up with. Note that most gaming companies hire dozens of people to do exactly this. They bang on the games for days, finding every problem and potential problem, and writing up a big report (which, unfortunately, often gets ignored, but what can you do -- that economic issue again). So, my position is that if you have the patience to do it, you CAN find most (maybe not all -- maybe one or two will surface later) bugs in your software, even if that software is of significant size. And, if a bug or two surfaces later, you can always fix it then -- a software engineer has one advantage over his physical cousins: a recall costs him nothing, just put a patch on a server and let everyone know it's there.
So, I think the main thing we disagree on is how much complexity a human can handle. I'm more optimistic than you on that issue. I think we can handle quite a bit, if we're willing to spend the time to deal with it.
As far as there being room for improvement to software engineering, I concede that point whole heartedly. It's not that I think there's no room to improve; I just don't like the way people come out every month or so with some totally new way of doing things and claim it changes everything and we can ditch all the old ways. It's annoying to me. If something works, and you're doing well with it, why would you discard it for some new fad? It's madness. But I'm a curmudgeon, everyone says so. Only 32 and already a curmudgeon, saying things like "you kids today!" and "why, when I was your age we had to turn a crank to get the hard disk rotating..." God, it's a curse. Heh heh...
Now, about the future, I think you're right about how commercial development is going to be done, with a couple of caveats. First of all, I agree that the vast majority of programmers are basically going to be assembling components, using something like an advanced 4GL. Heck, it's already happening today. But I don't think that will be the end of traditional programming. First of all, someone will have to write the components. Sounds like a business opportunity to me. Second, there will always be academia, where pure research isn't going to involve gluing controls together on a form. Third, don't write off the open source community, which is motivated by the fun of
I'll surrender the point on videogames. It was a bad example. The only good estimate I could find about lines of code for games was for Quake II, which looked like it came in around 70,000 lines of code. So... You got me there. ;)
On the other hand, your example of Linux being 30,000,000 lines of code is bad too. The biggest piece of Linux (which is made up of thousands of discrete projects, rather than being one giant project) is the kernel, at between 5 and 6 million lines of code. And, the first kernel was written by Linus Torvalds as a solo project. People love to brag about lines of code, but really it's just another statistic. You know... "There are lies, damn lies, and statistics" (Mark Twain).
But, that aside, I think you're seriously underestimating the number of lines of code one person can understand. Let me explain. You're stuck on the idea that one person can only understand 1,000 lines of code. Where the heck did you get that figure? I've got software projects I'm working on here that aren't that hard for me to follow, and they're pushing 8 or 9 thousand lines. I think I cut one down to 6,000 by removing image support (the person I'm writing it for only needed text). Hell, I just wrote a dll that contains around 2,000 lines, and it only took me a couple of days. 1,000 lines of code is an undergrad assignment, ok? So let's get away from that figure.
If you really want convincing, think about this: when ID software released the Quake II source code, lots of people downloaded it and started studying it. Now, that's probably 70,000 lines of code. And, people were able to understand it and work with it. If what you're saying is true, that ought to be impossible, right? But clearly it isn't impossible at all. How can we reconcile this with our current conversation?
If you look at the source download for Quake II, it's broken up into over 300 files, the largest of which is 4200 lines of code. Herein lies the secret.
It may be true that no one can understand any one piece of code that exceeds around 10,000 lines. HOWEVER, when you break that code up into functional chunks, suddenly far larger amounts of code are comprehensible. The largest file in the Quake II download was 4200 lines. Most were less than half that. So, if you were methodical, you could gain a decent understanding of the source code by reading, and taking notes on, individual files one at a time. As you gain understanding of each file, you document it until you end up with an understanding of the full project. Because of the modular way in which it is built, you don't have to have the whole thing in your head at one time. You concentrate on the subsystem you're working on. Follow? Ok.
Now, this is exactly why Object Oriented Programming was invented. Joe Programmer doesn't have to keep all 30K lines of code he's working on in his head at one time. He only has to worry about his individual object, provided he doesn't change its interface without looking up all the other objects that need it so he knows what else needs to change.
OOP, Components, and so on were all invented to solve exactly this problem. And, software engineering tries to codify an approach to designing your project so that all of the small chunks are manageable and can be assembled into a greater whole later. So one man can build twenty 4KLOC chunks of code and end up with an 80KLOC chunk of code that he can completely understand.
Will there be bugs? Of course. I'm not saying there won't be. That's what peer review is for. But, a little software engineering, a little OOP, and you can build some pretty big beasts in your free time. There's probably some kind of functional limit to what one man can do, even with OOP. Figure, 10KLOC per class file, max, a hundred classes... That's a million lines. It's doable.
So I don't think your idea that you can't write a bug-free big program really washes. Eventually, you CAN probably work all the bugs out, but you have to have more patience than you'll find i
Actually I've heard that the limit of what one person can reasonably be expected to maintain is 10,000 lines of code, and that's using object oriented programming. I've read articles online by people who have maintained code of that size, so I'm assuming that it's doable. And, I've seen many truly large programs that are relatively bug-free; look at the commercial game industry. Those projects are huge, and written by teams. Sure, they have bugs, but most games work pretty well by the time you end up playing them. So I disagree with your criticism about complexity.
I don't think the quality of a program drops automatically based on size; I think it depends on the organization that is doing the programming. Many companies don't really follow software engineering principles. One person mentioned "death marches", which apparently is a pretty common phenomenon. The book sure made it seem common enough. Consider: if you don't build at least some kind of initial design *and follow it* you end up continuously grafting on new pieces over time. You just can't take that approach without causing problems.
I can't disagree with your comment about scheduling, though. NO ONE I've EVER MET has had that one licked. I don't think the construction analogy holds up, though. Writing software is a very slippery endeavour, dependent not only on knowledge but on inspiration as well. Recently one person I know worked on a problem for a few days, then asked someone else to look at it -- and the second person solved it in thirty minutes. There's no linear way to predict how long something is going to take a given person. I don't think it's fair to consider this a problem with software engineering per se.
Ah... Don't take the comment about the ivy-leaguer personally. It related to an unpleasant experience I had with one once, although I enjoyed the end, where the ivy leaguer crashed and burned (don't worry about him, he bounced back, slightly more humble).
.Net projects (with C#, which they said they had no trouble learning). I think the youngest guy in that group is in his early forties.
As to your point about your work experience, wow, you're pretty bitter. Where have you been working, so we can avoid it? See, this is why I stick to civil service and government jobs these days. No death marches, no weirdo bullshit to put up with, just normal, software engineering projects that are managed sanely. Although, I do wish our users would provide us with more details in spec, but I suspect that everyone has that problem.
As far as your comment about people getting set in their ways and never changing, I haven't experienced that. Some of our senior developers are already building
See, you can work with new tools, learn new languages, discover new ways of doing things, without giving up basic software engineering principles. Think about it like this: a physicist doesn't stop using the Scientific Method when a new piece of laboratory equipment is invented, does he? No, of course not.
So, why give up programming and project design methods which have been proven to work? They're analogous to the scientific method. Use the new equipment, but don't drop the intellectual framework of your field of study.
Again, don't take my opinion personally. It IS, after all, just an opinion.
"Ah! Permit me to retort!" (Now, if only I had the Samuel Jackson look down pat, it would be perfect).
Yes, I am a curmudgeon. And, I am very jaded, from working with some of the very ding-bats I complained about. But, you're off the mark on some of your points, and I'd like to mention why I think this is true.
First of all, TRUE software engineering works just fine. That is, if you have a team which is committed to the basic principles involved, i.e. design your solution first, unit test everything, use a rational testing process, document everything well... You will likely end up with a solid project. The PROBLEM is, hardly ANYONE actually follows the principles of software engineering!!!
Companies care only about the bottom line, ok? Even Microsoft has come right out and said that fixing all the bugs in a given piece of software doesn't really matter, because most of the phone calls they receive aren't about bugs, but desired features (I'm not sure if I buy their reasoning, but some MS flack said it recently). If you pay attention to most of the things people are writing on the web about their programming practices, and if you read the articles that are being posted to programming-related magazines, AND you read between the lines a little, You'll see that they're not talking about software engineering, they're talking about hacking things together with small teams (what do you think XP is all about?).
I can't speak for everyone, but in the time I spent in private companies, this seemed to be what was going on:
1. Some manager comes up with a new Thing (tm) that they want to add to a piece of software, or maybe a new Thing (tm) that is its own tool.
2. Some developer or small group of developers is handed a "sort of" spec to follow and told "go for it, I need it by XXX".
3. The developers basically just go ahead and hack it together, figuring they'll document everything later, when they're done. Since companies are trying to penny-pinch these days, half or more of the developers are likely to be contractors, and it's likely that many will have no advanced training in computer science (hence my comment about six-month wonders).
4. After some short period of time, the Thing (tm) is presented to management. It works, because the developers have figured out a small set of test data which ought to work okay for the demo. Everyone is happy, there's lots of back-slapping, etc.
5. So, now, the managers who were at the meeting all start scheming to put their names on the project. So each one comes up with some hair-brained Thingy (tm) which they can insist the programmers include.
6. The programmers bitch about it, but they can't win, so they graft in a half-dozen Thingys (tm) and they get the project to work. Sort of. There's another demo, and more back-slapping. There may be sushi, but only for the managers. The programmers are given a dry bagel, a packet of imitation cream cheese, and a plastic knife. They go back to their cubicles and play hockey with the bagel, use the cream cheese to glue up a poster, and put the knife in their desk drawer for later.
7. Ok, now the managers are pissed because all the other managers had the same idea and everyone has their own Thingy (tm). So a round of backstabbing begins, with managers claiming that their Thingy (tm) is better than the other Thingy (tm) and that this or that Thingy (tm) should be left out because it's "not robust enough yet". This goes on for a few days, until a new list of approved and disapproved Thingy's (tm) gets sent back to the original project manager, who is now no longer the project manager but rather a gofer for the higher manager who's "taken a leadership role" in the project to puff up his resume.
8. The programmers all try to kill themselves with the plastic knives, then give up and read Slashdot for two hours while they stew about the situation. Eventually they simmer down and a round of grafting and featurectomies takes place. The programmers work late, curse th
I'm glad too. I like meeting smart people; I don't meet enough in private life. And, it was a pretty lively debate, wasn't it? I haven't had one that good for a long time. ;)
...are like $#@holes. Everyone has one, and they all stink. So I agree with this critique.
I'd like to add my two cents, so here it is:
Every year or so, some wingnut comes out with a "brand new paradigm" of software development, which is supposed to totally shake up all established practices and change the world overnight. And, it's all hogwash, but inexperienced programmers and the wannabes who take the six-month-special course in a back alley in NYC hoping to make it big in "Computers" all jump on the bandwagon and make life miserable for the rest of us. I've been programming in one language or another since 1991 (although I've been using computers since 1983 or 4); I started studying it formally in 1995, and I've been working full time as a programmer since 1998. And, in all that time I have never seen anything come out that does a better job than plain, old software engineering.
You know what I think?
I think that in this age of "bigger, better, faster, more" people who can't make a name for themselves by building/doing something USEFUL try instead to become "visionaries". So they pull some weird new way of programming out of their asses, serve it up to us like it's filet mignon, and sell books about how to change everything you're doing yet again. This constant change prevents companies from building stable software. How can you work all the bugs out of anything, when every five minutes you're changing all your processes? As if the huge amount of turnover, outsourcing, and downsizing doesn't make long-term software development hard enough.
The worst thing is, managers assigned to IT teams frequently don't know enough about software engineering to understand the difference between one paradigm and the next. So they end up running willy-nilly from one to another, changing boats midstream in a doomed, Frogger-like attempt to not get sunk in the next layoff. Any new book that catches the manager's eye mesmerizes him.
Heaven help the gullible manager who ends up with an aggressive little ivy-league grad that wants to make a name for himself. Then the manager's gonna be led by the nose. After all, what does a manager respect more than pedigree? It doesn't matter that the kid's balls haven't even dropped yet, that he has no experience on any real project, that the closest he's come to load balancing is two PCs in his dorm room, serving static web pages to one user who keeps hitting "refresh"...
GOD.
When, oh when, will people learn?
We've already figured out how to manage software projects. We've understood what works and what doesn't for at least a couple of decades. The field is fairly well researched, so there is plenty of material available about software engineering, and all you have to do is go look it up. There's NO NEED to keep trying to change the process.
Feh. Snort.