C++ is a psycho hose beast

C++, you and I go a ways back. We've been together since before I finished my degree. Since before I got married. I had great times with C++ in college, and we were hanging out pretty much exclusively during my first 3 years as a professional, and I thought things were just great the whole time since we'd met, 12 years ago. That's a pretty freaking long time to be deluding myself into enjoying a dysfunctional relationship.

I've had enough. You suck, C++. We're getting a divorce.

I'll be civil about the whole thing, and we'll still deal with one another to support the kids (legacy projects). Maybe you'll still have a happy life in low-level systems code, but I just don't love you any more, and I've got to move on with my life. But before we split, it's only fair that you know why I'm taking such drastic measures.

How do I hate thee? Let me count the ways...

1) You can't decide who you are.

Any time we're with our other compiler friends, you are maddeningly inconsistent in your behavior. It's seriously creeping me out when I hear about the multiple lives you're going on with. I talk to one buddy and he says that you've adopted the standard namespace and no longer want to deal with your old friend and all her friends. Another says you told her you've never heard of the standard namespace, and you're as close to the old ".h" gang as ever. And now I heard that you actually acknowledged the existince of the "export" keyword with that one pedantic friend, and now that's all he'll talk about when we meet. It's like you brainwashed him into thinking it's commonplace.

I'm tired of trying to remember which compiler we're hanging out with, and having to walk on eggshells with the preprocessor so you don't blow up. No more. My next significant other will be somebody that not only has standards, but sticks to them.

2) You live in a constant state of self-denial

The other day I wanted to ask you about an enumerated type, to see if you'd defined a particular name. Of course, you would have covered your ears and done your "I don't know what you're talking about" routine. Just once, it would be nice if I could give you a string, and you could tell me if a class had that particular method, attribute, whatever. Instead, you basically tell me screw off and do it myself. Introspection opens up all kinds of amazing framework and metaprogramming possibilities, but you're utterly incapable of doing this without help from clunky libraries.

3) You don't know what strings are.

Speaking of strings, what the heck is your problem? Every time I want to use one, I have to use a null-terminated pile of garbage, or a std::string with a horribly bloated interface, or any number of nonstandard third-party solutions with different interfaces and conventions. I shouldn't have to put up with this every time I want to do some high-level string manipulation.

4) You barely know what arrays are.

Arrays are just pointers to the data with no comprehension of the length of said data? Seriously, do you know how crappy that is? You make two-dimensional arrays needlessly cumbersome and obtuse. How tough would it be for a minimal, non-resizeable version of std::vector to be a first-class citizen? Heck, just making them objects that are aware of their own size would make "ProcessArray(int data[], unsigned int length)" a thing of the past.

5) Your templates are uglier than Sam the dog

Sure, at least you have templates, which is more than Java could say before generics. But holy crap, do they have to be so freaking nasty? And I'm just talking about usage, not implementation. I hope I never again have to type "for(std::map>::iterator ix = data.begin(); ix != data.end(); ix++)"(note: The fact that I forgot to use the preincrement operator instead of the postincrement is yet another stupid detail I have to devote brain cells to) just to set up a loop. Frankly, I'm amazed that people have produced compilers that can make sense of your nonsense.

6) Crappy dependency resolution

I could just #include everything I need, but then every time I make a change half of the project gets recompiled. Admittedly, this isn't a problem until I, oh, get out of school and enter real life, and have to work on sizeable projects, and then it takes 15, 30, 60 minutes, or even hours if you've got a really gnarly program. Way to kill productivity, jerk. And even with #include peppered all over the place, if I get a circular dependency loop, I still have to throw forward declarations in there to get by. Then I have to keep track of when to give you a forward declaration or an inclusion. When I'm subjected to this kind of micromanagement, how does this help me?

7) The neccesity for design patterns

Let me make this clear: I don't hate "Design Patterns", neither the book or the concept. What I do hate is that these are even neccesary in C++. A lot of these patterns are simple to use and don't require a cookbook if implemented in another, more capable language, unlike you, you decrepit heap of ineptitude. I guess this is nitpicking, but I'm at the limits of my attention span on this blog post, and I felt I just had to throw one more reason in there. I could probably go on all day, but then I'd get all weird and incoherent on my imaginary audience, so I'll just take a deep breath and move on to my conclusion. Let's get this rant, er, break-up over with.

(deep breath)

Programming language monagamy considered harmful

Ruby looks like a really cool language, and I'm going to start playing with it more, and hopefully use it on some lightweight applications. Yet, as great as Ruby looks, I'm promising myself that I won't ever get married to another language. I need to broaden my skillset some more, wrap my mind around different paradigms, that kind of thing.

I've heard it said many times, in various forms, that I don't neccesarily need to use Lisp for real work, but I need to learn about it, get comfortable with it, really explore what makes it different from the C family of languages, and it will make me a better programmer. That's next on my list, after I try building a few decent-sized apps in Ruby. Maybe I'll try Haskell or OCaml next.

It's hard to get away from the safe languages, like C, C++, Java, Perl, etc. That's what employers want, because they're popular, and they can pick up just about anybody that can read some C, and have a vauge idea of what's going on. It's hard to use some of these more different languages at many companies, which is understandable, because for all of it's groundbreaking amazingness, who has real world work experience with OCaml? Speak up. Anybody? That's what I thought.

