Slashdot Mirror

Netscape 4 sucks, so lets throw it out and start again. Back when Spolsky could write he bitched about this.

Mozilla seamonkey sucks, so lets gut most of it and make Phoenix (now known as Firefox)

And now this again?

It's 13 years old, but I still recommend as an introduction "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" : http://www.joelonsoftware.com/...

Hi Whiplash. I've been a very long term Slashdot reader who used to moderate etc. My effective protest about Dice was that I stopped logging in to my account; I'm going to celebrate this change by getting a new one or possibly reactivating my old one. Hopefully I will be able to continue that indefinitely. In the meantime a comment similar to one I made to Dice long ago.

Your comment about not replacing the user interface sounds like you are thinking about it. This is an obvious thing. Probably by now the code is big and difficult to maintain. Certainly the interface is old and limits certain new ideas. Dice didn't start the rewrite project for no reason. Before you even consider doing this read things you should never do.

The money quote is

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

Remember, this is will be on top of the three years Dice already threw away. Obviously, if you have some new ideas, then you are going to want to update the user interface. The main thing is that, if you do that, you need to do it in an evolutionary way, step by step, at all times fully with the old code base and at all times delivering new functions to all of the existing users. Otherwise you will end up like dice. Building a new interface that nobody uses and still maintaining the old one. If you really believed you could start Slashdot from scratch then you wouldn't have bought slashdot, just created a new one.

This means "throw away" the work Dice did on software that nobody wants. Start by announcing that the mobile interface is dead. Get everybody back onto one code base. Then start to see if you can mix new functionality together into the old interface. You may even be able to salvage some of the new work. The key thing is a) never introduce more than one new major feature at a time b) don't start introducing the next feature until the previous one is in use by, or at least visible to the majority of the code users c) back out changes if they make the users unhappy.

N.B. If you want to make any money from advertising to me you have to serve acceptable ads. Recent experience says that there's no way that I'm turning off the AdBlocker and the harder people try to make me the more I'm going to fight them, however I do, possibly stupidly, still keep the acceptable ads setting turned on in AdBlock Plus.

Exactly what I was thinking. Hiring skilled people and paying them a reasonable salary to get work done for you only to handicap them with a terrible working environment is just silly. Qbertino really needs to read http://www.joelonsoftware.com/... and think about the impact of giving his developers an ultra-cheap environment. Heck, go to the library and check out Peopleware as well. The library is even cheaper than ultra-cheap and a thoughtful read through that book will help him use his resources more effectively.

Since when did MS seriously worry about compatibility between versions?

