constructive nonconformist

links for 2009-03-30

• peripatetic axiom: Seduced by the drama?
  (tags: programming management)
• Should Managers Have a Green Hippocratic Oath? | HBR IdeaCast | BNET Intercom
  (tags: management)

Software Professionalism

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.

— Keith Braithwaite
peripatetic axiom: Seduced by the drama?

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.

links for 2009-03-29

• JSTalk Extras
  (tags: programming macosx applescript javascript)

What is constructive nonconformist?

When I graduated high school I was awarded the Anne Peters scholarship which is given

“to a graduating senior who intends to further his education and demonstrate the qualities of independent thought and activity that identify the constructive nonconformist.”

Raganwald and Obsession Times Voice

Daring Fireball - Obsession Times Voice
43 Folders - 43f Podcast: John Gruber & Merlin Mann’s Blogging Panel at SxSW

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.

Now go read raganwald and see what you missed.

links for 2009-03-28

• Lessons Learned: Work in small batches
  "Software should be designed, written, and deployed in small batches."
  (tags: programming management agile)
• Managing Product Development » Waterfall Projects Create Naivete
  "We know the requirements are not complete. We know the features will change."
  (tags: programming management agile)

links for 2009-03-27

• Introducing JSTalk, an alternative to AppleScript
  (tags: programming macosx applescript javascript)
• Michael Tsai - Blog - Introducing JSTalk
  (tags: programming macosx applescript javascript)
• Red Sweater Blog - JSTalk - An Alternative To AppleScript?
  (tags: programming macosx applescript javascript)
• ccgus's jstalk at master - GitHub
  (tags: programming macosx applescript javascript)
• appscript
  (tags: programming macosx applescript)
• JavaScript for the Macintosh
  (tags: programming macosx applescript javascript)

Software Design is not Quantitative

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.

— Scott Stevenson
Theocacao: Measuring the Design Process
(writing about Doug Bowman’s stopdesign : Goodbye Google)

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.

The Only Way To Improve Software Is To Change It

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.

links for 2009-03-08

• The DOM Stigma - The Fishbowl
  "Javascript has always been perfectly cromulent."
  (tags: programming javascript java dom)
• Cromulent from "Lisa the Iconoclast - Wikipedia, the free encyclopedia"
  (tags: cromulent)