Improving Wetware

Because technology is never the issue

Back to the future (again)

Posted by Pete McBreen 02 Dec 2015 at 20:27

Delving into the archives, Leslie Lamport wrote about the Future of Computing back in 2003. There are still too many programs that are not understood fully by their developers or maintainers.

Firefox is going to lose a lot of developers (and users)

Posted by Pete McBreen 25 Nov 2015 at 19:01

Somehow or other the Firefox community has convinced itself that scanning add-ons for vulnerabilities and malware is a good idea. Luckily Dan Stillman the developer of Zotero called them out on it pointing out that it is just Security Theater.

Firefox has always had lots of really large extensions, but by deciding that they must be signed and reviewed, the Firefox community has just committed itself to a LOT of extra work reviewing the extensions. Hence the dumb idea of scanning to see if there is anything malicious in it. Now that is an arms race that is going to be lost. The guys in the AdBlock game know that, a continual game of whack a mole. Actively developed extensions like Zotero really lose out because a manual review of a large codebase takes a long time, and scanning is insufficient (as the above link describes, it is easy to create an add-on that passes scanning and does nasty things).

Breaking news...programmers are not engineers

Posted by Pete McBreen 07 Nov 2015 at 15:59

The Atlantic just realized that programmers are not engineers

Sorry to break it to them, but this has been a topic of conversation long before I wrote the book Software Craftsmanship, which was published nearly 15 years ago.

I had forgotten about the Coding Horror website

Posted by Pete McBreen 30 Jul 2015 at 13:28

And then this article about testing — Doing Terrible Things To Your Code reminded me to look at it again.

QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.

I sure wish more programmers would focus a lot of attention on testing their own code before passing it on to QA/Test. That way the QA/Test team can focus on finding the requirements and interaction defects, rather than the simple coding mistakes that are often the bane of their existence

So much universe, and so little time

Posted by Pete McBreen 12 Mar 2015 at 19:52

AT LAST, SIR TERRY, WE MUST WALK TOGETHER.

Some quotes from Terry Pratchett

  • The whole of life is just like watching a film. Only it’s as though you always get in ten minutes after the big picture has started, and no-one will tell you the plot, so you have to work it out all yourself from the clues.
  • The presence of those seeking the truth is infinitely to be preferred to the presence of those who think they’ve found it.
  • It’s still magic even if you know how it’s done.
  • There are times in life when people must know when not to let go. Balloons are designed to teach small children this.
  • YOU HAVE TO START OUT LEARNING TO BELIEVE THE LITTLE LIES.
  • The truth may be out there, but the lies are inside your head.
  • Goodness is about what you do. Not who you pray to.
  • I have no use for people who have learned the limits of the possible.

Kevlin Henney - Seven Ineffective Coding Habits

Posted by Pete McBreen 15 Feb 2015 at 18:49

Kevlin Henney - of Curly Bracket Languages fame has a good video of his presentation at a recent NDC conference Seven Ineffective Coding Habits of Many Programmers. As usual a very entertaining talk, but Kevlin is also spot on in identifying ways in which we are lead to make incorrect decisions about the code we are writing.

In it he references a paper from Rob Pike Notes on Programming in C. Although Rob Pike wrote that paper back in 1989 it is still relevant, as can be seen by his words about variable names:

Length is not a virtue in a name; clarity of expression is.

Craftsmanship in other fields

Posted by Pete McBreen 08 Feb 2015 at 13:15

Interesting long article on a Kitchen Bladesmith, describing the expertise that goes into making kitchen knives, especially those for the chef market.

The Hard Way is Easier...

Posted by Pete McBreen 19 Nov 2014 at 21:00

Zed Shaw has written an introduction to his Hard Way series and in it he writes

The one skill that separates bad programmers from good programmers is attention to detail. In fact, it’s what separates the good from the bad in any profession. Without paying attention to the tiniest details of your work, you will miss key elements of what you create. In programming, this is how you end up with bugs and difficult-to-use systems.