They made a huge effort in Windows95. You can read about it here (though they've changed somewhat too). Quote:

Raymond Chen writes, "I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95."

Joel Spolsky likened the giant list of bugs to an keeping inventory: There's an overhead cost just from it being there.
http://joelonsoftware.com/items/2012/07/09.html

When you look closely you realize that months or years of work has gone into preparing those bug reports, and you ask yourself, how could we have 3000 bugs in the database while our product is delightful and customers love it and use it every day? At some point you realize that you’ve put too much work into the bug database and not quite enough work into the product.

• Suggestion: use a triage system to decide if a bug is even worth recording.
• Do not allow more than two weeks (in fix time) of bugs to get into the bug database.
• If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.

http://www.joelonsoftware.com/...

> Microsoft has an amazing history of backwards compatibility. I mean, the SimCity hack is just my favorite,

Ah, you're referring to How Microsoft Lost the API War

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

No wonders Windows is so buggy. They keep enabling other people's crap.

This puts it better than I can

http://www.joelonsoftware.com/...

MS is 'done'. They are slowly eating themselves. Balmer did a real trick on that company. Maybe the new dude can pull it out. But it will be exceedingly harder to do.

People do not upgrade hardware like they used to. It used to be if you bought a new computer 1 year later it *was* in every way better. Now it is only marginally better. I know people who still use every day Vista. They have no real reason to upgrade at all. What does that mean? It means if MS wants to push a new tech they can no longer rely on people upgrading the OS which typically happened at 'buy a new computer time'. Hence windows 10 and its rolling release. For them to survive they *must* push windows forward. There other software platforms will depend on it. The telemetry being sent back is to figure out how much backwards compatibility they need to spend time on. If 3 people in the world are playing some game dont bother. But if 50 million people are playing it then it may be worth the time to reverse engineer it and write the shims. The dev market basically dried up so they are as quickly as they can open sourcing the whole dev stack.

Oh, a framework.

hey typically render pixmaps and just have the X server composite them

This is just nonsense. Your applications may be overly pixmap based (certain GTK+ engines started that mess when people prioritized "themes" over good design), but it is foolish to assume everybody else uses the same limited set of software. Remember, most of the software in the world is smaller private stuff used internally by businesses, academia, etc. Simply asserting that nobody uses various features doesn't make it true.

Wayland advocates really need to learn one of the most important lessons of software design, which was best explained by Joel Spolsky's essay "Things You Should Never Do, Part I".

[Y]ou can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for." [...]

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. [...]

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. [...]

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Yes, there are rough areas in X11 that really need to be fixed. That's true for almost any software project of sufficient size. Fortunately, the extension system in X11 allows a lot of those problems to be solved one at a time, while retaining backwards compatibility. The people that believe the very existence of backwards must somehow be a bottleneck are not creating the next version of X. Instead, they are creating something new. This is fine, but by their own definition, it is not a replacement for X11, and if Wayland tries to be such a replacement, it will inevitably grow to a similar level of "messiness" as numerous fixes, workarounds, and minor features are re-invented.

The problem with Wayland (and many other modern "replacement" projects, with systemd as the canonical example) is not technical in nature, but the hubris that so easily throws out so many man-years of effort.

So, a whole bunch of people just graduated from school and realized the way we're currently doing software development is a lot of hard work, and all you need to do is automate it with magical fairies. As if no other generation of programmers before have come out of school with the same ideas. Further (relevant) reading.

LibreOffice 5.0, the tenth major release

Version 5 = 10th major release? Were they using excel to calculate their version number?

It's almost as bad as going 3.11, 95, 98, ME, 2000, XP, Vista, 7, 8, 10.

LibreOffice 5.0, the tenth major release

Version 5 = 10th major release? Were they using excel to calculate their version number?

I think the point here is doing a very basic list like the Joel Test:
http://www.joelonsoftware.com/...

He is not looking here in advice for seasoned developers.

I'm even fine with changes that break existing software if it is required to fix a security issue. Unfortunately, we have people confusing design with implementation, and even more that follow the Not Invented Here principle. Anybody in that camp may want to read "Things You Should Never Do" by Joel Spolsky.

When programmers see an old, messy project they tend to want to rewrite it. They see that mess and believe they know how it could "obviously" be simplified. Usually, this is incorrect, as the simplified abstraction they are picturing doesn't actually implement the same feature. That "mess" was actually the accumulation of important details that were learned over time: subtle details that were not covered by the original design, evolving requirements, and expensive bug fixes. The "rewrite" has none of that, and those details will eventually be added back, eventually making the rewrite just as messy as the original version at the cost of many man-years of effort. Throwing out the "mess" is throwing out a project's most valuable asset: real-world experience.

Warnings are useless.

Very important point.

For a good explanation of why this is, Joel Spolsky's article back in 2000: "Designing for People Who Have Better Things To Do With Their Lives" summarised it down to "users don't read anything", and broke it down into three simple points:

• * Advanced users skip over the instructions. They assume they know how to use things and don't have time to read complicated instructions
• * Most novice users skip over the instructions. They don't like reading too much and hope that the defaults will be OK
• * The remaining novice users who do, earnestly, try to read the instructions (some of whom are only reading them because it's a usability test and they feel obliged) are often confused by the sheer number of words and concepts. So even if they were pretty confident that they would be able to use the dialog when it first came up, the instructions actually confused them even more.

The brand, yes. The language, not so much. VB3 -> VB4 was a huge breaking transition in just as many respects as VB6 -> VB.NET, and that was in 1995. VB4 -> VB5 was also breaking in quite a few things, largely because of Win16->Win32 move; and that was in 1997.

That's a good point. VB was never known for being stable.

Most importantly, large chunks of .NET are now open source, including pretty much all of the web/server stack. It won't go away even if Microsoft were to drop it.

It doesn't really matter now, after the .net fiasco, most companies that could switched to web-based apps. This article goes into deeper detail.

You mean, the better language capable of running on the .NET CLR and utilizing the same set of proven, well-tested libraries available for all .NET languages? Getting that with a very low learning curve for existing VB developers?

You utterly failed to respond to his point. The only question is whether you ignored it, or didn't understand it in the first place.

Just in case you're not a troll, and you want to understand his point, here is the same thing restated. For your convenience, here is a relevant quote:

If you spend the money to upgrade to VB.NET, well, you just spent a lot of money to stand still. And companies don't like to spend a lot of money to stand still, so while you're spending the money, it probably makes sense to consider the alternatives that you can port to that won't put you at the mercy of a single vendor and won't be as likely to change arbitrarily in the future. So as soon as people with large code bases start hearing that they're going to have to work to port their apps from VB to VB.NET with WinForms, and then they start hearing that WinForms isn't really the future, the future is really this Avalon thing nobody has yet, they start wondering whether it isn't time to find another development platform.

That's why people stay away from Microsoft platforms.

You only need to print one factory factory factory and take it from there.

FTFY

According to Joel, Java isn't hard enough to weed out mediocre programmers in college. (Great programmers can use any language well.)

Cool, a CS student!

In the real world, there are edge case reasons where it makes sense, often for performance reasons. When your leaky abstractions fail you, you have to deal.

As I said, an immutable object may need to be duplicated because it is far more efficient to read contiguous memory or to prevent trashing.

Maybe the Prof is applying one of the principles from Joel Spolsky. It is better to fail the passing student than pass the failing student. The failing student can always take the class again and (likely) pass while the failing student is unlikely to take the class again and (deservedly) fail.

Probably not without the right framework, though.

String += String

Im in a 200 level java class. We're just learning inheritance. I could have told you why thats a bad way to do things.

Do people not study what arrays are and why its expensive to continually append to them anymore?

Maybe these folks need to go back to basics.

If they wanted to do that, all they had to do was post this. http://www.joelonsoftware.com/...

I think they missed that the += operation is an O(n) operation, and that putting it in a loop made it an O(n^2) operation - as compared to the O(n) operation of writting to the file butter. If they hadn't missed it, then they would have come right out and said that when they were talking about using StringBuilder or StringBuffer.

Something that also incorporates a wiki might be nice.

Jira and Confluence integrate well, and have the support of a company and large installed base behind them for future development.

There will be resistance if it's not really easy to use.

Joel Spolsky also made a point about formal issue tracker adoption, in that it doesn't have to be all or nothing (Strategy 2) from the get-go.

Here's probably the best things I've seen written on refactoring: http://www.joelonsoftware.com/... & http://www.joelonsoftware.com/...

Here's probably the best things I've seen written on refactoring: http://www.joelonsoftware.com/... & http://www.joelonsoftware.com/...

Joel Spolsky has a take on this problem, called Evidence-Based Scheduling, which tracks past estimates against their deliveries, and uses that to improve future estimates.

That is a good idea, but you have to be careful how you track work. We used to do estimates based on hours worked and thus come up with a price. Since the work was fixed price the actual hours were irrelevant to the customer's cost; but very relevant to our team. Going over was bad; and going under yielded us no benefits other than having to explain low utilization; even if we had huge profit margins. As a result, our total hours billed to a project always exactly matched the estimate. One word of caution, never let the sales person estimate the cost or duration; they are rewarded on sales and so have an incentive to underbid to get work and let the team try to deliver.

Joel Spolsky has a take on this problem, called Evidence-Based Scheduling, which tracks past estimates against their deliveries, and uses that to improve future estimates.

One of the big problems with the legal system is how inefficient and time consuming it is. We live in a world where just threatening legal action can put a big question mark over someone's financial future. To do anything, you need to pay for the services of expensive lawyers and paralegals. So this naturally puts the wealthy, big corporations and big government agencies at an advantage.

You can see how inefficient the judicial system is just by looking at how much paper they produce. They literally have to wheel boxes of documents into court with carts. Armies of paralegals have to manually sift through the documents by hand. It's really one of the most conservative and backwards industries out there.

The most obvious way that technology can help is by increasing efficiency and leveling the playing field. The ideas are not new (e.g. http://www.amazon.com/dp/01995...) and I think eventually law firms and courts will learn to leverage technology and make their services more accessible. Making information more accessible will also help shoot down abusers of the legal system (e.g. in invaliding bad patents - http://www.joelonsoftware.com/...).

"when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version. "

Maybe Wayland will be better, that would be great. Odds are against it though, because of how rewrites usually go.

While I applaud the founder for this move, I can't help but wonder what could have been if these efforts had been put toward producing a truly MS Office replacement.

It would lead to something like OpenOffice. Until Office 2007, working with MS-Office files meant working with the mess those binaries were. Look at this, and this.
Even nowadays, it is not "a truly MS Office replacement" if it does not open (and edit) old files, so too much effort goes to legacy.

While I applaud the founder for this move, I can't help but wonder what could have been if these efforts had been put toward producing a truly MS Office replacement.

It would lead to something like OpenOffice. Until Office 2007, working with MS-Office files meant working with the mess those binaries were. Look at this, and this.
Even nowadays, it is not "a truly MS Office replacement" if it does not open (and edit) old files, so too much effort goes to legacy.

And if only MS had a similar "never break userspace" rule that applied to even the most unbelievably "casual" of software too.

They used to. Scroll down and check out the part about Sim City.

Nobody buys a 'Toast Decorator'. They buy a 'Toast Decorator Factory'. If you don't pick the right framework, you're never going to be more than an HTML coder.

Microsoft thought that if people wrote lots and lots of VBA code, they would be locked in to Microsoft Office. They thought that no matter how hard their competitors tried (in those days, they were Borland, Lotus, and, to a far lesser extent, Claris), they would not be able to emulate the VBA programming environment and the gigantic Excel object model perfectly

PS: in researching this article, I tried to open some of my notes which were written in an old version of Word for Windows. Word 2007 refused to open them for "security" reasons and pointed me on a wild-goose chase of knowledge base articles describing obscure registry settings I would have to set to open old files. It is extremely frustrating how much you have to run in place just to keep where you were before with Microsoft's products, where every recent release requires hacks, workarounds, and patches just to get to where you were before.

Visual Studio + C# is fine as a development environment. Which is to say, it's not crappier than anything else.

The worrying thing is that Microsoft hasn't changed (they're still a corporation trying to make money, let's be honest), and they'll regain the dominance they once had. If you can't remember why that's a problem, here is a refresher.

I agree with the idea to study mathematics, as a useful exercise, that would in many cases benefit programmers by giving them a good mental workout, and hopefully reinforce if not expand their understanding of mathematics, logic, and reasoning.

Beyond that I would argue for the study of writing, in a natural (human-oriented) language of your choice.

Programming as a profession, and as an art, is about the meaningful expression of ideas; in a detailed, unambiguous manner that can be processed by a computer. Programming languages are tiny, simplistic, and restrictive in their ability to express ideas, and the execution of these ideas. Writing in a natural language is much more complex, particularly when you strive to remove undesired ambiguity*. The other issue is that as a professional, programming is not done in isolation. Even if you are an independent contractors, you must be able to communicate effectively with clients and users.

*) Ambiguity can be desirable in humor and poetry.

I think that any programmer can benefit from the abilities to make logically sound, comprehensible arguments in a written document; that these abilities will make them better in their ability to understand, and be understood by users, customers, or colleagues.

The argument has been made in the past by Steven C. McConnell in Code Complete, in The Pragmatic Programmer by Andrew Hunt and David Thomas, Coding Horror by Jeff Atwood, and Joel Spolsky (of Joel on Software) in his Introduction to Best Software Writing I and College Advice. And like tons of other software developers, and their managers; repeatedly.

You see, communication is the only really important aspect of software development that people really have trouble with. The rest are details and small bugs, but for really big screw-ups you need miscommunication (or greed)

I agree with the idea to study mathematics, as a useful exercise, that would in many cases benefit programmers by giving them a good mental workout, and hopefully reinforce if not expand their understanding of mathematics, logic, and reasoning.

Beyond that I would argue for the study of writing, in a natural (human-oriented) language of your choice.

Programming as a profession, and as an art, is about the meaningful expression of ideas; in a detailed, unambiguous manner that can be processed by a computer. Programming languages are tiny, simplistic, and restrictive in their ability to express ideas, and the execution of these ideas. Writing in a natural language is much more complex, particularly when you strive to remove undesired ambiguity*. The other issue is that as a professional, programming is not done in isolation. Even if you are an independent contractors, you must be able to communicate effectively with clients and users.

*) Ambiguity can be desirable in humor and poetry.

I think that any programmer can benefit from the abilities to make logically sound, comprehensible arguments in a written document; that these abilities will make them better in their ability to understand, and be understood by users, customers, or colleagues.

The argument has been made in the past by Steven C. McConnell in Code Complete, in The Pragmatic Programmer by Andrew Hunt and David Thomas, Coding Horror by Jeff Atwood, and Joel Spolsky (of Joel on Software) in his Introduction to Best Software Writing I and College Advice. And like tons of other software developers, and their managers; repeatedly.

You see, communication is the only really important aspect of software development that people really have trouble with. The rest are details and small bugs, but for really big screw-ups you need miscommunication (or greed)

I agree with the idea to study mathematics, as a useful exercise, that would in many cases benefit programmers by giving them a good mental workout, and hopefully reinforce if not expand their understanding of mathematics, logic, and reasoning.

Beyond that I would argue for the study of writing, in a natural (human-oriented) language of your choice.

Programming as a profession, and as an art, is about the meaningful expression of ideas; in a detailed, unambiguous manner that can be processed by a computer. Programming languages are tiny, simplistic, and restrictive in their ability to express ideas, and the execution of these ideas. Writing in a natural language is much more complex, particularly when you strive to remove undesired ambiguity*. The other issue is that as a professional, programming is not done in isolation. Even if you are an independent contractors, you must be able to communicate effectively with clients and users.

*) Ambiguity can be desirable in humor and poetry.

