Who’s Your User, Daddy?

All software is developed to be used by someone, even if only in an automated fashion (that is, without any direct interaction with the user). As such, it is important to understand who your user is, or you may (ok, probably will) find the going tough. If you are a game developer, life is good. You know who your users are – gamers! Likewise, there are many industries or types of programs where the user is a well-known entity. If you write accounting software, for example, your user is probably someone who does…uh…accounting.

I happen to work in an environment where the real user of the software is often a bit of an unknown. Well, the real user is generally known, but often we are unable to get direct feedback from the user, or the feedback loop is very tenuous and arrives filtered through other people who generally are not developers and rarely elicit the right kind of feedback or ask the users the right kinds of questions. The situation can be so backwards, in fact, that some of the developers I’ve worked with over the years are convinced the user is, in fact, the middleman who filters all that rarified feedback. Developers will say things like, “I’ll have to talk to the users about that.” Of course, they’re never going to talk to an actual user, just the business people who are in control of the project. In the real world, these people would be called stakeholders, but even in other companies, I’m willing to bet that the stakeholders are actually treated as if they were the users.

Stakeholders may feel they have deep insight into how real users will interact with the software, but, unless they spend a lot of time with real users, they are typically just guessing. That’s bad enough, however, the real problem occurs when the stakeholder has a vested interest in trying to shape the software to make their own job easier. While that’s understandable, and their opinion does matter in that respect, it doesn’t serve the actual user of the software. A common symptom of this affliction are screens that fit the stakeholders workflow, rather than the end user’s workflow, or forcing the end user to enter all kinds of data that may not be readily available to them. The stakeholder wants every possible piece of data up front, whether they truly need it or not, and these become required fields. End users will frequently come up with creative ways to get around the restrictions, which ultimately helps no one, because it ends up being extra noise to filter out.

Unfortunately, developers have no say in any of this, and most will simply do as they are told. I’m not sure what can be done to change this attitude, but it’s ultimately counterproductive, and developers like that end up revisiting things over and over as they try to tweak things and plug holes – problems that might have been averted by paying more attention to making sure the software actually was developed for the right user.


Three Types of Comments You Can Stop Doing Right Now!

All right, step away from the double slashes and no one will get hurt! Over the years, I’ve seen plenty of bad commenting practices, and I’ve been guilty of doing some of these, myself, but it’s time for us all to just move on and simplify our code in the process. Consider each of these a type of smell in the code, to the point where the code can smell like New York City after a month-long sanitation strike.

Here they are, listed in no particular odor (pun intended):


Commented out code

Why, oh why, do we need to keep commented out code in our production code? Even in the days before source control was common, this was an insidiously evil way to mire down maintenance programmers, or even yourself. Now that we use source control on a regular basis, there really is no need to keep hanging onto this stuff.

The problem is, most programmers will just leave commented code right where it is. Partly, this is simply out of fear – fear that somehow the code has meaning, it might still be needed, or it’s something someone was working on. Another reason programmers won’t delete the unneeded stuff is they simply don’t feel it’s their responsibility (“if it ain’t broke, don’t fix it”). New programmers will think that leaving in commented out code is some kind of standard, and they will start doing it all the time, as well. After a few years, some files may consist of almost as much commented out code as real code, if not more.

The fact is, commented out code doesn’t do anything, so it’s really just visual noise. It makes real code harder to read. Commented out code shows up in searches, which can cause a little extra confusion. It also makes it a bit more difficult to do code compares.

So, just say no to commented out code. Go ahead, rip it out. No one will miss it. If anyone truly needs to reinstate it some day, it’s right there in source control. They can copy-paste it right back where it was, and probably discover all over again why it was commented out in the first place.


The historical marker comment

Here’s an example of this type of comment:

if (index < maximum) // Added 1/1/2014 XYZ

These comments are completely unnecessary, assuming you’re using source control. Then, we can see who to praise or blame, as the case may be. As with commented code, this stuff can really start dragging down the readability of the code, without adding a single useful tidbit of information about the code.


End-of-block comments

These comments can be found decorating the end of do, if, while, for, foreach (or the equivalent), enum, struct/type, switch/select statements, and even methods or functions. If you’re not sure what I’m talking about, pay attention to the comment at the end of the while statement:

while (index < 100)
// Do some stuff for the next 2000 lines…
} // while (index < 100)


Maybe you really do need to see that comment to let you know when your 2000-line while loop is finally over, but if that’s why you’re doing it, there are now two reasons why we’re going to send you to bed without your video games, your iPod, your Droid, or your quad-copter.

