Ken Nelson

This should be on your reading list.

One of the things I’ve seen over the years is that work experience does not correlate to high quality and efficient software engineering.

So how can programmers get better?  Todd Hoff, a programmer known for his C++ coding standard (among other things), says they can get better like pretty much anybody else – with practice.

Deliberate Practice, or Experience, to be precise:

Rather than mere experience or even raw talent, it is dedicated, slogging, generally solitary exertion, repeatedly practicing the most difficult physical tasks for an athlete, repeatedly performing new and highly intricate computations for a mathematician, that leads to first-rate performance. And it should never get easier; if it does, you are coasting, not improving.

This is true, whether in programming, or in skating or shooting. Deliberate practice to build unconscious skills (aim/shoot, make ever more difficult figure skating jumps) leads to excellent performance.  Repeat at higher and higher levels to raise the performance bar.

Yet most programmers go home and forget about work. They don’t read about software engineering. They don’t expand or hone their skills.  They really aren’t interested in software engineering beyond paying the bills. And while most managers would like software people to get better, sending them to training and giving them time to practice and expand their skills can be really hard to fund.

Some say we need to require certification and continuing education, like doctors or lawyers, but I don’t think that really necessary or helpful. It would just drive up costs of an already very costly and inefficient occupation.

Frankly, I don’t think there is an answer that is satisfying. Other than for software engineers to step up and take an interest and pride in their profession and want and try to get better at it.

For now, as I hire, I try to bring in those that are interested in computer science and software engineering. They read about it, and have memberships in professional organizations, and at a basic level have a self-motivated desire to improve.

I think I’ve just discovered my next topic for the software engineering class I present to each year.

This handy chart covers the basics of the history of programming:

Just heard about “gestures” at lunch yesterday where we discussed adding to my fortune with an iPad app.  Can’t wait for that!

Gestures are things you do with your fingers on the screen that make the iPad and iTouch do clever complicated things you would normally do easily on a computer (like select all and stuff like that).  I knew about gestures, but on my MacBook they cause me grief. I learned how to turn them off on the macBook at lunch – sweet. But they look useful on mobile devices.

Here is a guide to gestures – and you need to read it if you have an iTouch or iPad cause you will NEVER sort them out with guess work.

One begets the other.

According to SigPwned, I shouldn’t be heading a software company!

Ask 100 CEOs of software companies if they want to ship software with bugs. What will they say? 50 won’t answer at all, saying something about how bugs are a huge problem in the industry that needs to be addressed; 40 will say “Of course not!” and promptly call their shark tank in preparation for a lawsuit; 9 will hang their heads and say “we can’t help it”; and that last 1 will look you straight in the eye and say “Absolutely.”

He then goes on to cover the economics of software development, as related to bugs anyway. And then proposes a “golden” rule:

Ergo, I propose the Golden Rules for Deciding When Your Software Is Ready for Prime Time. The Golden Rules state that you should keep testing your software and fixing bugs until the new bugs you find:

1. Aren’t embarrassing to your company.
2. Won’t tick off your customers.