I think that any programmer can benefit from the abilities to make logically sound, comprehensible arguments in a written document; that these abilities will make them better in their ability to understand, and be understood by users, customers, or colleagues.

The argument has been made in the past by Steven C. McConnell in Code Complete, in The Pragmatic Programmer by Andrew Hunt and David Thomas, Coding Horror by Jeff Atwood, and Joel Spolsky (of Joel on Software) in his Introduction to Best Software Writing I and College Advice. And like tons of other software developers, and their managers; repeatedly.

You see, communication is the only really important aspect of software development that people really have trouble with. The rest are details and small bugs, but for really big screw-ups you need miscommunication (or greed)

Rebates have other purposes.

One differentiation from a normal plain price cut is info. In this case, you're a Comcast customer and they have said info, but in the general buying-from-a-store sense its a good source of buyer info. if i bought, say, a ShopVac and I had a mail-in rebate, then ShopVac has the name and mailing address of a ShopVac customer. They're now free to use that information in certain ways, such as junk mail, sending me mail for add-ons, etc.

Second is price discrimination. If somebody wants to give me 200 for this, I don't want to get in his way. If someone will only pay 150, well, I have a 50 rebate card he can send in for. There's some effort in the rebate card and maybe the guy who paid 200 loses the receipt or just doesn't want to bother with mailing it in. That's an extra 50 for the seller, called producer surplus.