The bottom line is, if you keep your methods and your block statements short, it should be no problem for the average programmer to see both where a block starts, as well as where it ends.

These comments actually add more density to the code, making it harder to read. On top of that, they do not add any new knowledge to what or why the code is doing what it’s doing. Worse, when people change the stuff going on in the top statement, they frequently forget to update the comment. And if you have nested block statements and discover you need to swap things around? Yep, you have to make sure the comments go along for the ride. In other words, using these comments also adds to your maintenance woes.

Keep your code blocks short, and just get rid of these comments. After a while, you’ll find you don’t miss them.

5/1/2014 Article Links


I’m reading a book on anti-gravity. I can’t put it down.


Web and mobile stuff:

var functionName = function() {} vs function functionName() {} (This ought to be worth reading at least 17 times)

How Adobe Is Moving on From Flash to Embrace HTML5 (Let’s all pan the flash)

Wearables offer hazy hope for mobile chip growth (Ah, yes, a chip off the old frock)

Why Smartphones Are About to Get Tacky as Hell (Crass dismissed – please!)

The Future Of Mobile Advertising Will Be Shaped By Two Trends (Thing one, and thing two)

12 Chrome extensions power users will love (Great spelling error in the initial screen. Maybe they can find a spell-checker for their graphics editor in their search for the next 12 extensions)


F# stuff:

Another Porter Stemmer in F# (Excess baggage not included)

Code coverage using dotCover and F# make (Covering yourself with nothing but a dot – not just for nudists, anymore)

Simple Parallel Array Filtering in F# (Slowing making our way toward complex parallel universe filtering)

F# scripting for a component based game engine (Because it’s fun)

F# and List manipulations ((Sometimes, it’s OK to be manipulative)

Facilitating Open Contributions for the F# Compiler, Library and Visual F# Tools (We open at Effin’ 5 O’Clock Sharp)

Where to practice your F# with fun? (Under the blanket, with a flashlight?)

Twenty six low-risk ways to use F# at work (Feel free to try this at home, too)


Other stuff:

Programming Sucks (Yep. And yet we love it.)

IoT Startup Evrythng Secures $7M Series A From Atomico, BHLP, Cisco And Dawn 

Report: Google Glass parts make up 5.3%—roughly $100—of $1,500 price tag (Sounds like a glass half full kind of thing)

America’s nuclear arsenal still runs off of 8-inch floppy discs (Sure, why not? They could come back in style some day.)

Sony develops tape tech that could lead to 185 TB cartridges (And in other back-to-the-future news…)

Good news: IT businesses see growth. Bad news: They can’t find people to hire. (Must be a shortage of twenty-somethings who skateboard and suck down energy drinks)

Millennials and tech: Round pegs in a square cubicle farm (I don’t think hatred of cubicles is restricted to millennials)

4/23/2014 Article Links


A woman was suffering from a pain in her abdomen. Along with a battery of other tests, the doctor ordered an X-ray. She went into the doctor’s office to review her case. When she entered, the doctor was talking on the phone and the lady noticed the X-rays laying on the desk. The woman smiled as a kitten walked around the edges of the X-ray, staring down at the picture. The lady thought it was cute, although a bit odd that the doctor would have a kitten in the office. Anyway, she talked to the doctor and decided on a course of action, and the lady went home. Two days later, she received the bill in the mail. For some reason, the X-ray cost $5000! She immediately called the doctor’s office to find out what was going on. They informed her that the cost was extra for the cat scan.


Web and mobile stuff:

TypeScript 1.0 Released and Open for Contributions

Coding error protects some Android apps from Heartbleed (Hmmm, like two sound waves cancelling each other out)

Go 1.3’s first beta promises a sleeker, faster language (Go ahead, have a go!)


F# stuff:

What is FSCL? (F Sharp to OpenCL)


Alea.cuBase 1.2.680 Released (I CUDA had a V8!)

How to design a language integrated compiler with LLVM (Show it a little LLOVE)

GPU Applications for Modern Large Scale Asset Management (One manager says to another, “I see you’ve finally made an asset of yourself.”)


Other stuff:

In programming, a little guidance goes a long way (Ironically, lack of guidance can take you even farther, because you’ll be instantly lost)

When the solution is the problem (1 = 1)

Verizon: Web apps are the security punching bag of the Internet (Big surprise)

Do more with less: Lambda expressions in Java 8 (Speak up about this topic. The silence of the lambdas must end!)

GNU Compiler Collection gains major new functionality (Good Gnus)

Be careful what you wish for: The dream job that wasn’t (I missed it by *that* much!)