A different take on software engineering

Posted by Pete McBreen 11 Nov 2014 at 09:25

In The Leprechauns of Software Engineering Laurent Bossavit has an interesting take on the folklore of software development.

A different view on testing

Posted by Pete McBreen 28 Sep 2014 at 19:16

The Beauty of Testing article has a different take on testing;

Test, to put it simply, is the conscience of a product.

Understanding the problem

Posted by Pete McBreen 01 Jul 2014 at 19:52

Software development is a hard problem.

Books like The Mythical Man Month, Set Phasers on Stun and The Inmates are running the Asylum have all pointed out in their own way that creating software is hard. Fred Brooks focused on the problem of large complex projects, and the problems that face project managers, the other two remind us that even small projects can fail because we still are not able to create software that is both easy to use and powerful enough to do that tasks that we want to do with software.

Until we are able to understand why software development is such a hard problem, we are not going to make much beyond incremental improvement. There will always be a few projects that through the operation of blind luck across millions of projects that results in seemingly reproducible improvement, but the normal regression to the mean will correct that eventually.

Craftsmanship around the web

Posted by Pete McBreen 29 Jun 2014 at 20:17

I didn’t see this when it was first written, but it matches with my recent experiences.

… most programmers simply don’t know where the quality bar is. They don’t know what disciplines they should adopt. They don’t know the difference between good and bad code. And, most importantly, they have not learned that writing good clean code in a disciplined manner is the fastest and best way get the job done well. – Robert Martin

Software Craftsmanship depends on developers knowing the craft of coding

Posted by Pete McBreen 04 Jun 2014 at 19:47

Many software developers do not seem to understand the basics of our craft. Recently I’ve seen

  • SQL queries that were massively more complex than they needed to be - that when simplified, without any database changes ran more than 10 times faster
  • Client server applications that issue nearly 1000 SQL queries while refreshing what is supposed to be an interactive screen - the end result being that the poor user has to wait 5 to 10 seconds for the screen to refresh after conceptually simple actions
  • Supposedly secure web applications that sent Active Directory usernames and passwords in cleartext across HTTP connections
  • Code that created connections to external resources but forgot to free them - made for a very effective rate limiting mechanism since the external resource freed unused handles about an hour after they were last used

There have been lots more examples, but most of them fall into the category of being unbelievable if you were not a direct witness to the utter ignorance of the basics of software development that brought them to my attention.

Maybe it is time that we started to focus on the basics of the craft of coding before we get too far into creating overly complex systems that nobody can understand or fix.

We can learn a lot from Healthcare.gov...

Posted by Pete McBreen 21 Nov 2013 at 20:10

But I’m not sure we will learn the right lessons.

In the early 1980’s I worked on applications that had to process 300 transactions per minute. At the time that was considered a heavy load for a Dec Vax to deal with. By the late 1980’s the same applications were dealing with 1,000 transactions per minute because the hardware had got a lot faster. In the mid-1990’s I worked on a small scale credit card processing application, running on a later incarnation of the Dec Vax that was able to handle nearly 20 transactions per second. In the late 1990’s I worked on a stock exchange system that had to deal with what we thought at the time was a stupidly large number of messages per second … little did I know. Fast forward to the early 2000’s and I worked on consumer facing web applications that had to withstand 10,000 requests per second. By 2010 I had the fun of being on a real web scale project, experiencing the joys of being linked to by Digg and CNN and hoping that the ensuing millions of requests per hour would not being the system down.

All this is to say that dealing with internet scale applications is a solved problem, but it seems that whoever was involved in the Healthcare.gov fiasco did not realize that. Dave Winer pointed out that the Government develops software differently, but there is no excuse for building a site that cannot handle the traffic.

I disagree with Bob Goodwin - there is no software engineering crisis - OK I have to say that because I wrote the Software Craftsmanship book. But that is not the real reason I have to disagree - I have to disagree because whoever built the site went about it the wrong way. Dave Winer parodied the approach that big consulting companies take