Back when Joel Spolsky wrote more, he had an excellent primer on pricing. It's written from a producer point of view, but it's a a good read for consumers as well. If you know about producer surplus, you know where you can start negotiating on prices as a buyer.

*another* development stack... pity's sake, don;t we have enough already?

Now its just another thing that will pollute our systems - no longer will you install some shitty little app and find it pulls in all the Gnome libraries, now it'll pull in a heap of .NET ones and probably Gnome libs too!

The reason Microsoft likes it is possibly because of the sentiments in this article

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features.

Yeah, so now Linux people - you too can spend all your time rewriting in the latest cool new development stack, while Microsoft gets on with building whatever it was you used to build.

Add to that "developer mindshare" and we might just give up on anything decent, having to put up with crap like ASP.NET MVC Razor 5 with EF6.1 frameworks.. and if you don't know all that blackbox magic, forget trying to get a job.

There's a lot of people who will code in .NET because it purports to be easy, and they will use Visual Studio sooner rather than later, and then they'll find writing for Windows first is the norm, just for development.. and eventually they'll think why bother actually doing the little porting work.

so I'm not convinced its a good thing overall, even if it is good for me as I know that shit already.

Ah that brings back memories - the IBM documentation bibles I had for OS2 programming were bliss. If I needed to know *anything*, I looked it up.

