How silly of them to think that the Linux movement actually wants people other than programmers to use the operating system.
It depends on what you mean by "the Linux movement". Sure, everybody wants lots of users. But very few people are interested in signing up to be the personal slaves of people who don't know a one from a zero and would like to stay that way.
A lot of open-source software gets written under the itch-scratching model. I want software to do X, so I write it until I'm happy, and maybe I write a little more because it's fun. Somebody else who wants X+Y writes the Y. But if no programmer wants X+Y+Z, then Z may never get done, no matter how many non-programmers want it.
This isn't meant to be exlusionary. Quite the opposite: a lot of Zs do get written for fun or out of generosity, and I've never dealt with an open-source developer who wasn't immensely welcoming towards those who wanted to learn enough so that they could contribute.
But by and large, the rule is "patches welcome". If you think "the Linux movement" should have better driver support, then you should start writing drivers or assist somebody who can.
I've yet to see any of us complain about the pop under and other adverts served up along with the ignorant and self rightous article. All forms of advertising on the net represent an abuse of a public resource
Which public resource would that be? The DSL line that I pay for? The privately owned long-haul fiber? The newspaper's servers? The reporter's time? Last I checked, none of those was a public resource. But hey, if you want to make your hardware, bandwidth, time, or money a public resource, be my guest.
The difference between spam and regular advertising is having a choice. You decide whether you want to put ads on your web site. You decide whether you want to visit web sites that fund themselves through advertising (rather than subscription or the generosity of the publishers). But you don't get to decide who gets to spam you.
They NEED to be charged per email sent. How much? Just in the amount of the expected revenue from the spam + 1 dollar. Only that will stop spam alltogether...
You're an optimist. People still fall for the MLM scams in droves, although they never make any money off them. I know people who jump to a different MLM thing every year or two, convinced this one will be the next one. They are perfectly willing to blow money on signs, postage, imprinted pens, and all sorts of other mainly useless marketing expenses; they'll happily keep spamming as well, even if they have to pay.
The only cash-related solution that will likely work is one that I first saw mentioned in Brin's Earth: Each person gets to say how much they must be payed to accept mail from an unfamiliar sender. The custom is then to refund the money if they mail is non-commercial.
The same goes for people who forward their spam to services like SpamCop--you are only clogging the network even more, please stop.
I think you're just trolling, but in case you aren't, here's the difference:
I go to a fair bit of trouble and expense to maintain my networks. I get to decide what happens with it. Spam is a parasitical use of that network, something I don't want. The reporting of spam is one of the things I do want. If I feel that it's clogging my network, I can stop anytime; I can't do that with spam.
Spam is noise on a data channel.
Uh, no. It's not like spam is some weird radio interference problem or some quantum effect. Real humans write and send every spam. They do it because they think they can make money at it.
This is not an inevitable consequence of the existence of a communication channel. Spam was negligible for many years; it wasn't until around the time of September That Never Ended or maybe the green card spam that I recall getting any. Since then it has grown explosively, so that for many people it outweighs regular mail. Ignoring it in hopes that it will go away or level out is about as smart as ignoring a suppurating wound.
Re:True story
on
Pet Bugs?
·
· Score: 3, Interesting
I'd wager that the majority of those who follow the herd and say, "VB is an idiot's language," have never even tried VB.
I've tried VB; I used it by client mandate on a 4-month project. I started with only a slight bias, and ended up hating it with a burning passion. I wouldn't say it's an idiot's language, but I would agree that it makes weaker programmers.
Why? Let's ignore VB for a bit and compare Pascal, Perl, and BASIC.
Pascal is a language made for instruction. It's uptight, a bondage and discipline language, forcing you to program in a way that's pretty orderly. Developers who start with it tend to follow those habits later. Perl is neutral; it will allow you to program in a way that's as fussy as Pascal, but it will also let you write utterly perverse code. BASIC, has a weird set of limitations and freedoms that actively train people in bad habits that they will have to unlearn later.
In my experience, VB isn't as bad as BASIC, but it was pretty close. My major complaint is the complaint I have about a lot of Microsoft stuff: on top of a skeleton of early, rushed design (kept for the sake of backwards compatibility) somebody glued multiple layers of marketing's features d'jour, doing so without any particular appreciation for elegance.
A good programmer could spend some time working in VB and live; if they've had some broad exposure, then then won't learn the bad habits that VB allows and the tolerance for ugliness that VB requires. But somebody whose main experience is VB is another story entirely.
I know of one group of former VB developers who are now Java developers. The whole way through they've worked on a large dynamic website for a major financial institution, which they redid in Java a while back. For the most part the site works, but the code brought me to tears.
In trying to help these people (who were all smart, committed, and nice) the main problem was that 90% of them couldn't tell good design from bad, elegant architecture from tangled, or clear code from obtuse. I blame this directly on their years of working with a language whose designers didn't know the difference either.
No matter how cheap HDs get, they just don't have the [...] lifetime
Really, it depends on what you mean by "lifetime". Even assuming the media is still good, try finding a working drive for an arbitrary backup from a decade or two ago. And longer than that? Forget it. (But it's plausible that CDs will be an exception.)
For moderately long-term storage, your best bet is stone, although some metals are a good choice, too. But really, the only currently successful medium for real long-term storage is DNA. That's not because DNA is durable; it's because Lots Of Copies Keep Stuff Safe.
So the lesson is that if you really want to be able to get at your backups in the future, the best way is to keep them 1) live, 2) distributed, 3) replicated, and 4) monitored. Whether you do that by colocating a couple of hard drive arrays or by encoding the data into bacterial DNA with checksum-linked apoptosis mainly depends on your budget.
As someone once employed to build computers, here's how long it takes [...] Total time to build a system, if done in the above order: A little over 30 minutes. Well under an hour.
Uh, you neglected the three weeks it takes to get a job building computers, plus the couple of months it takes to get pretty good at it.
I remain unconvinced that anyone with just a bit of experience can't economically justify the amount of time it takes to build a computer
Even on Slashdot, I can't imagine that the average person gets a new computer more than every year or two. That just isn't often enough to keep up with the latest; each new computer involves a lot of learning and fiddling.
For me, when I set up new gear I always end up going through several loops where I change the hardware setup, the bios setup, or the driver settings, reboot, and run some tests to see whether I've made things better or worse. And if there's a subtle problem, that can take days of intermittent poking to track down. And if some hardware fails during burn-in, then I have to spend more time putzing around with RMAs, shipping, and billing.
If I buy from a reputable shop that does a lot of Linux boxes, I have some hope that they're already done the research and tuning to make sure that they've shipped me something solid and zippy.
Still, that's no excuse for a geek buying something from a major consumer PC company; that stuff is optimized for which-end-do-plug-in chumps whose peak computing experience comes when that letter in MS Word spills over onto a third page.
If you enter the actual maximum amount you are willing to pay, you would not have to worry about a "sniper"
The maximum people are willing to pay isn't constant; it's variable. For example, if somebody outbids you, you may discover that you are willing to pay more than you thought. Quite a lot of marketing works on this principle.
Whether or not this is a good or wise thing, I dunno, but it's a true thing.
The problem the OP describes usually comes down to a lack of communication between the people doing the work and the people ordering it. Building up trust is a great way to get people to listen to you.
This is also why the various agile methods (XP, Scrum) work well; short-cycle iterative processes force a lot of interaction, and frequent deliveries build confidence on both sides. Allowing features to be reprioritized every iteration gives managers the feeling that they're in full control, which makes them much less likely to demand impossible things.
But I have seen cases where this won't work. In an organization of sufficient size, the high-ups are so isolated from reality that they can only manage by appearances; the people under them can succeed just by creating the appearance of success. All programmers know that it's easy to create the appearance of success for v1.0 while leaving a steaming pile of turds under the hood that will sabotage any attempts at v1.5. Truly evil managers will take this every time and then move on to a higher position, leaving somebody else holding the bag.
I think you may be setting up a bit of false opposition here. I agree that tools are good; I use many of those same tools myself. But when you say
[...]code reviews will NOT catch the most insidious and costly mistakes, such as general architecture design flaws[...]
you go too far. If there's a tool out there that will catch design problems, I've never met it.
Software development is an expression of human desires in languages meant simultaneously for human and machine interpretation. Good tools can help with the machine interpretation side, but only inspection by other humans can catch problems relating to human desires or human interpretation.
Design walkthroughs, code reviews, and pair programming can address problems for which there are as yet no good tools.
Deciding whether to use a code inspection or a profiler depends entirely on nature of the problem causing the poor software quality.
there are two coders on the project (myself and the senior coder)
Do you already review each other's code? If not, try that. Also consider trying pair programming, which gives you a continuous code/design review.
Otherwise, consider hiring an outside contractor to do the code reviews. Or even a couple of them to give you different perspectives.
we're approaching release on our project
This is not the best time to start code reviews. Why? At this point you've written a bunch of code; you're also facing release pressure. The only things most people would be willing to fix at this point are clear bugs that can be fixed without changing the design. Anything else you'll likely be forced to ignore (or hack around).
The earlier you catch a problem, the cheaper it is to solve. In your next design cycle, start code and design reviews early!
But the problem I face at my company is that nothing is fully planned ahead of time [...] Which in turn usually results in bugs. That's what I'd like to avoid. [...] I think the biggest problem is convincing the boss to sit down and fully plan his ideas before asking software to be written for it.
That's one possible solution. If your development process can't handle changing requirements, either you can a) suppress all changes after the first requirements are given, or b) change your development process to handle mutating requirements well.
Both can work, but they have different cost/benefit profiles. You might chat with your boss about how much business value could be gained from reducing time spent in the analysis phase, and adapting more quickly to the business environment. Then you can balance this against the costs of using a more flexible process.
I can do either, but personally I enjoy the flexible approach more. I get so tired of telling users no.
Please note that you are asking a question similar to "Are there any good books that cover the process of living? You know, what it's all about, and particularly what rituals to follow for success?" You are likely to get religious answers to religious questions.
For a good overview of development practices, though, pick up McConnell's Rapid Development. The main thing to come along since then is the various agile processes like XP. For the scoop on that, pick up Extreme Programming Installed. (Don't get Beck's book, Extreme Programming Explained to start with; it's a manifesto, not a practical book.)
As with religion, you should probably ignore the people who claim to have The Answer ("Use UML!" "Use XP!" "The word of the Architect shall be as law, and you verily must smite the coders who stray from it." "Only infidels use COBOL/VB/C++/Java!" "There shall be no editor but Emacs!").
Instead look at it more like home maintenance or martial arts. Is a screwdriver better or worse than a hammer? Is a punch better than a kick? Those questions can be entertaining, but they are never helpful. The right questions are more subtle: "Given the problem I'm facing, what tools might help? How should I adapt them to the situation? And how can I tell when they help rather than hinder?"
This depends a lot on the job and the outside interests. From the hiring side, I like to see people who are doing geek stuff because they love it. Outside projects also let people get experience that they couldn't easily get at work. It also gives a public record for me to examine; I'd certainly browse the code and the CVS history to see how you code and what you've been learning. You get bonus points if a) the project is relevant to the industry or b) if you or the project is prominent enough that we can attract customers or better staff by saying something like, "Yeah, Linus Torvalds is working for us."
On the other hand, if I suspect that your outside projects will prevent you from giving 100% while you're at work, the resume will go right in the shredder. If the job is a particularly intense or demanding one (e.g., a startup), that goes double. The last thing I wanna do is be somebody's daddy/monitor/whip-cracker, making sure they aren't always sneaking off and working on their outside projects.
And now that I think about it, this all applies to any non-work activity, geek or non-geek.
Re:single point of failure
on
Is RPM Doomed?
·
· Score: 1
I agree that/etc is a pain in the ass, but I don't buy that it's just as good as the Windows registry. The registry is easier for programs to manipulate, but etc-style plain text files give much more flexibility and support for arbitrary human-readable metadata (especially through comments, but also through naming, file location, and organization within the file) that the Windows stuff lacks entirely.
The registry strikes me as a typical Windows effort: notice a problem (namely that lots of little text config files are a pain), think about it for between two and five seconds, and then introduce a solution that while better in some narrow sense (namely that the data is now structured). But they don't really appreciate the full power of what they're ripping off, and they don't give any thought to maintainability or future expansion.
And thus it's nearly useless to call most companies for Windows technical support. They might as well replace all of those people with a recording saying "Download the new version. If that doesn't fix your problem, reinstall Windows."
Java has some really cool features, but it is a dumbed-down language aimed at dumb programmers with the effect of keeping potentially smart programmers dumb.*
I do most of my professional work in Java these days, so you'd expect me to disagree. But you're 100% right. Java is a language with most of the sharp edges hidden away between a lotta cushy padding. And generally, I think "Thank god for that," even though I personally find it constraining.
Why? Because half of the programmers out there are below average. (Or, as a mathematician I know reminded me, more than half the programmers are below the mean.) If I'm going to work on somebody else's code, I'd much rather it be in Java. Bad Java is salvageable; bad C or Perl is so impenetrable that you might as well just off yourself. Or, perhaps better, the person who wrote it.
Personally, I like to drive fast cars, the kind of sports car where you can hear the engine's every growl and feel every pebble. The kind where you can turn on a dime and give yourself whiplash by stepping on the gas pedal quickly. But can you imagine the carnage if all cars were like that? For everyday people and everyday uses, minivans are all most people should be allowed to use. Ditto Java. But although minivans and Java keep people safe, they make it impossible to build your skills past a certain point.
Best not to mix economics and toking, though. Instead, try writing device drivers when the paranoia hits; that way you will trap potential errors six ways from Sunday.
Large financial institutions have been doing this for quite a while. The crash of '87 was allegedly made substantially worse by automated trading systems, so much so that the SEC muzzled 'em substantially.
The nice thing about working for financial companies is that they aren't afraid to spend money if they think they can make money. But beware: trading atracts the most prodigious bullshitters and superstious nut-jobs that I've ever seen. If I could get a dollar for everybody who thought they had sure-fire way to beat the market and make millions, I'd make millions.
The end result of an undergraduate CS education should be adability, and the facility to think in whatever language the situation demands.
Yeah, but this is an intro programming class we're talking about. C++ is fine for production code written by professionals, but they don't strike me as great teaching languages.
The point of an intro class is to draw people in, help them to see how cool it is, get them thinking in the right way, and give them some foundation so that they can go on. Tracking down subtle malloc bugs or pointer problems is enough to bring seasoned he-man programmers to tears; I can't imagine what it would do to an unsuspecting liberal arts major.
Personally, I started with BASIC and Pascal. Both are limited languages, but Pascal taught me a lot of good habits that helped me when I got to less anal languages. Without that kind of discipline, something as no-safety-guards as C or more-than-enough-rope-to-hang-yourself as Perl might have killed me dead. Or worse, killed the people who had to maintain my code.
It sounds we agree that unit tests are good but not a sufficent way to achieve high-quality code. We also agree that the key to good development is having skilled developers; processes can support or hinder them, but no ritual can turn dunces into geniuses.
(a) passing unit tests does not give any indication of maintainability
Absolutely. This is what makes understanding biological systems really hard. They don't even have unit tests, just functional tests. All the code (that is, the DNA) changes are random, and as long as the functional tests mostly pass, the product ships. (Personally, I advocate taking all those surplus COBOL programmers and giving them to the human genome project; if they can deal with hopelessly snarled 50 MLOC ERP systems, the should be able to help with all that junk DNA.)
The only thing that guarantees maintainability is maintenance by people who know they will have to keep maintaining the system. Twenty minutes into an XP project, the first unit test should pass. After that, you can think of it as being in maintance mode; unit tests are not allowed to regress, and features are continously added to the existing code base. Only maintainable code can survive this process.
(b) passing all the unit tests, while a good confidence builder, is not an absolute guarantee that requirements have been met and no bugs are lurking.
Also very true. Note that XP also requires functional tests, which are specified by the customer. Unit tests verify that the code does what the developer intended; functional tests verify that the code does what the users want. Pair programming also gives you code reviews and walkthroughs for free. For most projects, that's a high enough level of quality. But if that isn't, the XP gurus will certainly tell you to add other quality control measures, of which there are a plentitude.
Note, though, that you can never guarantee that a non-trivial system has no bugs. Each quality control measure reduces the chance that a bug will be encountered by an end user, but the cost rises exponentially for each bug found, so at some point you just have to ship.
One thing a clear and well-documented design is excellent for is reducing your dependence on the guy who originally wrote the code. OTOH, how does a new guy on the project who wasn't in your original development pair learn his way around? (I'm not saying it can't be done, just that it might be harder without a clearly documented overall design.)
Clear designs certainly increase maintainability. So does clear code. As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." And other XP heavyweights are very big on this too; Ward Cunningham, for example, makes a good case that an OO programmer should always have a thesaurus at hand, so that you can choose the best names for your objects.
But it sounds like you have a misconception about XP; pairs change frequently (generally every few hours), and knowledge is widely distributed among team members. Thus, a newbie just gets thrown into the mix, although you generally try to pair them with your more experienced people until they find their feet. Heck, one shop I know of doesn't do technical interviews anymore; they'll just bring a promising candidate in for an afternoon to pair with a few different people, doing normal work on production code. At the end of the day, both sides know exactly what they're getting into.
Of course if you have really high turnover, a shared-knowledge approach could break down, but that kind of turnover among programmers is a symptom of severe organizational problems that will likely sink any process. And if the project is put on ice and the team is disbanded, the recommended practice is to spend a final iteration tidying up loose ends and writing documentation so that they next team can take over easily.
Yes. In a traditional, design-first environment, you only need one good guy to be responsible for the overall design, and everyone else to follow it and be smart enough to ask questions if something doesn't fit the existing set-up.
This is theroretically true, but it requires iron-fisted control over design changes, and it also requires developers to have enough appreciation for design to know when they are doing it wrong.
Most of the time when I see a formalized architect/coder distinction on a project, it ends up being a) seagull-style, where a theoretician flys in, poops a lot of design on everything, and flys away, leaving the developers to deal with the mess, or b) rebellion in the trenches, where developers know that they can get away with ignoring the architects, so they just do their own thing.
I have seen it work occasionally, but it ends up being in spite of the formal division, rather than because of it.
In an XP-based process, you appear to need one skilled person in every programming pair, a much more demanding requirement. The responsibility has been decentralised, so everyone now shares it and needs to be able to handle that.
I could see how you'd get that idea, but that's now how it should work. As with the other model, the developers need to know when they are in over their heads and then ask for help.
With XP, though, there are a few things to support this. One is that only one of the programmers has to recoginize the trouble and ask the best designer for help. This could either come through a short discussion or through the master just getting swapped into the pair.
Another valuable piece of support is that XP requires frequent pair changes, so a design issue of any substance will get looked at by a variety of people in pretty short order. This doesn't just give you the benefit of many eyes; it also means that design problems are likely to get caught sooner.
Better, XP encourages experimentation and change. With the classic waterfall approach, you are stuck with bad design decisions for a long time. The ability to safely change my design as I go has substantially improved the designs I end up with.
But I think the most important one is common code ownership. Part of a team effort is that each person should make use of their strengths. If you're by far the best designer, then you should be looking out for design problems and fixing them, especially given XP's empahsis on aggressive refactoring. Common code ownership means that you are empowered to change anything that you think is ugly.
I've only ever been involved in a couple of projects that have tried XP seriously and long-term, but both suffered obviously from this particular weakness, hence my reservations that started this subthread.
I'd be intrigued to hear more! In particular, I'd love to know
how big the teams were
how frequently the pairs changed
whether there were any good designers on the project
if so, what prevented them from fixing bad design
if not, why not?
Personally, I used to aspire to be an architect, and I still will occasionally take jobs like that. But I eventually realized that the only way I learned to design well was by writing a lotta code, which made me intimately famliar with the tradeoffs that a good designer had to make. But as soon as I was an ivory-tower architect, mere coding was considered beneath me, which cut me off from the source of my strength. Once that happens, it's easy to spend a lot of time on philosophical bullshit, debating the OO equivalent of angels dancing on pins.
Now, every day I analyze, design, write code, and design some more. I find it much more satisfying.
But i still maintain that it is hard to implement unless your group fully embraces it.
That's very true. But don't give up! It's slow getting people stated with unit tests, but once people have had a little experience with it, they see how helpful it is. Once it catches on a little, the process will snowball.
Some of my favorite tricks:
Run the tests automatically. Use a tool like CruiseControl or Anthill to automatically do builds and run tests. Then if somebody breaks the tests, it's not you who bugs them; it just happens automatically. It also gives managers a window into the state of the project, which they will like a lot.
Generate test coverage numbers. Use an automated tool to figure out the percentage of code covered by your testing suite. Collect this number and make it visible on a pretty graph, so that everybody knows whether test coverage is improving.
Require a unit test for every bug fix. It's hard to keep managers involved in every check-in, but they often track bugs. Get a policy that every fixed bug must have a unit test written before it is fixed. Programmers will often imply that they are too smart or too good to need to write unit tests, but once a bug crops up, that's a harder argument to make.
Whatever people think about XP, good unit tests make for better code and less developer stress. Until I tried XP and test-first, I never really wrote them, but now they make my life so much easier.
And? Perfection is rarely achieved the first time. Indeed, perfection is never achieved; that's one of the big lessons in iterative developent. Bugs always happen, the only question is what to do with them. When a bug is reported, I write a test to expose the bug, then I fix the bug. I may not have all the bugs, but I can be confident that certain problems will never appear.
as anyone who's worked in the field will tell you, testing with blanks is no guarantee it will work with live ammunition.
I will certainly grant that some things are so expensive to test that it's just cheaper to accept the failures that come from not testing. But anybody who's worked in the field can also tell you that if you don't even fire a few blanks, odds are low that it will work with real ammunition.
The level of testing I did at that point was way more than any set of unit tests I've ever seen.
I guess I am not getting your point. You name a lot of other quality control techniques, all of which are good. Does this make unit testing bad? No. For many cirumstances, I find it a much cheaper way to achieve a given level of quality.
The main difference is that non-automated quality control measures are very difficult to repeat cheaply. Moore's law means my unit tests, integration tests, and functional tests get 50% cheaper every 18 months. Code walkthroughs, second opinions, and manual testing track programmer salaries.
I exercised every option and every little setting, which is the most any automated test would do, if you could even write such a test in the first place. [...] You couldn't write automated tests to test the code I was working with. I think that pretty much shoots that argument down in flames before it even starts.
If you can manually test it, you can automate the test. The only question is one of cost. For pure software, the costs should be pretty low.
The problem may be in your testing techniques; retrofitting testing to existing code can be a pain, but doing test-first development is pretty painless and much less expensive then after-the-fact testing.
Some of that code is now used by thousands of clients, hundreds of times a day, and in more than two years since some of those modules went live, we haven't had a single fault report on them.
And what happens when somebody else goes to add a feature to your code? With good unit tests, an average programmer with little knowledge of your modules can make the change without breaking any existing feature. Without them, you're the only fellow who can make the changes cheaply. That's great for you, I guess, but it sucks for your employer and the colleague who gets handed the stuff when you get hit by a bus.
Slashdot Mirror
How silly of them to think that the Linux movement actually wants people other than programmers to use the operating system.
It depends on what you mean by "the Linux movement". Sure, everybody wants lots of users. But very few people are interested in signing up to be the personal slaves of people who don't know a one from a zero and would like to stay that way.
A lot of open-source software gets written under the itch-scratching model. I want software to do X, so I write it until I'm happy, and maybe I write a little more because it's fun. Somebody else who wants X+Y writes the Y. But if no programmer wants X+Y+Z, then Z may never get done, no matter how many non-programmers want it.
This isn't meant to be exlusionary. Quite the opposite: a lot of Zs do get written for fun or out of generosity, and I've never dealt with an open-source developer who wasn't immensely welcoming towards those who wanted to learn enough so that they could contribute.
But by and large, the rule is "patches welcome". If you think "the Linux movement" should have better driver support, then you should start writing drivers or assist somebody who can.
A more accurate name for it is "confirmed opt-in". The point of the confirmation being that it's not clear that you really opted in.
I've yet to see any of us complain about the pop under and other adverts served up along with the ignorant and self rightous article. All forms of advertising on the net represent an abuse of a public resource
Which public resource would that be? The DSL line that I pay for? The privately owned long-haul fiber? The newspaper's servers? The reporter's time? Last I checked, none of those was a public resource. But hey, if you want to make your hardware, bandwidth, time, or money a public resource, be my guest.
The difference between spam and regular advertising is having a choice. You decide whether you want to put ads on your web site. You decide whether you want to visit web sites that fund themselves through advertising (rather than subscription or the generosity of the publishers). But you don't get to decide who gets to spam you.
They NEED to be charged per email sent. How much? Just in the amount of the expected revenue from the spam + 1 dollar. Only that will stop spam alltogether...
You're an optimist. People still fall for the MLM scams in droves, although they never make any money off them. I know people who jump to a different MLM thing every year or two, convinced this one will be the next one. They are perfectly willing to blow money on signs, postage, imprinted pens, and all sorts of other mainly useless marketing expenses; they'll happily keep spamming as well, even if they have to pay.
The only cash-related solution that will likely work is one that I first saw mentioned in Brin's Earth: Each person gets to say how much they must be payed to accept mail from an unfamiliar sender. The custom is then to refund the money if they mail is non-commercial.
The same goes for people who forward their spam to services like SpamCop--you are only clogging the network even more, please stop.
I think you're just trolling, but in case you aren't, here's the difference:
I go to a fair bit of trouble and expense to maintain my networks. I get to decide what happens with it. Spam is a parasitical use of that network, something I don't want. The reporting of spam is one of the things I do want. If I feel that it's clogging my network, I can stop anytime; I can't do that with spam.
Spam is noise on a data channel.
Uh, no. It's not like spam is some weird radio interference problem or some quantum effect. Real humans write and send every spam. They do it because they think they can make money at it.
This is not an inevitable consequence of the existence of a communication channel. Spam was negligible for many years; it wasn't until around the time of September That Never Ended or maybe the green card spam that I recall getting any. Since then it has grown explosively, so that for many people it outweighs regular mail. Ignoring it in hopes that it will go away or level out is about as smart as ignoring a suppurating wound.
I'd wager that the majority of those who follow the herd and say, "VB is an idiot's language," have never even tried VB.
I've tried VB; I used it by client mandate on a 4-month project. I started with only a slight bias, and ended up hating it with a burning passion. I wouldn't say it's an idiot's language, but I would agree that it makes weaker programmers.
Why? Let's ignore VB for a bit and compare Pascal, Perl, and BASIC.
Pascal is a language made for instruction. It's uptight, a bondage and discipline language, forcing you to program in a way that's pretty orderly. Developers who start with it tend to follow those habits later. Perl is neutral; it will allow you to program in a way that's as fussy as Pascal, but it will also let you write utterly perverse code. BASIC, has a weird set of limitations and freedoms that actively train people in bad habits that they will have to unlearn later.
In my experience, VB isn't as bad as BASIC, but it was pretty close. My major complaint is the complaint I have about a lot of Microsoft stuff: on top of a skeleton of early, rushed design (kept for the sake of backwards compatibility) somebody glued multiple layers of marketing's features d'jour, doing so without any particular appreciation for elegance.
A good programmer could spend some time working in VB and live; if they've had some broad exposure, then then won't learn the bad habits that VB allows and the tolerance for ugliness that VB requires. But somebody whose main experience is VB is another story entirely.
I know of one group of former VB developers who are now Java developers. The whole way through they've worked on a large dynamic website for a major financial institution, which they redid in Java a while back. For the most part the site works, but the code brought me to tears.
In trying to help these people (who were all smart, committed, and nice) the main problem was that 90% of them couldn't tell good design from bad, elegant architecture from tangled, or clear code from obtuse. I blame this directly on their years of working with a language whose designers didn't know the difference either.
No matter how cheap HDs get, they just don't have the [...] lifetime
Really, it depends on what you mean by "lifetime". Even assuming the media is still good, try finding a working drive for an arbitrary backup from a decade or two ago. And longer than that? Forget it. (But it's plausible that CDs will be an exception.)
For moderately long-term storage, your best bet is stone, although some metals are a good choice, too. But really, the only currently successful medium for real long-term storage is DNA. That's not because DNA is durable; it's because Lots Of Copies Keep Stuff Safe.
So the lesson is that if you really want to be able to get at your backups in the future, the best way is to keep them 1) live, 2) distributed, 3) replicated, and 4) monitored. Whether you do that by colocating a couple of hard drive arrays or by encoding the data into bacterial DNA with checksum-linked apoptosis mainly depends on your budget.
As someone once employed to build computers, here's how long it takes [...] Total time to build a system, if done in the above order: A little over 30 minutes. Well under an hour.
Uh, you neglected the three weeks it takes to get a job building computers, plus the couple of months it takes to get pretty good at it.
I remain unconvinced that anyone with just a bit of experience can't economically justify the amount of time it takes to build a computer
Even on Slashdot, I can't imagine that the average person gets a new computer more than every year or two. That just isn't often enough to keep up with the latest; each new computer involves a lot of learning and fiddling.
For me, when I set up new gear I always end up going through several loops where I change the hardware setup, the bios setup, or the driver settings, reboot, and run some tests to see whether I've made things better or worse. And if there's a subtle problem, that can take days of intermittent poking to track down. And if some hardware fails during burn-in, then I have to spend more time putzing around with RMAs, shipping, and billing.
If I buy from a reputable shop that does a lot of Linux boxes, I have some hope that they're already done the research and tuning to make sure that they've shipped me something solid and zippy.
Still, that's no excuse for a geek buying something from a major consumer PC company; that stuff is optimized for which-end-do-plug-in chumps whose peak computing experience comes when that letter in MS Word spills over onto a third page.
If you enter the actual maximum amount you are willing to pay, you would not have to worry about a "sniper"
The maximum people are willing to pay isn't constant; it's variable. For example, if somebody outbids you, you may discover that you are willing to pay more than you thought. Quite a lot of marketing works on this principle.
Whether or not this is a good or wise thing, I dunno, but it's a true thing.
You're on to something, for sure.
The problem the OP describes usually comes down to a lack of communication between the people doing the work and the people ordering it. Building up trust is a great way to get people to listen to you.
This is also why the various agile methods (XP, Scrum) work well; short-cycle iterative processes force a lot of interaction, and frequent deliveries build confidence on both sides. Allowing features to be reprioritized every iteration gives managers the feeling that they're in full control, which makes them much less likely to demand impossible things.
But I have seen cases where this won't work. In an organization of sufficient size, the high-ups are so isolated from reality that they can only manage by appearances; the people under them can succeed just by creating the appearance of success. All programmers know that it's easy to create the appearance of success for v1.0 while leaving a steaming pile of turds under the hood that will sabotage any attempts at v1.5. Truly evil managers will take this every time and then move on to a higher position, leaving somebody else holding the bag.
Designers should rely on their tools.
I think you may be setting up a bit of false opposition here. I agree that tools are good; I use many of those same tools myself. But when you say
[...]code reviews will NOT catch the most insidious and costly mistakes, such as general architecture design flaws[...]
you go too far. If there's a tool out there that will catch design problems, I've never met it.
Software development is an expression of human desires in languages meant simultaneously for human and machine interpretation. Good tools can help with the machine interpretation side, but only inspection by other humans can catch problems relating to human desires or human interpretation.
Design walkthroughs, code reviews, and pair programming can address problems for which there are as yet no good tools.
Deciding whether to use a code inspection or a profiler depends entirely on nature of the problem causing the poor software quality.
there are two coders on the project (myself and the senior coder)
Do you already review each other's code? If not, try that. Also consider trying pair programming, which gives you a continuous code/design review.
Otherwise, consider hiring an outside contractor to do the code reviews. Or even a couple of them to give you different perspectives.
we're approaching release on our project
This is not the best time to start code reviews. Why? At this point you've written a bunch of code; you're also facing release pressure. The only things most people would be willing to fix at this point are clear bugs that can be fixed without changing the design. Anything else you'll likely be forced to ignore (or hack around).
The earlier you catch a problem, the cheaper it is to solve. In your next design cycle, start code and design reviews early!
But the problem I face at my company is that nothing is fully planned ahead of time [...] Which in turn usually results in bugs. That's what I'd like to avoid. [...] I think the biggest problem is convincing the boss to sit down and fully plan his ideas before asking software to be written for it.
That's one possible solution. If your development process can't handle changing requirements, either you can a) suppress all changes after the first requirements are given, or b) change your development process to handle mutating requirements well.
Both can work, but they have different cost/benefit profiles. You might chat with your boss about how much business value could be gained from reducing time spent in the analysis phase, and adapting more quickly to the business environment. Then you can balance this against the costs of using a more flexible process.
I can do either, but personally I enjoy the flexible approach more. I get so tired of telling users no.
Please note that you are asking a question similar to "Are there any good books that cover the process of living? You know, what it's all about, and particularly what rituals to follow for success?" You are likely to get religious answers to religious questions.
For a good overview of development practices, though, pick up McConnell's Rapid Development . The main thing to come along since then is the various agile processes like XP. For the scoop on that, pick up Extreme Programming Installed . (Don't get Beck's book, Extreme Programming Explained to start with; it's a manifesto, not a practical book.)
As with religion, you should probably ignore the people who claim to have The Answer ("Use UML!" "Use XP!" "The word of the Architect shall be as law, and you verily must smite the coders who stray from it." "Only infidels use COBOL/VB/C++/Java!" "There shall be no editor but Emacs!").
Instead look at it more like home maintenance or martial arts. Is a screwdriver better or worse than a hammer? Is a punch better than a kick? Those questions can be entertaining, but they are never helpful. The right questions are more subtle: "Given the problem I'm facing, what tools might help? How should I adapt them to the situation? And how can I tell when they help rather than hinder?"
This depends a lot on the job and the outside interests. From the hiring side, I like to see people who are doing geek stuff because they love it. Outside projects also let people get experience that they couldn't easily get at work. It also gives a public record for me to examine; I'd certainly browse the code and the CVS history to see how you code and what you've been learning. You get bonus points if a) the project is relevant to the industry or b) if you or the project is prominent enough that we can attract customers or better staff by saying something like, "Yeah, Linus Torvalds is working for us."
On the other hand, if I suspect that your outside projects will prevent you from giving 100% while you're at work, the resume will go right in the shredder. If the job is a particularly intense or demanding one (e.g., a startup), that goes double. The last thing I wanna do is be somebody's daddy/monitor/whip-cracker, making sure they aren't always sneaking off and working on their outside projects.
And now that I think about it, this all applies to any non-work activity, geek or non-geek.
I agree that /etc is a pain in the ass, but I don't buy that it's just as good as the Windows registry. The registry is easier for programs to manipulate, but etc-style plain text files give much more flexibility and support for arbitrary human-readable metadata (especially through comments, but also through naming, file location, and organization within the file) that the Windows stuff lacks entirely.
The registry strikes me as a typical Windows effort: notice a problem (namely that lots of little text config files are a pain), think about it for between two and five seconds, and then introduce a solution that while better in some narrow sense (namely that the data is now structured). But they don't really appreciate the full power of what they're ripping off, and they don't give any thought to maintainability or future expansion.
And thus it's nearly useless to call most companies for Windows technical support. They might as well replace all of those people with a recording saying "Download the new version. If that doesn't fix your problem, reinstall Windows."
Java has some really cool features, but it is a dumbed-down language aimed at dumb programmers with the effect of keeping potentially smart programmers dumb.*
I do most of my professional work in Java these days, so you'd expect me to disagree. But you're 100% right. Java is a language with most of the sharp edges hidden away between a lotta cushy padding. And generally, I think "Thank god for that," even though I personally find it constraining.
Why? Because half of the programmers out there are below average. (Or, as a mathematician I know reminded me, more than half the programmers are below the mean.) If I'm going to work on somebody else's code, I'd much rather it be in Java. Bad Java is salvageable; bad C or Perl is so impenetrable that you might as well just off yourself. Or, perhaps better, the person who wrote it.
Personally, I like to drive fast cars, the kind of sports car where you can hear the engine's every growl and feel every pebble. The kind where you can turn on a dime and give yourself whiplash by stepping on the gas pedal quickly. But can you imagine the carnage if all cars were like that? For everyday people and everyday uses, minivans are all most people should be allowed to use. Ditto Java. But although minivans and Java keep people safe, they make it impossible to build your skills past a certain point.
Dude that stuff makes me paranoid, too.
Best not to mix economics and toking, though. Instead, try writing device drivers when the paranoia hits; that way you will trap potential errors six ways from Sunday.
Large financial institutions have been doing this for quite a while. The crash of '87 was allegedly made substantially worse by automated trading systems, so much so that the SEC muzzled 'em substantially.
The nice thing about working for financial companies is that they aren't afraid to spend money if they think they can make money. But beware: trading atracts the most prodigious bullshitters and superstious nut-jobs that I've ever seen. If I could get a dollar for everybody who thought they had sure-fire way to beat the market and make millions, I'd make millions.
But that episode didn't air until 1998. Clearly they stole it from here:
Step 1: Get market share
Step 2: ???
Step 3: Profit!!
Which was the business plan of 92% of VC-funded internet companies starting in 1996.
The end result of an undergraduate CS education should be adability, and the facility to think in whatever language the situation demands.
Yeah, but this is an intro programming class we're talking about. C++ is fine for production code written by professionals, but they don't strike me as great teaching languages.
The point of an intro class is to draw people in, help them to see how cool it is, get them thinking in the right way, and give them some foundation so that they can go on. Tracking down subtle malloc bugs or pointer problems is enough to bring seasoned he-man programmers to tears; I can't imagine what it would do to an unsuspecting liberal arts major.
Personally, I started with BASIC and Pascal. Both are limited languages, but Pascal taught me a lot of good habits that helped me when I got to less anal languages. Without that kind of discipline, something as no-safety-guards as C or more-than-enough-rope-to-hang-yourself as Perl might have killed me dead. Or worse, killed the people who had to maintain my code.
Ah, I'm beginning to see your point.
It sounds we agree that unit tests are good but not a sufficent way to achieve high-quality code. We also agree that the key to good development is having skilled developers; processes can support or hinder them, but no ritual can turn dunces into geniuses.
(a) passing unit tests does not give any indication of maintainability
Absolutely. This is what makes understanding biological systems really hard. They don't even have unit tests, just functional tests. All the code (that is, the DNA) changes are random, and as long as the functional tests mostly pass, the product ships. (Personally, I advocate taking all those surplus COBOL programmers and giving them to the human genome project; if they can deal with hopelessly snarled 50 MLOC ERP systems, the should be able to help with all that junk DNA.)
The only thing that guarantees maintainability is maintenance by people who know they will have to keep maintaining the system. Twenty minutes into an XP project, the first unit test should pass. After that, you can think of it as being in maintance mode; unit tests are not allowed to regress, and features are continously added to the existing code base. Only maintainable code can survive this process.
(b) passing all the unit tests, while a good confidence builder, is not an absolute guarantee that requirements have been met and no bugs are lurking.
Also very true. Note that XP also requires functional tests, which are specified by the customer. Unit tests verify that the code does what the developer intended; functional tests verify that the code does what the users want. Pair programming also gives you code reviews and walkthroughs for free. For most projects, that's a high enough level of quality. But if that isn't, the XP gurus will certainly tell you to add other quality control measures, of which there are a plentitude.
Note, though, that you can never guarantee that a non-trivial system has no bugs. Each quality control measure reduces the chance that a bug will be encountered by an end user, but the cost rises exponentially for each bug found, so at some point you just have to ship.
One thing a clear and well-documented design is excellent for is reducing your dependence on the guy who originally wrote the code. OTOH, how does a new guy on the project who wasn't in your original development pair learn his way around? (I'm not saying it can't be done, just that it might be harder without a clearly documented overall design.)
Clear designs certainly increase maintainability. So does clear code. As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." And other XP heavyweights are very big on this too; Ward Cunningham, for example, makes a good case that an OO programmer should always have a thesaurus at hand, so that you can choose the best names for your objects.
But it sounds like you have a misconception about XP; pairs change frequently (generally every few hours), and knowledge is widely distributed among team members. Thus, a newbie just gets thrown into the mix, although you generally try to pair them with your more experienced people until they find their feet. Heck, one shop I know of doesn't do technical interviews anymore; they'll just bring a promising candidate in for an afternoon to pair with a few different people, doing normal work on production code. At the end of the day, both sides know exactly what they're getting into.
Of course if you have really high turnover, a shared-knowledge approach could break down, but that kind of turnover among programmers is a symptom of severe organizational problems that will likely sink any process. And if the project is put on ice and the team is disbanded, the recommended practice is to spend a final iteration tidying up loose ends and writing documentation so that they next team can take over easily.
This is theroretically true, but it requires iron-fisted control over design changes, and it also requires developers to have enough appreciation for design to know when they are doing it wrong.
Most of the time when I see a formalized architect/coder distinction on a project, it ends up being a) seagull-style, where a theoretician flys in, poops a lot of design on everything, and flys away, leaving the developers to deal with the mess, or b) rebellion in the trenches, where developers know that they can get away with ignoring the architects, so they just do their own thing.
I have seen it work occasionally, but it ends up being in spite of the formal division, rather than because of it.
In an XP-based process, you appear to need one skilled person in every programming pair, a much more demanding requirement. The responsibility has been decentralised, so everyone now shares it and needs to be able to handle that.
I could see how you'd get that idea, but that's now how it should work. As with the other model, the developers need to know when they are in over their heads and then ask for help.
With XP, though, there are a few things to support this. One is that only one of the programmers has to recoginize the trouble and ask the best designer for help. This could either come through a short discussion or through the master just getting swapped into the pair.
Another valuable piece of support is that XP requires frequent pair changes, so a design issue of any substance will get looked at by a variety of people in pretty short order. This doesn't just give you the benefit of many eyes; it also means that design problems are likely to get caught sooner.
Better, XP encourages experimentation and change. With the classic waterfall approach, you are stuck with bad design decisions for a long time. The ability to safely change my design as I go has substantially improved the designs I end up with.
But I think the most important one is common code ownership. Part of a team effort is that each person should make use of their strengths. If you're by far the best designer, then you should be looking out for design problems and fixing them, especially given XP's empahsis on aggressive refactoring. Common code ownership means that you are empowered to change anything that you think is ugly.
I've only ever been involved in a couple of projects that have tried XP seriously and long-term, but both suffered obviously from this particular weakness, hence my reservations that started this subthread.
I'd be intrigued to hear more! In particular, I'd love to know
Personally, I used to aspire to be an architect, and I still will occasionally take jobs like that. But I eventually realized that the only way I learned to design well was by writing a lotta code, which made me intimately famliar with the tradeoffs that a good designer had to make. But as soon as I was an ivory-tower architect, mere coding was considered beneath me, which cut me off from the source of my strength. Once that happens, it's easy to spend a lot of time on philosophical bullshit, debating the OO equivalent of angels dancing on pins.
Now, every day I analyze, design, write code, and design some more. I find it much more satisfying.
That's very true. But don't give up! It's slow getting people stated with unit tests, but once people have had a little experience with it, they see how helpful it is. Once it catches on a little, the process will snowball.
Some of my favorite tricks:
Whatever people think about XP, good unit tests make for better code and less developer stress. Until I tried XP and test-first, I never really wrote them, but now they make my life so much easier.
Their "comprehensive" unit tests simply weren't.
And? Perfection is rarely achieved the first time. Indeed, perfection is never achieved; that's one of the big lessons in iterative developent. Bugs always happen, the only question is what to do with them. When a bug is reported, I write a test to expose the bug, then I fix the bug. I may not have all the bugs, but I can be confident that certain problems will never appear.
as anyone who's worked in the field will tell you, testing with blanks is no guarantee it will work with live ammunition.
I will certainly grant that some things are so expensive to test that it's just cheaper to accept the failures that come from not testing. But anybody who's worked in the field can also tell you that if you don't even fire a few blanks, odds are low that it will work with real ammunition.
The level of testing I did at that point was way more than any set of unit tests I've ever seen.
I guess I am not getting your point. You name a lot of other quality control techniques, all of which are good. Does this make unit testing bad? No. For many cirumstances, I find it a much cheaper way to achieve a given level of quality.
The main difference is that non-automated quality control measures are very difficult to repeat cheaply. Moore's law means my unit tests, integration tests, and functional tests get 50% cheaper every 18 months. Code walkthroughs, second opinions, and manual testing track programmer salaries.
I exercised every option and every little setting, which is the most any automated test would do, if you could even write such a test in the first place. [...] You couldn't write automated tests to test the code I was working with. I think that pretty much shoots that argument down in flames before it even starts.
If you can manually test it, you can automate the test. The only question is one of cost. For pure software, the costs should be pretty low.
The problem may be in your testing techniques; retrofitting testing to existing code can be a pain, but doing test-first development is pretty painless and much less expensive then after-the-fact testing.
Some of that code is now used by thousands of clients, hundreds of times a day, and in more than two years since some of those modules went live, we haven't had a single fault report on them.
And what happens when somebody else goes to add a feature to your code? With good unit tests, an average programmer with little knowledge of your modules can make the change without breaking any existing feature. Without them, you're the only fellow who can make the changes cheaply. That's great for you, I guess, but it sucks for your employer and the colleague who gets handed the stuff when you get hit by a bus.