They’d fully specify the software, the user interface, its internal workings, file formats, even write the user documentation, before a single line of code was written. Then they’d hand the parts off to development teams who would independently of each other create the components. Another team would do the integration.

The sad fact is that the big corporations that are awarded these big government contracts do not have a clue how to build web scale applications that work. They over promise and massively underdeliver. All too often large companies are awarded contracts to build large systems and fail to deliver anything of value except to their own shareholders.

Apple messes up with Pages UI - stupid ideas #451

Posted by Pete McBreen 01 Nov 2013 at 17:05

Just had to help someone with Apple’s Pages, not sure what version, but they were not able to save a separate version of the file to keep two slightly different versions of a document. Turns out that Pages no longer has a Save As… file menu option, instead it has a Duplicate and Rename menu option.

Which designer in their right mind thinks that it is a good idea to change a thirty year old idiom that their entire userbase is familiar with?

Best bit of this insanity is that the shortcut key for Duplicate is the same as what used to invoke the Save As… dialog box, but of course the behavior is different.

Software Craftsmanship - Simplified Chinese edition

Posted by Pete McBreen 20 Sep 2013 at 19:24

Hot off the press, there is now a Simplified Chinese Edition of Software Craftsmanship - amazon.cn link. ISBN is 978-7-115-28068-8 for anyone who is interested.

The link is also proof that international alphabets are now supported in URLs - http://www.amazon.cn/软件工艺-Pete-McBreen/dp/B00AAQXL28

Are they trying to put people off programming?

Posted by Pete McBreen 27 Feb 2013 at 21:21

Dave Winer calls it like it is - the wrong people are behind code.org, and their pitch is not even wrong.

But I don’t like the way people at code.org are pitching it. And I don’t like who is doing the pitching, and who isn’t. Out of the 83 people they quote, I doubt if many of them have written code recently, and most of them have never done it, and have no idea what they’re talking about.

These people don’t themselves know how to do what they want you to do. So what they say makes no sense. It won’t make you rich, but it will make them rich. And if you do it, they won’t listen to you. And even worse, if you do what they want you to do, you’ll be tossed out on the street without any way to earn a living when you turn 35 or 40. Even though you’re still a perfectly good programmer.

The Economist does not understand numbers

Posted by Pete McBreen 20 Jan 2013 at 11:26

From Difference Engine: Edison’s revenge

It is true, and was the basis of Edison’s showmanship, that low-frequency alternating current can be more hazardous than an equivalent direct current. By oscillating at a similar (ie, close enough) frequency to the human heart, a sufficiently strong alternating current can cause that organ to beat arhythmically and thereby induce ventricular fibrillation—a potentially deadly condition that needs to be corrected immediately.

This is the improved, edited version. How can a journalist equate 50 to 60 Hz to be close to the frequency of the human heart 60 to 120 beats/minute (1 to 2 Hz).

With corrections like this, I remember why I stopped reading the Economist.

Slides from Agile Calgary talk

Posted by Pete McBreen 07 Dec 2012 at 16:44

Gave a talk at Calgary Agile Methods User Group, slides from the talk are now available - Applying Craftsmanship - 20MB PDF

Making a Game of Disaster Recovery Planning

Posted by Pete McBreen 16 Nov 2012 at 20:29

The Atlantic has an article called When the nerds go marching in that tells a story about the comparative approaches of the Obama and Romney teams and how they built and tested their systems in the run up to the 2012 US presidential election.

Obama team had an interesting approach to the planning - Making it a game

Hatch was playing the role of dungeon master, calling out devilishly complex scenarios that were designed to test each and every piece of their system as they entered the exponential traffic-growth phase of the election. Mark Trammell, an engineer who Reed hired after he left Twitter, saw a couple game days. He said they reminded him of his time in the Navy. “You ran firefighting drills over and over and over, to make sure that you not just know what you’re doing,” he said, “but you’re calm because you know you can handle your shit.”