One Feature for Future Operating System...

Long ago operating systems completely missed the idea of “installation”. Setup of each program was completely personal business of that program. Now they became a bit more wise that that, but still featuring that naive liberal-democratic way of how other people treat my hard drive. Which is one of the reasons for the spread of sexually-transmitted... pardon, Internet-downloaded software transmitted computer viruses.

If I’d be asked, I’d say that one feature I want from any future operating system is treating any program, wishing to install on my machine, as a feature, totally encapsulated, with operating system knowing each piece to keep or remove, when I am done with it, and which activates only when it’s needed, and which is deactivated afterward.

Say, SQL Server Personal Edition. On one hand, this is an amazing piece of freely available technology from the world #1 commercial software vendor. On another hand, 90% of the time I am waiting for this piece of crap to start up, when booting my computer, is a total waste, because I don’t actually need it this time.

Is it too much to ask?

Cross-post from http://eldar.com/node/401">the personal blog...

No Style Is Perfect.... a case for passing args by reference in C++

Let's say you have a style guide that says: "Never pass parameters by reference in C++ unless it's const"

Sounds fair, isn't it? After all, passing by reference is indeed fairly confusing concept. You see a variable like a local variable, but you can assign to it. Is it a good policy? Maybe. But lets see...

Assume you have a function like:

void DoStuff(Crap* crap) { ... }

You want "crap" to be mutable, so you cannot pass it as (Crap& crap) according to the policy. You have to pass a pointer.

Then in the main() you get a code like this:

main(...)
{
...
Crap crap;
DoStuff(&crap);
...
}

Now, guess what do you get in DoStuff after a bunch of junior developers changed it? Something like:

void DoStuff(Crap* crap) {
...
crap = new different pointer....
use crap
...
}

Crap...

No really, I just fixed the one like that. Not good. Crap. Keep an eye on things like that.

Never ever never ever...

No kidding. Never ever do that. Never. Ever. Seriously. Again, no kidding.

Big NO-NO.

BAD. REAL bad. Don't do that.

Ok, it may be good for a team or a company, but this is not good for you. Yes. No kidding.

NEVER OWN A PIECE THAT HOSTS EVERYBODY ELSE'S CODE.

I did. And I tel you, do not do that. Really.

Let's imagine you own a Windows service, like NT service. And it has a mechanism to host code of everybody else in the team. Guess, what comes next?

So, every idiot puts BAD code inside, and then -- naturally -- it breaks. If you work in a good company (like I do now), testers start to scream. Otherwise - customers, which is even worse. Anyway, somebody screams, and guess, what do they scream?

"YOUR service BROKE!!!!"

It's ridiculous how much of modern software development career is about visibility and how little of it is about really doing the stuff. In a few months you train testers to look into the logs and file the bugs against those, who created the problem. Yes, they are in the logs. Clearly. Black on white. Like "XXX.c line YY access violation...", and you look into version control and see the name of the guy, who last changed XXX.c. Easy, right? Not for those crying "Your service broke!!!"

Anyway, in the end, every bug is YOURS and every fix is THEIRS.

I'd love to ignore this, in fact, I tried it, well.... it DOES NOT WORK.

Don't do that. Let others pick their own crap.

Really.

No kidding.

Well, maybe at some other company in some better time... like another universe... but not now.

Do yourself a favor.