Why Your Software Sucks: Intro

Frustration (was: threesixtyfive | day 244)Your software does suck. You may not think it does which is exactly why it sucks. Of course, no one means for it to suck - I have yet to hear someone, either in business or software engineering/development, say, "We require this software to suck". Invariably, it does, and sucky software has kept me employed for decades. Some of it I got to fix. Some of it I got to redesign. Some of it continued to suck, some of it sucked more and some sucked less.

But yes, software sucks.

Two articles worth reading on this are 'Why the Great Glitch of July 8th Should Scare You' and 'Everything is Broken'.

Why does software suck? We have terms for why software sucks - that's how much we know it sucks. It falls down to:

  • Technical Debt: This is the result of business and developer decisions to do things quickly instead of properly in the hope that they will fix them someday (if they're even aware). This is a big one for startups as they enter their sustainable phases. In my experience, this issue tends to be enforced by management, and later on the software engineers who did not create the debt are forced to pay for it. The original people who worked on the code have probably moved on to that greener pasture across the fence.
  • Complexity: Aside from NASA and whatever commercial ventures are going into space, software does not exist in a vacuum. Further, users almost always use the software in ways in which it was not designed for. In an increasingly software 'rich' world, this is almost always a problem.
  • Not Fixing Real Problems: I've heard phrases along the lines of, 'Chasing the Shiney' so many times and yet it always surprises me how the Shiney is never the underlying issue that needs to be addressed. At one particular company I worked for, we hated when our management flew anywhere because they'd read the magazines on the planes and think that they had a grasp on what was wrong. They trusted the magazine article more than they trusted their own people. 

Almost all of this could be fixed by better software engineering practices combined with management actually trusting the people they hired to think about these things and acting on what is being said, but that requires a culture shift. The bad news is that the software will still suck and that it will be more expensive. The good news is that the software will suck less and be less expensive to maintain in the long run.

C++: Not Dead

dennis_ritchieWith all the new languages that have come up since I started programming, I can't help but remember reading Dr. Dobbs Journal in the mid 1980s. The worth of C++ was being debated.

About 3 decades later, 'The Beast Is Back' according to this O'Reilly book. And yet, the India Times complains that Indians are writing in the language of the past: C++.

Nevermind that C++ has a heavy code base. But the India Times doesn't seem to understand what that means.

It makes you wonder, doesn't it? It should. After all, Facebook is working with C++. C++ is getting extended.

Why is it that C++ is such an ugly duckling for some?

Since over the years I have coded in more languages than most, I think of C++ as a manual transmission on a car. You can directly access the power under the hood and use it as well as your skill permits. You can dig into the hardware directly (if your operating system lets you). And, you can shoot yourself in the foot. A skilled C++ developer can do a lot, quickly - but it takes more time to do that. It's fast. Yes, it's faster than C#/.Net (long read) in most cases.

I joked with someone not long ago after cleaning a whiteboard, ".Net developers don't know how to clean up after themselves". A seasoned C++ developer is used to being responsible for their code rather than being dependent on someone else to be responsible - particularly when that someone doesn't assume liability.

This is not to say that C++ should be used for everything. Far from it. Yet it is not a dead language. If you need things done fast, C++ is still the way to go - particularly if you bother to design the application properly so you don't have to keep changing it.

No, no, C++ is not dead. It has lived longer than the .Net framework despite not having a marketing department.


The Right Question To Ask About Communication.

Museum of CommunicationsI read two posts in the past week that had me thinking about communication - and some real world experience to add weight to it. The first post is Social Discourse 101: Listening to Your Adversary - a title that says more than you may think when you consider if you're 'listening to an adversary', you may not be listening at all. We don't listen to adversaries. We argue with them, and when we argue we have our filters on.

Read The Argument Culture: Moving from Debate to Dialogue. Really.

The other post is, amusingly, Email is Broken, It Needs To Die, and We'll Be Sorry When It's Gone. As a species, we're very good for blaming our child technologies for our inability to communicate properly - and our answer is typically to birth Yet Another Technology that fails to meet our needs and adds another technology babel where we already have cultural and linguistic babels.

And the real world? Who hasn't been to a meeting where two opposing sides have strong opinions and refuse to find the middle ground? Who hasn't been constantly interrupted by someone who thinks talking loud makes you agree? I could explain it away as people suck, but people don't suck as much as we think. We think they suck when they don't agree with us, which is all about ego - invariably, you'll hear people who have these problems use 'I' and 'me' until they're blue in the face. For people like me, I find it annoying, and that becomes a problem for me because I don't want to listen to annoying people.

Oh look. There's my ego.

So should I adapt a technology to be heard? A bullhorn? Then they'll get a bullhorn. The escalation will continue until there are dueling nuclear monologues.

There's something to be said for communicating properly. Some people aren't good at it, and they're not good at it because they think that their method is working. Sometimes the best strategy is to demonstrate to them that their method is not working.

How do you do that?

Now that's the real question we should be asking.

It's not technology. It's people.