March 29, 2009

One of the few cogent points to have emerged form the recent spasm of interest in so-called Software Craftsmanship is the idea that a “craftsman” has a line that they will not cross, things that they will not do. I tend to agree.

It’s not the point of his piece (please read his whole post) but Keith makes a nice summation.

I consider myself a software professional. My professionalism includes my skills, experience, and judgement. My professionalism is one of my assets. It is not conferred by my employer. When I change positions or jobs, my professionalism stays with me. I’m accountable for the state of my professionalism as an asset of my personal self. It is in my self interest to improve and grow but also not to perform in a manner that is harmful, destructive, or unethical as a software professional.

I continue to be inspired by Reg’s raganwald blog. Thank you Mr. Braithwaite. But Reg has moved on and is no longer actively posting to raganwald.

I miss his blog but if I’m serious about my own blog (and there’s doubt about that) then I’m glad my blog is not competing with an active raganwald (and I don’t compete with raganwald in any literal sense.) In the audio of Mann and Gruber’s talk, Merlin says something like your blog needs to be better than 80% of the other blogs that are focused on the same obsession. I recall Scott Adams, creator of Dilbert, writing that he greatly admired Gary Larson’s The Far Side and Bill Watterson’s Calvin and Hobbes and was consequently very glad when those strips ceased and ‘left the field.’

My blog, this blog, is not raganwald but like John Gruber’s New Yorker, it is a point of inspiration.

March 23, 2009

The most contentious point between software engineering culture and visual design culture is the question of whether important things can be always seen in absolutes. The engineering approach values measurable, reproducible results which can be represented in a graph or a checklist. Unit tests and benchmarks illustrate progress.

[…]

Visual design is often the polar opposite of engineering: trading hard edges for subjective decisions based on gut feelings and personal experiences. It’s messy, unpredictable, and notoriously hard to measure. The apparently erratic behavior of artists drives engineers bananas. Their decisions seem arbitrary and risk everything with no guaranteed benefit.

Software design is not data-driven engineering. Unit tests and benchmarks are about testing an implementation and certainly what’s learned needs to feed back into and inform the design but strictly speaking these are not design activities. There is a myriad of decisions in a software design that are made on qualitative grounds, not quantitative data. Maybe Google tries to make even those decisions driven by data. I’d like to know if it’s so. Most places I’ve worked there was someone with a bigger paycheck and the word ‘architect’ in his/her job title who was expected to pass judgement on the software design. Generally this person did so based on her/his skills, knowledge, and experience. A visual designer who’s aware of that may be all the more vexed when asked to defend the choice of pixel width for a border with data. Where’s the supporting data for the choice to use MVC? How come the debate over WS-* versus REST hasn’t been agreeably resolved with a graph?

If something is a ‘religious debate’, like choice of text editor or choice of programming language or choice of OS, does that mean it’s a question that is not (currently) answerable with data? Or does it mean there are different values and needs and experiences, qualitative things, that lead to different answers?

There’s all kinds of inexact unpredictable squishy messy issues, questions, and decisions that go into software development even without considering the visual interface. Scott is right on when he says:

Data and measurements are essential in software, and can take you a long way on their own. But feelings and instincts are necessary too if you want to do something remarkable.

March 13, 2009

One place I worked had a major release of their enterprise software and following the release a bug appeared. A serious bug. The business was not happy. The Director of Software Engineering was under pressure. The bug had never been reported before and the system processed a large volume of activity every day and had done so since the last major release six months ago. The Director was confident the bug was introduced with the new release. Because of the sense of urgency he didn’t wait for a full analysis. He made the decision to rollback to the prior version. But he was wrong. Rolling back didn’t fix the issue. The bug was pre-existing. It was unfortunate timing that the first time conditions were right to trigger the bug was the day after a major release.

People sometime refer to software as ‘hardening’ in Production. There’s a pervasive presumption that working Production software is generally safer and less risky than newly developed software. The idea is that the longer the software has been in use in Production without change the less likely it is to have unknown bugs. But hardening is a misnomer. Software doesn’t cure like concrete.

The assumption behind ‘hardening’ is that Production is the ultimate test. That the volume and variety of a Production environment is more comprehensive than any test regimen could be. But how good of a test is Production? What if 80% of typical Production activity exercises only 20% of the code? What happens when the unusual occurs? Many organizations test for load and scale issues but I don’t hear of organizations commonly measuring (or inferring) code coverage in Production. Could the unit tests and QA tests actually be more comprehensive than typical Production scenarios? Could ‘hardening’ represent an unsafe assumption?

A colleague pointed out there can also be an anthropomorphizing factor at work. Who do you trust more — the new recruit or the veteran? Even with known flaws the veteran can seem like a safer choice than the unknown recruit. “The devil you know is better than the devil you don’t.” But software releases are not people and you may not know the devil you know as well as you think you know it.

Program testing can be used to show the presence of bugs, but never to show their absence.

— Edsger W. Dijkstra

I once wrote the Dijkstra quote on a whiteboard as part of a presentation. The technical folk in the room nodded in recognition and agreement. The non-technical manager became agitated and vehemently disagreed.

To manage risk an organization working with the supposition that ‘hardened’ Production software is safer, may place strict controls on Production releases. Because of the effort involved in a release, releasing quarterly may be considered a fast schedule. Because of the amount of time between releases, each release tends to be large which increases the perceived risk.

If the potential for regression issues can be minimized (say through automated unit tests), which becomes the greater risk — introducing new bugs with a new release or not fixing latent bugs in the existing Production code? If the risk is in not releasing, than releases need to happen faster. Instead of quarterly what if releases were biweekly? The work would be chunked into smaller more frequent releases. Bugs which aren’t critical enough to require a special immediate fix could be fixed in production in 2 weeks instead of 3 months. The software could potentially adapt more quickly to changing needs and user feedback.

Build unit tests. Release often. The only way to improve software is to change it.