Today, its a combination of intellisense guesswork, google and trial-and-error coding :-(

I'd like to say that going back to the old days would be good, but we have too many languages, too much refactoring in APIs, too many 'cool new things'. No-one could go back to the concept of building on top of what is already there in a stable, mature manner (well, except the Linux guys, but then look at what's going wrong with systemd to see it infecting even them!)

To all: if you want productivity, you need to stop with the churn. Spolsky said it right when he talked of all constantly changing APIs from Microsoft. Summary: it helps Microsoft, not you:

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features.

Your'e close - the split is indeed between the older Unix types and people that just want to be "users", but you need to recalibrate where their relative positions. Those of us that are against being forced to use[1] systemd see this in a different light. As computers became inexpensive over the last decade, a new generation of younger people joined the Linux community. They were young an inexperience, and often made well-known mistakes in their software. Thats was ok - we were all n00bs at first, and many of us tried to gently nudge the inexperience developeers in useful directions. Very few listened, and have now decided that anything "old" is bad.

Listening to those that came before you is important, if you want to avoid making the same mistakes. A lot of those lessons are collected under what many refer to as the "Unix Philosophy". Mostly, that "philosophy" is jsut a handful of tricks that make maintainance saner. A lot of the stuff that people claim is "overcomplicated", "messy" or an "archaic design" is such an "ugly" state for a reason, and those messy bits are bugfixes. The nice ideal design we all starty with rarely fits exactly when we introduce it to the problems and unforseen circumstances in the real world. That ugly spaghetti-code-style hack that seems to ignore and bypass the "correct" way? That is probably a bug fix, and by removing it you probably reintroduce the bug.