Good advice SigPwned. But I got there a bit before you. I’ve used this rule for about 20 years now (-:   Slightly modified, we never stop testing/fixing because we never stop adding new features.  The rule of thumb I use is about 1/3rd of our engineering money goes to fixing problems the other 2/3rds caused.  That ratio has increased over  time as our feature set went up and our installed based grew (7000 customer sites).  Over time any software business becomes a service business because of feature and customer growth. That affects the dramatic profit margins seen when a product is newer, but you owe it to customers to do it and if you want dramatic profit, introduce a new successful additional product.

So don’t expect bug free software, except were profit isn’t a motive (NASA) or any error intolerable (money wiring).   It just isn’t worth it.

I’ve a love hate relationship with Google. Today I love them. This isn’t my note, just something found on the Internet. But it is this sort of small, obvious even, attention to helping the user that makes me love Google today.

Someday…

Software seems to be at the heart of the Toyota recall. And I confess to being surprised at how much software now runs in cars.  You’d think I’d know. I’m a software guy. I sell software to software developers – the car makers are all customers, as are most other software developers that put software into other products (called “embedding”).

But I was surprised when I read this article:

These are impressive amounts of software, yet if you bought a premium-class automobile recently, ”it probably contains close to 100 million lines of software code,” says Manfred Broy, a professor of informatics at Technical University, Munich, and a leading expert on software in cars. All that software executes on 70 to 100 microprocessor-based electronic control units (ECUs) networked throughout the body of your car.

Factor in this article, where decades after software first started being written, software authors still debate if they ever will develop it correctly.

You will gain and you will lose, from software in your car. You will gain antilock braking systems, and smart airbag deployment, GPS, and smart engine monitoring among hundreds of other benefits. But you will be at risk too – because all software has bugs, often as much as 1 per every 10 lines.

So buckle up!

After updating Picasa yesterday, something odd happened.  A bunch of faces appeared:

Apparently, Picasa now finds faces and tries to put a name to them. It asked me a few, mainly Brian, Jenny & Paula, and then it went off and automatically found them. It did a fine job.

But… it also told me, without a doubt, that my kids look like my wife, not me.

Every single “wrong answer”, and every single suggestion, was that Brian looked like Paula, or that Jenny looked like Paula.

Lucky kids!

 
High End Web Server Builder Guy Available

Software engineers made the Top 9 list of professions that lost the most jobs in 2009:

The profession saw a 10 percent decline in jobs to 970,000 by the third quarter of this year, down from more than 1 million positions in 2008.

But take heart… in 8 years there will be 762K more jobs for software engineers.  I’m not sure where though… India, China?

Nice picture:

Until you notice, her hand is holding a handbag strap – but no handbag!

HackerFactor believes, as I do, that you never Photoshop just one thing. So what else happened? A lot!  And they use some fancy smancy Photoshop stuff to sort out what.

Not only did Victoria’s Secret not like her skin tone, arm flab, and handbag, they also did not like her chest. They digitally enhanced her bust. Compared with the other image of the model, this image appears to be at least a cup larger. (Insert witty pun here.)

Some day I’ll show you what I do to Pics of the Day…

Bjarne Stroustrup, inventor of the C++ programming language, says that universities should focus less on creating new Computer Science (CS) professors and more on developing professional software engineers:

My suggestion is to define a structure of CS education based on a core plus specializations and application areas, aiming eventually at licensing of software artifacts and at least some of the CS professionals who produce them. This might go hand-in-hand with an emphasis on lifelong industry/academia involvement for technical experts.

I disagree emphatically with creating a licensed guild. But the rest I generally agree with.

I regularly meet with the Computer Science faculty of one local college, and I’m about to join the curriculum committee of a computer science department at another Utah college as well.  I have strong opinions, formed in the forge of wasted money on failed software projects, on what should be taught in a computer science degree.

Stroustrup pegs it:

It would contain much of the established CS curriculum—algorithms, data structures, machine architecture, programming (principled), some math (primarily to teach proof-based and quantitative reasoning), and systems (such as operating systems and databases). To integrate that knowledge and to get an idea of how to handle larger problems, every student must complete several group projects (you could call that basic software engineering). It is essential that there is a balance between the theoretical and the practical—CS is not just principles and theorems, and it is not just hacking code.

Basically, I want it hard. And what he proposes sounds a lot like what I had in college.  ESPECIALLY the more math (the hard kind) part because the quantitative reasoning it teaches seems missing from many of the graduates I hire or interview.

So what happened? Where did the rigor go?   Many (most?) of them had cook book calculus as their highest math, never getting into the exotic mind benders like differential equations, or linear methods, that put quantitative hair on your chest.

Computer Science enrollment dropped 70% since I was in school in the early 80’s.  Other paths (Information Systems, Microsoft Network certification for example) into the field caused part of the drop, but also a general recognition that industry would hire you _without_ a degree.  So why spend the time and money?

Lately, the kind of person entering the degree has changed too. They are still “geeks” but many are “gaming geeks” focused on video games.  The geeks of early CS were algorithm/logic geeks – they built puzzles, enjoyed logic, and ultimately built up languages like C++, and operating systems like Unix.  As Stroustrup suggests, for many:

"programming" has become a strange combination of unprincipled hacking and invoking other people’s libraries (with only the vaguest idea of what’s going on).

When I meet with CS faculty, I say "make it hard!”, “challenge them” and make them fix other people’s code.    Because if we are going to have less CS graduates, lets at least make them top notch.

Apparently, spaghetti of the Counter Insurgency inter-relations in Afghanistan:

means you can’t win a war.

But spaghetti like this, of the Model E GISS climate modeling simulation source file interdependencies, should be trusted implicitly:

I know war can be complex. And I’m quite familiar with how thorny software complexity can be.

But if you have concerns about the one, shouldn’t you about the other?

I know… I ask too much!

BTW: This is not to impugn the folks at NASA who expose themselves by posting their source code on the net.  I don’t know any specific issue about the quality of the NASA software. I can, however, measure its complexity. And I can guarantee you, at the level of complexity measured, it probably has hundreds of significant bugs. As does virtually ALL software of similar complexity and size.

Software graph done by “Understand” from Scitools.

The poster shows John McCarthy, inventor of Lisp. Lisp differs from most other programming languages as much as Xhosa from English.

Interesting…. are they trying to make sure people really read it, or just joking around? 

The Alliance for Code Excellence will now sell you Bad Code Offsets letting programmers everywhere offset bad code they have written:

Only 50¢ per SLOC (source line of code)!

But what the Alliance misses is that they need to tax programmers to make this work.

Google is finding out that owning the hardware AND the software gives Apple an advantage:

“A slew of problems have made managing Android apps a “nightmare,” they say, including three versions of the OS (Android 1.5, 1.6 and 2.0), custom firmware on many phones, and hardware differences between different models.”

Fragmentation is also the reason Linux has failed to make significant inroads into the PC desktop, but OSX is considered a big success even though both are based on the same Unix technology.

Android appeals to me on a conceptual level, but Java based systems always are slow. Slow doesn’t appeal.  It also tries to do a lot, and lets the developers do a lot, which is appealing, but can also lead to bloat and… slow.

H/T: Jim B.