But if we had fewer language monagamists out there, more die-hard language bachelors of the kind I'd like to become, this wouldn't be as much of an issue. We might just find ourselves asking each other why the heck we're still using Perl, when Ruby does everything Perl does with practically none of the downside. And then some of us start using these new languages on some low profile, internal projects, and it works, and we start using them more and more, and suddenly it reaches some sort of critical mass and a language like Ruby completely supplants an inferior cousin like Perl.

It could happen, and I hope it does.

Plausible software scheduling for rookies

Anybody with a few years of experience has had the displeasure of being held to overly optimistic development schedules. Sometimes it's endemic to the organization, possibly as a result of having to submit ridiculously low bids in order to secure any work whatsoever. Sometimes it's the result of a simple brainfart. Sometimes it's the result of having giant alien space ants in your organizational chart that callously give out unreasonable demands to their human underlings. (I, for one, welcome our new insect overlords. I'd like to remind them that as a trusted code monkey, I can be helpful in rounding up others to...toil in their underground sugar caves.)

This post won't contain anything new to all of you awesome code gorillas with 15 years of experience. Consider it a rant. Remember, this is the blog of a journeyman code monkey, not a super-duper guru code monkey. I aspire to reach your exalted plane of existence where we can have these great conversations I made up in my mind:

• "Ho, ho, yet another little code monkey just saw The Mythical Man-Month for the first time."
• "How quaint. I can't wait until he goes through his 'Lisp is the most beautiful language EVAR' phase." *flings code gorilla poo* "Let's go back to writing mind-bogglingly expressive, functional, concurrent, mind-reading languages in our spare time."
• "Superlative idea, old chap!" *flings code gorilla poo*
• "I love Emacs!"*flings code gorilla poo*

Now that's the life. Listen to my nuggets of quasi-wisdom, little rookie monkeys, and someday we'll be able to have these incredibly deep coding discussions out loud. Awesome, huh?

Vacation/leave
Assuming 2 weeks of vacation and 2 weeks of sick leave per year, you can count on 4 weeks per year, on average, that each developer will be out of the office. Throw in another 10 days of various holiday leave, and 6 out of 52 weeks of the year are gone. Poof! Write them off now. That's 11.5% that the project is not going to get back.

Management can always disallow vacations when the project starts falling behind, calling developers in on sick days, working holidays and weekends, etc. However, if schedule-affecting factors are habitually ignored, these measures quickly become a permanent state of affairs, a perpetual death march, mass hysteria, dogs and cats living together! The end result of this is our next item...

Developer turnover
It's a fact of life. Developers are going to leave, and management will need to hire new ones. Face it, 20% of your people are going to be recycled within the next year. Some years more, some years less, but that's going to be your long term average. If it's significantly more, maybe you work for Electronic Arts, if it's much less, you must work for Google, that fabled realm of free gourmet lunches, super geniuses with complete intellectual freedom, and disgustingly amazing stock benefit options, or some other fairyland that a real programmer wouldn't be caught dead working for, and you should leave a comment telling me who I should send my resume to.

Losing strong developers has a huge impact on project schedule that I'm not sure how to quantify just yet. But it's there, and it's significant.

Nasty surprises
So I'm working out in the yard, digging up some roots,trying to make up for ineptitude by putting on displays of brute strength, without much success, (or much brute strength for that matter), and I've encountered this root with a bad personality. I'm hacking at this thing, pulling it up, and it goes on and on. It's hard work, but I seem to be making some progress when my wife comes out to tell me what an amazing hunk of a man I am. I know it's coming - she's got that look of awe and wonder in her eyes. As I hold up the trophy root, she sings my praises - "Honey, why are you destroying the sprinkler system?"

Oh. I thought roots were supposed to be black and rubbery.

Well, looks like the whole weekend is shot to crap. Now I have to make 20 trips to Home Depot, trying to figure out what piece I'm supposed to buy while my handy neighbor wonders how this hopeless wreck ever managed to live past the age of seven.

This happens in software, not always, but often. Attempts to extensively plan your design to account for every single possible eventuality will rapidly demonstrate diminishing returns, to the point where all that time spent planning kills your productivity, and you would have been better off spending some of that time on rapid prototyping and other forms of actual development. (The extreme opposite of over planning is "Agile Programming", which comes with its own problems)

Surprises will affect your schedule in bad ways. The good news is that you can attempt to account for this by collecting data on your past estimates, being disciplined and consistent in your estimating methodologies, collecting data on time spent on unplanned surprises, and figuring out an average percentage of buffer time you need to build in to your future estimates.

Distraction
As you come up with more refined plans, and dutifully track your work time, you'll notice that a lot of your time is spent on things not in your original plan. Some of this is in the form of unplanned development surprises, as covered above. Some if it is in other tasks, checking email, workplace training, meetings, answering the phone, random conversations, office chair demolition derbys, you get the idea. The end result is that, as an industry standard, developers, on average, spend only 15 hours out of a 40 hour work week toiling on tasks that were planned beforehand.

This means that if you've got a task that you've planned out at 80 hours of effort, even after adjusting your effort estimate to correct for your own built-in estimating inaccuracies, there's no way that sucker is going to be done in two weeks of normal 8 hour days. On average, you're gonna need 5-6 weeks to get that done.



This is list is by no means comprehensive. But accounting for these factors gives you a start at making more realistic estimates than I did, all bright-eyed and bushy-tailed, straight out of college.