You call us luddites, but heed our warning at your own peril. Some bugs and bad designs have happened before, and a key reason why we don't like systemd is that it makes one of the worst mistakes you can ever make when designing software: it throws out the supposedly "old" or "ugly" parts. I suggest readoing Joel Spolsky's famous essay on this topic:

you can ask almost any programmer today about the code they are working on. "It's a big hairy mess," they will tell you. "I'd like nothing better than to throw it out and start over."

Why is it a mess?

"Well," they say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."
[...]
The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
[...]
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

Systemd is still at the early stage, where it can get away with this kind of bad design, but as more and more people start to use it and the never-ending list of Real World Problems starts to creep in, the systemd developers - and the distros that joined them - are goign to have one nasty mess on their ihands. It is going to be a nightmare to all of the bugfixes and real-world mess that was thrown away because it was "old".

We tried to warn them, and were labeled luddites.

Well, as B5's Londo Mollari put it:

"Ah, arrogance and stupidity a

Mature, debugged, and well documented?

From a classic (i.e., old) JoelOnSoftware, Things you should never do :

Before Borland's new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

Which DOE lab has tenured staff? Or calls them "faculty" for that matter? The ones here in Livermore have "Technical Staff" and there is no tenure, per se.

Check out this guy's essays on hiring. Really great insights, and just plain fun to read. Plus you can kill an afternoon reading his other stuff too: http://www.joelonsoftware.com/...

That reminds me of this quite interesting article:

http://www.joelonsoftware.com/...

I've found that while a degree can help you get entry level at a higher position, after a few years, competence catches up pretty quickly on compensation.

As a hiring manager, I've been fond of the "smart, get's things done" criteria - http://www.joelonsoftware.com/...