Sean O’Halpin did a very nice job with his Unobtrusive Metaprogramming rant/presentation that has been making rounds particularly in the Rails community.  Sean’s suggestions seem thought out, and the ideas he gives to the maturing rails community are sound.  That said, I can see a bunch of folks taking Sean’s thinking as dogma (ala Edgar Dikjstra’s famous letter “Goto Considered Harmful”). I understand the futility of my efforts, but cannot help my urge to fight creativity-bashing dogmatic thinking.

Talks such as Sean’s are about how to be polite.  And for sure politeness is a nice thing to be around. “Politeness is the art of choosing among your thoughts”, wrote Madame de Stael. So while a programmer should certainly choose carefully among the thoughts they offer the rest of the world, should we really care? No, and in fact, I would argue that new languages like Ruby and Go have grown out of the desire of programmers to have power restored to their hands, maybe at the expense of some politeness.

I’m talking here about the difference between Convention and Protocol. Convention helps people get along, if they want to. Protocol prescribes pre-arranged actions and consequences. Woe to those who violate protocol. The protocol of programming has become deep. Don’t use goto, don’t use private data, don’t use globals, don’t monkey patch, don’t put more than one class into a file, don’t return except from the end of a function, yada yada yada. Now I understand protocol is a great way, albeit Maoist, to get along, but convention is really a better choice for many programmers.

The fact that your patient gets well does not prove that your diagnosis was correct. Samuel J. Meltzer

Many will point out that function calls really did improve the general quality of software from the the spaghetti-coded goto-strewn mess that preceded it. Likewise, it is also true that I see goto often and productively used in device drivers and OS kernels where conciseness and complex control are inevitable. And there lies the rub. Bruised fingers do not argue for outlawing hammers. Though a pneumatic nailer is a nice thing too. I once had a land-lady that insisted the workers replacing her roof use hammers. I understand her feeling.

Sometimes to do great work you need to have full control. Craftsmanship requires being so close to the workpiece that great skill can be distinguished from the damn near inevitable errors. Error has to be as likely as success to expose the skill, and the art. Folks choose Ruby so that they can monkey patch. If that’s a bad thing, maybe Java is a better choice for the project at hand? The agility of a tool like Ruby brings the possibility of getting cut by one’s own knife. And you know, that just might be a good thing.

• Sean O’Halpin’s Talk on Unobtrusive Metaprogramming, via Ruby Manor
• Gever Tully on why kids should have sharp things to play with, via TED

Often when working on projects there are two opposites types of personalities at work: Idealists versus Pragmatists. Often both sides show great animosity for each other. What’s so problematic about battles between idealists and pragmatists is that great solutions to problems are most often combinations of these two approaches. Results come from elegant combinations of pragmatism and idealism. Dogma is the enemy…

Elegance is our best friend. Now before the Dogmatists (Idealists + Pragmatists) claim the elegance of their respective approaches, lets look at the actual definition of elegance: pleasingly ingenious and simple, related to Latin’s eligere, ‘to choose, or select’. Elegance is choosing or selecting a simple and ingenious solution. Nothing more, nothing less. Idealists over-design, in love with excess flexibility.  Pragmatists under-achieve by rushing to action, in love with excess quantity.

Elegance is in finding a fine middle point between these extremes. How to achieve elegance in software design and implementation is not always intuitive or straight forward. One the the best talks on this topic is Jim Weirich’s from Mountain West Ruby Conference 2008. He skillfully combines the approaches of the noble blue collar pragmatists with the space-age white collar idealists. He advocates a path that does not over-design, or over-implement. He points out that a solution must be appropriate to be elegant.

James Joyce said that great writing possesses Wholeness, Harmony and Radiance. I think he meant understanding the problem, creating the right goals, and selecting or choosing the elegant path to meet those goals.  It sounds easy, but simple is much harder than complicated. If one persists towards simple, a certain timeless beauty becomes possible. This feeling transcends elegance, and feels like Grace from the constant struggle of the programmer’s trade.

• Jim Weirich’s talk from Mountain West Ruby Conference 2008
• It is the sign of a great mind to dislike greatness, and prefer things in measure to things in excess. — Lucius Annaeus Seneca

It used to be that a high-tech engineer would be fired for being redundant, or if they failed. However, now days engineering groups that are perfectly successful are getting laid off the day they finish products. Getting fired for success is pretty new, since most companies viewed the engineers that understood how their products worked to be assets. At the very least, depriving one’s competitors of talent was worth doing everything possible to keep engineering staff around. That thinking appears to be old fashioned.

Companies are experimenting with all kinds of approaches to staffing. Some fire 5% of their staff yearly. Others have launched on diversity programs. It seems to be fashionable to call these social engineering exercises of the workforce stupid, moral failings of management, or conspiracies. Some simply cite globalization, or executive incentives tied to fabulous piles of stock options.  Folks like Jack Ganssle go on and on, as journalists love to do. Fear mongering sells.

I wonder about this. As a human being, I often make mistakes, blunders, and mis-predictions. In fact, I really only seem to learn the hard way, by making mistakes. The only way I seem to be able to avoid making mistakes to to avoid action. I think most people are fairly familiar with the reality of this human condition. But for some reason, when evaluating these new trends in labor policy, many of us fail to realize the humanity of those making the decisions. Things change, and folks are trying to adapt in the only possible way, acting, failing, trying again.

I do not mean to say that there are not executives with self-serving motives and low character. In fact I have seen some fairly astounding lack of character in managers throughout my career. What I am saying is that to ascribe such faults to the natural course of change in an industry is not rational, it’s emotional. Therefore, the failing is in us engineers, it’s not our employers. Rut-roh…

Why would I say such a thing? Well, the truth is that companies are experimenting with staffing because competition demands it, and they have the power to do so. While we engineers are not as powerful as the executives that decide the fate of many, we are far from powerless. The first thing to do is recognize that the employment game’s rules have changed. The next thing to do is play to the new rules. Eventually we will learn to play the game well. Now that the market for engineering talent is heating up again, here are some ideas that have been working for me:

• Consider yourself a free agent. Serve your employer and give them excellent value. However, the argument that bending over backwards will make the company more loyal to you is silly. Appealing to our sense of corporate loyalty need no longer restrain you; there is no loyalty. Reject all such coercions from managers trying to get even more from you. If someone says you’re less likely to be fired if you work weekends, you’re going to be fired eventually, maybe soon. Best to spend your weekends looking for new work.
• Join local trade and networking groups. By going to the excellent Kickstand networking group here in Boise, I have learned of  new local companies developing LED street lighting, blood tests on silicon chips, wireless power metering, Internet appliances, and media/advertising software. And this is Boise! Get out there and find out what’s going on. Meet the people who might need you, now or in the future.
• Go to demos and specialized group meetings. When I lived in Silicon Valley I saw a demo from Steve Wozniak at Xerox PARC. I grew as an engineer from that demo. I also learned a ton about Internet publishing through my local Drupal group (which just happens to have some real Drupal powerhouses that attend). There are lots of doors that lead to new ideas, products, tools and (dare I say it) adventures. Make sure you’re taking in new stuff all the time, finding new interests and pursuing them.
• Learn from all the people around you. Especially focus on people who do things differently. It is tempting to hang around with those that agree with us. However, the real magic in learning happens when we confront the unfamiliar and threatening new ideas we will not hear about unless we ask. Connect with people and ideas you wouldn’t normally entertain. It just might lead you to the place you’d rather be.
• Take friends in other industries and vocations out to coffee. Ask them what they like and don’t like about what they do. Consider what it is about what they do that you might like. Remember don’t make hunting for work ideas into a status thing. It doesn’t matter if a friend is a CEO or an hourly worker. Don’t always look up the food chain. Meet with folks independent of status or position and consider everything they say. You might just decide you’re more senior than you’d like, as opposed to a frustrated superstar.

These are just a few ideas that have been working for me. There are many more angles on the new economy for us nerds. It could be as simple as writing an app for the iPhone, or as complicated as changing careers to the fine wood boatbuilding you’ve always admired. Anything is possible when you never know what the next day holds. Believe me, falling down and getting back up again is normal and necessary. Only the emotionally stupid fall down and end it there.

• Stumbling on Happiness, discovering what makes us happy
• The Adventures of Johnny Bunko, finding the right job
• Falling Down, a film about an engineer gone wrong

My sister’s in-laws like to visit her home during Thanksgiving.  I don’t blame them, she’s a fabulous cook and host (ess). These occasions stuck in my mind. When my brother-in-law’s family broke out a cribbage board and played into the night, it looked like a ton of fun. But I never learned to play.

Recently I discovered that cribbage is a favorite of the US Navy’s submarine service. This little bit of trivia (thank you Wikipedia) made me think of learning cribbage again. So I downloaded an iPhone app (my preferred solution to almost any problem) and set to work.

My choice was Cribbage Multiplayer. I absolutely love this app. It had directions for me to get started and was very intuitive to play. At the bottom of the screen it prompted me for the next move, so I really don’t have to remember every rule to play easily.  The app allows me to play against the computer, or to use it to play with another.

I think the iPhone app my be good for submariners, if they are allowed such luxuries. I had a chance to visit the Guardfish once (an amazing evening courtesy of the XO of the Guardfish in 1983). I can understand how much a cribbage board could brighten a very long cruise. My thought is that the Navy should issue iPod Touches to the crew of all submarines and include Cribbage Multiplayer. If I had the means, I would make it so.

• Cribbage Multiplayer
• Dick O’Kane’s Cribbage Board aboard the USS Los Angeles
• Cribbage, via Wikipedia

Last night at Kickstand, one of the panelists (Steve Nipper, I think) mentioned David Allen’s GTD. Sometimes I struggle with the description of why GTD is important, and I thought the panelist struggled much the same way I do (my impression, disclaimers apply). Upon reflection, I think the concept that doesn’t get mentioned in a recommendation of GTD is Relaxed Control.

I think the thing that made Relaxed Control hard for me to find was that I thought I already knew what it was. In other words, I read the book, I read about Relaxed Control, I decided that Relaxed Control is what I wanted, and off I went to do do do.

But as I have struggled over the years to implement GTD, and achieve RC, I’ve been forced to look at the concept more carefully. What does it mean? When working on the How of GTD, we need to have the clearest possible conception of the What, the Relaxed Control we seek, as our guide.

One of the best ways to explain Relaxed Control (abbreviated RC, and pronounced ‘Rock’), is to define what it isn’t. After all, one can be very busy, and yet relaxed, focused and in the flow of things.  We can also be very busy and Out Of Control (OOC, pronounced ‘Awk!’). My definition of Relaxed Control is not-OOC (pronounced ‘Nawk’).

Being a nerd myself, a problem I’ve had implementing GTD is holding onto it too tightly. The tighter I squeeze, the more painful details slip out of my hands, and paradoxically the closer to OOC I go (think, Admiral Boom). A Chinese general once remarked that “perfection is the enemy of good enough”, which seems apropos to my situation.

So now I focus on Good Enough in my GTD (GEGTD, unpronounceable at this point, acronyms apparently not my strong suit). These days Mary Poppins is as much an inspiration as David Allen. That said, spit spot, off I go…

I have not been writing, nor reading for that matter, over the last several months. So I was excited to have Santa bring me a copy of Phil Bolgers’s Boats with an Open Mind.  Spending the last few days leafing through the work of Phil Bolger reminds me that design is not a job for wimps, or for folks afraid to have strong opinions.

While pleased with a new position at Micron Technology, I have been working an uncharted area of my trade furiously for several months.  When I took this position my wife wisely advised me to drop other pursuits in the interest of focus.  Like so many things, she helped me remember the value of doing one thing at a time.  Phil Bolger clearly understood the value of focus.

Phil’s work combines the simplicity of the Model T, with the craftsmanship of the masterful New England boat builders of the last two-hundred years. The ability to relentlessly pursue design, and understand the sometimes subtile difference between success and failure, stood Phil well.

It is with sadness I report that Phil died this year. His story ends with the clean lines and simplicity that marked his work and his life. Not one to shirk a challenge Phil left this world violently. I wish him godspeed on his next expedition.

• Boats with an Open Mind: Seventy-Five Unconventional Designs and Concepts
• Boat creator ‘leaves on own terms’ via Gloucester Daily Times
• “The Lovers”, a story based on the Bolger Micro

Recently I bought a nifty little USB charger for my iPod touch and mobile phone.  You can build these things, but I was in a rush, and Radio Shanty had them on sale. I was so pleased at how tiny my vacation bag was without my enormous collection of wall warts.

We get to our mountain cabin, tuck the baby into bed, and plug in the charger. Ack! The Blue LED of death!  Why must almost every electronics manufacturer put these obnoxious super-bright blue LEDs into everything.  Is it really a feature?

Sure you can say “night light”. But what night light makes one wince? I once worked on a pair of computer servers from a reputable maker.  The blue LED on the front of the box was so bright it hurt (not kidding) whenever I failed to turn my head before approaching the machines.

When I looked inside these servers, I found a light pipe over one foot long to make the bright blue light come directly out of the center of the machine (straight into my face). So the design team on the computer actually worked long and hard to make this death ray come out of the center of the control panel.  This is really quite far away from the “pilot light” concept, the little stupid light that tells one a machine has power.

Of course the solution is black electrical tape.  However I would urge design teams to send the marketing girl/guy packing when they pop in to ask for a bright blue LED on something.  Apple has the right idea with pilot lights, dainty soft, unfocused lights, discretely hid on the front of devices.  Design is about removing that which does not belong as well as adding what does.  Unless there is a compelling reason to put a blue death ray on something, it’s better left off.

• Dual USB Power Adapter, by Belkin
• Light Pipe, or Light Tube via Wikipedia
• USB Wall Charger via Instructables

One of the nicest things about taking a summer sabbatical (or siesta as my darling wife prefers to call it), is that I get to read books. Maybe I don’t read a bunch more when on vacation, but I do get to noodle with a book’s ideas more than I do when hard at work. The Element is a book I enjoyed thinking through.

It appears that I dog-eared about 50 pages of 300 in this book. That might be an unofficial record. It is surly an indication of a good read.  To be honest, I was surprised it was such a good read. You see, the book appears at the beginning to be a book about education. And I must also admit that education is not a subject I relish.

The Element is not a philosophical treatise on education methods, though it does discuss why we in the first world might not be meeting our educational goals. Primarily the book is packed with interesting, unusual stories about people who found what they most loved to do and were best at achieving. The biographies are fantastic.

I was forced to recollect my own extremely mixed feelings about education. While talented and interested in schoolwork, my results were mostly mediocre. And I was truly unapologetic to my, justifiably exasperated, instructors. One doesn’t have to be a poor student to get something from these biographies. They are interesting and diverse. The stories cover good and not so good students.

The point being made in The Element is about finding resonance, or a relationship with an activity, vocation or art. Discovering an interest and a pursuit can meld into an exceptional life. And someday, maybe such lives wont be exceptional. The Element is a guide for those of us still looking for ways to find their own sweet spot in life. I think The Element may just have helped me get a bit closer.

• Kindly recommended by Doug Covey: @DougCovey
• The Element: How Finding Your Passion Changes Everything on Amazon

So having been careful about requirements, prototyping iteratively, testing with real users early on and getting it out the door quickly, what now?  No doubt users are calling, or emailing questions, feature suggestions, raves, rants and some, hopefully occasional, hate mail.  There are some naysayers at this point hollering that it went out the door too soon.  Be calm…

The reality is the all the finest and most experienced software companies ship fast, Microsoft, Apple, etc.  The reason is that software rarely gets better after a certain point.  Software really can only be so good by design.  It only can become great software when in gets into the hands of real users trying to accomplish something they value.  Period.  It doesn’t matter how screwed up the software is, you’re on the right track.

So with flames all around you, it’s time to profit from shipping quick.  All the information coming at you is gold.  Here’s what to do with it:

• Capture
• Categorize
• Postmortem
• Kit
• Launch

Capture

Many shops have defect tracking systems.  And you know, that is a good thing.  However, the days and weeks after shipping new software is a little like brainstorming a new product.  There is a tendency with defect tracking systems to narrow things down to the explicit cause and effect of a problem or bug.  But right after a new product is shipped you’re going to receive a lot of input that doesn’t fit this mold (”I think the new interface sucks!”).

It is really important to capture everything you hear back from the field.  I mean everything.  So don’t just capture that someone thinks the new interface sucks.  Make sure you capture exactly how many people said it, who they were, how loud they were, and the date.  Not kidding!

Categorize

After trends start to develop generate some categories to sort the input into.  Don’t get too anal about this.  It is again like brainstorming, try to sensor things as little as possible.  If you’ve got something that resists all other categories, give it its own category for a while.  Do not make a category called Misc and put the oddballs there.  One oddball idea ignored has been the death of many a project.  Treat every insult with the utmost respect.

Postmortem

Dead is bad, right?  Wrong.  Dead is just the state of being over, being done.  The previous cycle of software development tried to produce the most wizbang code for wowing users and making everyone in the company rich.  It didn’t do that, right?  What can we see in the feedback coming to us now, that is completely surprising?

What was predicted, that we didn’t act on and turned out to be true?  Who predicted it?  Why didn’t we listen?  Was that a good choice to ignore (maybe it was)?  Crawl through every angle of how these issues were regarded before ship date.  The most important point is to have no judgment.  There aren’t any right or wrong answers, no one has a crystal ball.  The point is to try to stretch our imaginations to be more like how the outside world regards our work.

Kit

So with a basic set of categories and some time spent understanding issues, what we thought about them before, and what we think about them now, sharpen the categories into Kits.  Kits are a combination of priority and do-ability.  It is taking the most important things that are do-able and putting those first.

It might mean that large important issues have to get done in stages to keep people happy.  Yes, this is unfortunate when it happens, but it happens.  Prepare kits that address the needs of your customers in chunks that your team can deal with.  Some of the early iterations might be very short to get stuff moving, and hopefully get longer as more gets sorted out.

Launch

Use all your new data and learning to watch for ways in which the old thinking, the stuff that was shown to be really wrong in the postmortem, doesn’t creep back into people’s heads.  If we’ve spent months oriented toward a set of design challenges, it might take more than one day to turn the ship.  Sometimes major philosophies or design decisions are not the right path.  It can take lots of daily work to rebuild the ship, while turning it and keeping it from sinking.  Stick with it.  If it doesn’t kill you it will make you better.

Repeat…

The key in all these processes is tying the feedback from the field back into the thinking of the team.  That is really the most important part of managing software.  You can’t do this with systems and scheduling and priorities.  It is a human task.   Processes work for sustaining software, but to build new stuff, you gotta really find ways to get dirty with the problems and opinions of one’s customers.

Postmortems focus a team on thinking like its customers.  And that, at the end of the day, is all that matters.  To study our own work, with an objective eye, from the viewpoint of the outside world, is the key ingredient in truly great software.

I just off the phone with an old High School chum.  We got to talking about Bottom-Up Thinking as a way to set direction when a situation is unclear or changing too quickly. It was in the context of career, so I gave a lot of unsolicited advice … ‘natch.

However, it got me to thinking about all the messed up, and the few really great technical projects I’ve worked on.  I think one of the most important things to do for every phase of any project is to decide if it is time to work Top-Down or Bottom-Up.  I think for Software Design one must always work Bottom Up:

1. To understand requirements clearly, it’s best to mock up, or prototype software to show stakeholders.  Paper or a whiteboard is the place to start.  It should be iterative with the prototypes getting fancier and the requirements firming up.
2. Already know your requirements?  Think again.  Go back to step #1.
3. Prototypes should always run and always be accessible, you never know who will get shown the proto and come up with the game changing idea.
4. Think you know what will change the game?  Think again.  Go back to step #3.
5. As soon as the ideas in the product firm up and the prototype represents them, it is time for User Interface (UX) testing.  It is critical to design with the customer in mind asap.
6. Think that silly users are not going to be able to understand the lofty ideas behind your story board, powerpoint, or web prototype?  Think again.  They get it better than you.  After all, if they don’t understand it, why would they buy it?  Back to step #5 with you.
7. Prototypes become commercial software through a process of Re-factoring.  Re-factoring changes incomplete, flaky or non-mission-critical components with stuff that is ready for prime time.  The point is to be iterative, always have the software in working order, and develop tests+specs as you go along.
8. Is the prototype technology too week and not suitable for heavy duty commercial use?  Do you need some new language, tool, technique or paradigm to get your design implemented?  Think again.  All kinds of cheap technology powers critical systems the world over.  Google started with a freaking Perl script.  Elitism doesn’t make money.  You got it, back to step #7.
9. If you’ve gotten to this point.  Ship It!
10. Are you wondering if this is really ready for primetime?  Maybe we need to make it run on a cloud, or have a real sysadmin, or advertise, or, or, I don’t know, do something else.  Look, software is never done.  It is much better to fail fast, and still be able to get back up, than sit around waiting for stars to line up.  The real learning doesn’t start until the product ships.  Back to step #9, and no excuses this time

Some folks today will call this Agile.  But its been around a long time in engineering.  Before the Internet, back when Pyramids were being built.  Engineers noodle around too much, have lots of ideas, and tend to work top down.  I am one, I know my type.  The truth is, it really is a jungle out there.  Work Bottom Up, in lots of little steps, up to survive Software Design.

Recently I saw an Ignite Boise presentation from a woman who read 200 books in one year.  Many of these were classics.  You may be interested in some of the classics in computer software. Classics do tend to become free eventually.  Here are some good ones:

• Structure and Interpretation of Computer Programs, Abelson and Sussman
  A look at the fundamentals of computer programming, most importantly that programs are data, and data can be programs.
• On Lisp, Paul Graham
  A great look at why Lisp and other higher order languages are the future, not the past of software development.
• Higher-Order Perl, Mark Jason Dominus
  Higher order programming implemented in the original Swiss army knife of computer languages, Perl.

Last year at a family gathering, someone from the younger generation commented that they had no idea why NASA was still in the business of shooting people into space. They felt like the money was sorely needed for things like the next generation of renewable fuel, for example.

My father was there, a sixty-something electronic engineer who worked on Apollo. He said many important things came out of the space program. Naturally he was asked how exactly our society benefited from the Apollo program.  He replied that important inventions, like Velcro, had come from the space program. Velcro?

We giggled for days at his unwitting reinforcement of our claim that NASA and its work has become largely irrelevant.  Of course, those younger than I were incredulous.  But I understood.  In his time, the effect of the space program was pervasive.  National identity, our contrast with the fierce rise of communism, and the world’s new path of technical military domination fed the enthusiasm for the space program and all it produced.

My father’s point wasn’t that Velcro was an important invention, it was that even the smallest and most insignificant of the stuff we regard as normal today came from the space program.  We are in so many ways children of Apollo.  The goal to reach the moon not only galvanized our country, but was a goal so big, so beyond anything tried before, that it changed us for good. It changed us in ways we can’t recognize anymore.

Getting back to the original comments of the 20 somethings, I think there is some common ground here.  I think it is time to stop shooting people into space, and stop worshiping that past accomplishment.  It’s time to set another outrageous goal, outrageous like going to the Moon.  Another goal that is so beyond us, and so indicative of what this country stands for, that it changes us forever. Something that we all feel, and all want for ourselves and everyone who comes after us.

Thank you Apollo 11.  Now lets figure out what to give our children’s children, something that they won’t be able to see or understand, but will make them richer and stronger for us having done it.

• We Choose the Moon

From the Google Chrome OS announcement:

Speed, simplicity and security are the key aspects of Google Chrome OS. We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web.

Recently, I failed to notice a Google malware notice on some search results.  In a scene straight from the late 90’s, I clicked on my browser, it crashed, followed by Windows crashing too.  Been a while since I’ve seen that blue screen of death.  Kinda missed it…not!

This was a reminder that the clunky operating systems of the present were built for a world when computers were giant space heaters that sat on our desks, running expensive shrinkwrap software.  Back in those days, companies got into the habit of creating systems deliberately to either hold market share (create proprietary standards) or steal market share (create open standards).  This history has made it hard to bring new operating systems to market, as Rob Pike (part of Google’s brain trust) points out:

To be a viable computer system, one must honor a huge list of large, and often changing, standards: TCP/IP, HTTP, HTML, XML, CORBA, Unicode, POSIX, NFS, SMB, MIME, POP, IMAP, X, …

A huge amount of work, but if you don’t honor the standards you’re marginalized. [We] Estimate that 90 to 95% of the work in Plan 9 was directly or indirectly to honor externally imposed standards. At another level, instruction architectures, buses, etc. have the same influence. With so much externally imposed structure, there’s little slop
left for novelty.

Plus, commercial companies that ‘own’ standards, e.g. Microsoft, Cisco, deliberately make standards hard to comply with, to frustrate competition.

The earnest hope of many has been that Rob would bring out a version of the old Plan 9 operating system with Google’s help.  But that hasn’t happened.  So I figure it’s time to write down what I want and send it off to Google (and Rob, via Santa).

• Like Plan 9 have every aspect of system interaction based on one abstraction.  For Plan 9 it was the file, for Chrome OS I would think data streams addressed by URLs are an obvious and useful choice.
• Plan 9 had the wonderful Acme integration of system, editing and user interface.  I would like the entire screen to just be a browser with no chrome at all.  Like Acme, I would like the user interface to be easily constructed and modified by the user.  I suggest HTML 5/CSS3.
• It’s time to get rid of the notion of application.  A program should run as both client and server and be downloadable from a URL.  I.e. if I download the app and run it locally, it is a client in my browser, and a server to the local data store.  The same program can run in a cloud or on a server.  No change to the source code.  I have experimented with this a little and plan to cross post some code to my code-only.com blog real soon now.
• Device drivers generally need to run native code, but that makes maintaining them and securing them a hassle.  I suggest all device drivers be written in an OS neutral, architecture neutral byte code.  After an OS downloads the code from a URL it can use a JIT compiler to translate to the native architecture (and maybe a different OS) and cache that translation so there is no need to translate in the future.  A hardware config should really just be a bunch of URLs.  Apple should help with this, it would be enormously useful to their OS, and probably no threat, only help.
• Every URL/program should run in its own process.  That URL should map to other URLs which allow the identity of the server and a hash of the content to be automatically verified.  The kernal should be able to do this without any process intervening.  This way a user can surf all securely signed websites with acceptable, non-intrusive content with just a single OS setting.
• The filesystem should understand replication and be encrypted.  In other words the local filesystem can have content from local programs mixed with content mirrored from a server ala Gears.  Theft of a physical device should require extensive work to break the encryption.
• An entire customized system should be able to live on a private site in the cloud, so an exact replica of your personal system can be booted on any Chrome OS computer by just pointing it at the URL.  This allows anybody to work anywhere with a friendly custom environment of their own choosing.

Now I promise to be good before Christmas.  I have a Sharp MM10 netbook machine I just cannot wait to put Chrome OS on.  I hope this letter gets to the North Pole (and then to Mountain View).

• Official Google Blog: Introducing the Google Chrome OS
• System Software Research is Irrelevant, by Rob Pike
• Rob Pike Bio, via Wikipedia
• Sharp Actius: Redneck Netbook (The Cotton Gin)

Though I have enjoyed all of Gladwell’s books, this particular one hit me close to home.  I suspect it will have a similar effect on others.  Who doesn’t want to understand success?  Who isn’t looking for the Midas touch?  Success books might outnumber diet books?

Gladwell demonstrates how numbers can show us more about our world, our assumptions, our illusions and therefore, us.  I treasure his style which reminds me of James Burke’s Connections TV program.  Surprise lay around the corner of each page, and the amazing seems completely staid when Gladwell reveals the underlying back story behind the pattern.

The book is an example of how analytics and statistical research will likely redefine our world, one amazing hypothesis at a time.  It is also a worthy example of how numbers must be paired with logic, deduction, art and instinct to yield their treasured results. I think, Gladwell shows us how data alone gets us nowhere.  But with data, our intuitions can fly much further on the same effort.

• Outliers: The Story of Success
• Debate: Design, Analytics and Google
• James Burke’s Connections

Recently MIT announced that it would change the programming language used to teach freshmen engineers to program.  The change was from Scheme (a language obscure to many outside MIT) to Python (a language enthusiastically used throughout the world, notably at Google).  To most, this may seem a relatively minor curriculum change, the kind that happen all the time in universities, without fuss, and especially in the technology areas.  Not so.

Why?  After all, MIT has been using Scheme since 1985.  That’s practically the stone age.  The IBM PC was still the top personal computer in 1985 (8 MHz Intel 8088, remember)!  Python is a relatively recent language,  supported by a vibrant open source and commercial community and used in some of the most obvious places in the Internet.  Most might wonder what took MIT so long.

The truth of MIT’s choice is that this represents a fundamental shift in the nature of the nerd art.  And that shift is a true barometer of where we are headed in computer software, and in all the businesses connected to that software. Let me explain…

Scheme is a dialect of Lisp, the Latin of computer languages.  It’s elegance, obscurity and simplicity hides pure unadulterated power of expression.  Not many speakers of latin these days eh, same with Lisp.   Mostly folks program in the descendants of Lisp.  Python is rather more Esperanto.  Simple, and powerful, it is oriented around giving the widest possible range of programmers, the most leverage, for the amount of time they spend programming.  Python is pragmatic, effective and useful to a wide range of people trying to get stuff done with computers.

What does this say?  I think it says, we are transitioning engineers from the task of creating technology to the task of using that technology to build amazing new inventions.  We are asking our computers to now help us solve problems.  Problems in electronics, cars, energy, robotics, automation, analytics, communication, medical and every other human endeavor you can think of.  MIT is now saying, we don’t need people to make new ways of computing.  We need people thinking up new and clever ways to apply computing. Bravo!

Just to be clear.  I am mourning the passing of Scheme.  The text MIT used is my most cherished book, along with several others that explore the deep elegant basics of computer programming.  Though I like Python (and use it every day), I prefer the more elegant, refined and powerful Ruby.  Ruby is, to me, closer to Lisp.  I would love to work in Scheme.  Ah, well.  This too shall pass.  MIT has made a wise choice.  Our future lies with what we create with our computers, not the computers themselves.  I’d say the classic glass palace has given way to the wild and woolly, sometimes daring, Gehry.

• Innovation:  It’s About the Application Stupid
• Why Did M.I.T. Switch from Scheme to Python?
• Chiming in on the MIT Scheme to Python Switch

Recently I read “The Internet devalues everything it touches..“  While I wantedto dismiss the premise of the article out of hand, I think this will be a popular opinion.  It is also worthy of study.  After all, it is easy to get caught up in the idea that everything Internet is always better.

Looking at the continuing development of IBDTs [Internet-based disruptive business technologies] and their relative low cost of development and nearly free distribution, it is easy to see that once they become widely used and implemented, we will see a massive reduction in the costs of doing business.

We will know when this scenario has occurred, or is occurring because we will see the signs: a strong and continuing deflationary trend. We will see a continual erosion in the value of products and services.

In simple terms, the Internet devalues everything it touches. Anything that can be digitized. I’m using the term “devalues” in a strictly materialistic definition and not in a cultural “values” sense.  And I’m using the term “Internet” to denote a class of distributed technologies and applications.

This is an intellectual “bait and switch”.  Reduction in a business’s overhead lowers the cost, not the value (or “utility” in the language of economics). In fact both the provider and the purchaser benefit compared to the pre-Internet service.  Cost is the thief of profits in a steady state market, not price.  And price has nothing to do with value, a cornerstone of economics.  You can see this by just noting Google’s extreme profitability.  More money in, for less out.  Simple…

There was another group of folks that made the identical error in reasoning: the Luddites. Luddites were opposed to the drop in prices anticipated (correctly) following the introduction of automated looms to British textile factories.  Unskilled labor could then accomplish, faster and for less money, what experienced tradesmen could only do before.  Contrary to the popular use of the term Luddite, they were not opposed to technology, they were opposed to the inevitable economic consequences of technology.

Why were the Luddites wrong?  They were wrong because the world needed more clothing.  Society got the opportunity to have less of its resource (cost) devoted to the mundane task of making clothing for the people.  The industrial revolution freed folks from tasks that machines could do, so they could move on to things like inventing electricity and light bulbs, antibiotics and airplanes.

Remember business is not, in the end, about making money.  Money is made in the process of producing ever increasing amounts of utility.  Business is a means to an end for society.  It is a means to making the world what we want it to be.  If people don’t want to pay more for something, they really don’t want that more expensive thing as part of their world.  Get over it…

So where does the, dare I say it, Internet-ization of business processes and information lead us?  What better future lies over the horizon?  Lots of ideas are out there, many of them wonderful.  Freedom and education for a large population of the planet for one thing.  Those two are world-saving developments.  And of course, the largest Luddite organization ever, the Chinese government, is on track to shut down its use of the Internet (thanks Cisco).

So why would a free thinking journalist in our society claim such a thing, in such a Luddite-like way?  For one thing, it is very hard to imagine what the future holds.  For the human animal, the future often looks like a void, and the void looks just like death, which is, you know, bad.  The reality is we have no idea what comes next, we could just work to use all that freed up energy to do something useful (maybe even burn digitized books for fuel…okay, that might not be a great idea).

Some folks who specialize in this kind of thinking believe that the Internet will bring the basics to those who don’t have them, medicine, education, journalism, and eventually freedom.  They go on to point out that the effect in first world nations is likely a type of luxury to pick and choose from niche and unique services,  to enjoy ridiculous and irrational utility, sometimes called Art.  Whatever it is, it is coming.  And it will change all of our lives when we just plug into it.

• “The Internet devalues everything it touches..” [via zdnet and Tom Foremski]
• Luddite from Wikipedia
• Chart of the Day: Google’s not that big after all (note: Google’s profit per person)
• The Dream Society: How the Coming Shift from Information to Imagination Will Transform Your Business, Rolf Jensen

1. Verification

   Duh, right?  Your stuff needs to be verified.  However, most design engineers don’t realize that there are important issues in verification tools, qualification, software lifecycle and design for test that can’t be fixed after the fact.  Too many shops throw stuff over the wall, and say “test it”.  Not only does that create a bunch of problems and delays, it makes for bad testing.  But the real reason to always be thinking about verification first is that verification costs are much higher than development costs.  It really pays to develop with verification in mind.

2. Quality Assurance

   Developers cannot see their own mistakes.  It is a feature of the human hardware.  One must have a highly competent, independent set of eyes to reach the high quality safety critical engineering requires.  Don’t bother hiring great developers if you don’t want to hire great QA.

3. Configuration Management

   This is just version control right?  Nope.  Keeping one’s stuff in a version control system is not the point of this 178B objective.  The point is to be able to 1) identify objects with problems from reviews and defect reports, 2) identify the changes that make up a fix,  3) verify that the fix made it into a build, and then be able to 4) show the fix worked.  This objective is way more about having a system to identify things, track changes and know what results to review.  This functionality needs to be built on top of a version control system.  Hint: use a web technology to create a user interface for version control that helps users implement Configuration Management.  If you’re going to automate something, the biggest bang for the buck is here.

4. Certification Liaison

   It doesn’t matter how fast you’re walking if you’re walking in the wrong direction.  Make very sure that your certification authority knows exactly what you’re doing and is reminded often.  Most engineers at certification authorities are very busy people, it pays to communicate, communicate, communicate.  Make sure you see them, talk to them, and follow up with some written documentation.

What makes these things so important?  Well, they are the integral processes.  In other words they apply to every single step of a certification project.  Screw any of them up, and the whole project is rotten at its core.  Then it will take major action (i.e. expensive action) to get back on track.  Succeed with these four, and the rest of the errors that inevitably come up won’t stop your fast break to certification.

• Ready to Certify: Chicken or Egg?
• Google Testing Blog: Why are we embarrassed to admit we don’t know how to write tests?

When I started this blog, it was named The Cotton Gin.  I liked the name, and I liked the metaphor.  I still do.  So why would I change the blog’s name to the most boring thing possible: “John Conti’s Software Journal?”  Blame my favorite company Google.

You see, when I looked at the Google Analytics data for this blog, I saw a bunch of searches for information on, you guessed it, cotton gins, the kind Eli Whitney invented.  Google was putting more stock in the H1 and title tag at the top of every one of my pages, as opposed to all the other content, which never mentioned Eli Whitney (until now).

Sigh.  I buckled to the pressure.  It seemed like no service at all to those school kids working on social studies reports to end up here.  Well, I’ve changed my mind (or lost it).  I’ve decided to ignore Google.  After all, one of the most prominent ads Google placed on my pages is for tires.  So Google search and ads can’t be all that smart. SEO is one thing, following a dumb machine’s dumb ideas, is well…

• Hello World: The Cotton Gin

I excitedly asked my mom if we could call the flight attendant (”stews” in those days) and point out the fairly substantial stream of fuel.  My mother, panic stricken, agreed.  Shortly after, the first officer arrived to take a look.  He confirmed the leak and thanked us for piping up.  I was prouder than a prized pig at the county fair.

My flush of enthusiasm led me to write a glowing review of the crew and the flight on a little survey card in the seat pocket.  I was amazed that the crew read them!  After all, weren’t they just supposed to turn them into their management   The result of my survey was an ice cream and a treasured trip to the cockpit to see the “front office” of the Douglas DC-10 we were on.  Wow!

Certainly by now you’re asking “what’s the point” (and maybe also, where’d the bad metaphors come from).  Well, many years later, having become a pilot, and having known airliners to make emergency power off landings due to loss of fuel, I realize what a big deal such things can be.  Imagine, one of the most powerless, and for the most part ignorant passengers on the plane pointed out one of the potentially most important things for the flight crew to take a look at.

This happens in organizations all the time.  Except in most, priorities are assessed top down, not bottom up.  That’s a shame.  If folks in clubs, organizations, political parties and Corporate America could really listen to the bottom up observations of the unwashed masses, important stuff can come up.  In fact I think a few generalizations can be made, and they’re surprising.

1. Build from the Top Down
2. Decide/Design/Prioritize/Analyze from the Bottom Up

What’s behind these ideas?  Well, when we build something, manufacture something or architect something, we really need a Top Down cohesive view of things.  In other words, the pilots of my DC-10 needed to have a flight plan that considered all aspects of the aircraft’s operation, weather and route of flight prior to departure.  That’s strategic.

When we decide to change direction, usually the environment is changing, something is not going as planned, the market has changed, there is new data, or a new analytic view of a situation.  This is a Bottom Up process.   Bottom Up is tactical, gritty and often surprising.  There is nothing better than fresh data, fresh opinions, and seeing the whites of their eyes.  Many organizations forgo this viewpoint, or do it half-heartedly, because so much whacky noisy information comes in through Bottom Up information channels.

A young boy with little knowledge of the situation or consequences could have a big impact on a multi-hundred million dollar venture one day.  That boy’s message could be carried by the lowest ranking crew at the bottom of an airline food chain.  Respecting the people at the bottom and the insight a view from the front lines can offer is critical for success. Otherwise, the executive suite will spend much time “breathing its own exhaust.”  Or to use yet another tired metaphor, “running out of gas”.

• Air Transat Flight 236, Wikipedia
• Obama, Inviting Ideas Online, Finds a Few on the Fringe, NY Times
• Debate: Design, Analytics and Google

I’m glad I’ve read Stumbling on Happiness, by Daniel Gilbert.  Gilbert writes in an entertaining style that must keep his Harvard students rapt.  And the book’s concise summaries of studies into human contentedness are surprising and fascinating material.  What I conclude from this book is that happiness is neither complicated nor a pursuit.

It is a rather long detailed trip to arrive at Dr. Gilbert’s conclusion that happiness is not what we think it is.  In summary, his interpretation of psychological experimentation into human satisfaction:

1. Memory does little to help us remember what made us happy.  We tend to write our historical memories optimistically or pessimistically.  Whichever of these two perspectives we choose, idealized memories are unlikely to help us decide what will make us happy in the future.
2. Our imagination allows us to envision our future.  However, our feelings of the moment are likely to be the primary influence on that future image.  Then, even if memories are used to generate our future, those memories are of little use since they are optimistic or pessimistic (rarely realistic).
3. A host of environmental factors, perceptual illusions and biological bias make this situation worse quite often.  Evolution being the harsh task master it is, we choose what is best for our gene pool most often without realizing the cost to our own happiness.

The book helped me understand the scientific worth of many of the suggestions I have found useful in my own search for happiness.

1. Our perceptions change our reality and are most often arbitrary, affected by timing of events, illusion and societal programming.  It is useful to choose the perceptions we want to have and let reality fall into place behind those perceptions.  Sounds delusional, but it is really the norm with human nature.  Why not make it work for us, instead of against?
2. Being grateful for all that we have and the moment we are in right now is the best that anyone will ever achieve.  There is no better tomorrow, only a better now.  We just have to focus our minds on the cup half full.  Really it is there, it’s just as humans we tend to focus on what needs fixing.  You know, the half empty part.  It’s those genes trying to make us unhappy so we will work hard.  Turn those suckers off, be happy right now.
3. Purpose is a tremendously satisfying color of glasses through which to see past, present and future.  While Adam Smith pointed out that the original pursuit of happiness is a mirage, we can substitute whatever we want for money in that mirage and really be happy.  In other words, the economy runs on the false belief that if we are more successful we will be more happy.  However, we can substitute a calling or ideal greater than ourselves and pursue that instead.  This turns out to be an enormously rewarding pursuit (and still helps the economy and gene pool).

Stumbling on Happiness is a fun read, and an important look into the psychological reality we humans experience under the lens of science.  That science is truly valuable, even if it sends us off into the direction of delusional mirage instead of hard currency, looking for happiness.

• Chris Shattuck (who kindly suggested this book to me)
• Stumbling on Happiness, by Daniel Gilbert (via Amazon)
• The Daily Motivator:  Blue Pill?

Recently my family descended on me for a visit.  It was nice. Good weather. Good times.  However, I knew that my father (a talented engineer) and my nephew (a budding nerd genius) would need something more than pin-the-tail-on-the-WALL-E to keep them occupied.  Luckily I had a plan.

I went to the Maker Shed and bought a Drawdio.  Then I deposited the two nerds in my office with a soldering iron and some spare tools.  An hour later, our new Drawdio appeared (much to my wife’s consternation).  We now have one of the most irritating nerdy little musical instruments ever conceived of.

However, a grandfather got to teach a teenager how to solder and test an electronic circuit for the first time.  The feedback from the easy to build Drawdio is immediate and a riot to play with.  Yup, you guessed it, priceless…

• Drawdio Kit, $19.50 at the Maker Shed
• Drawdio video etc. via Lady Ada, a cool hardware hacking site

Talk of Federal Aviation Administration software or hardware certification leaves anyone “in the know” with a dark feeling of dread.  Therefore, it’s hard to tell folks that the process of certifying hardware and software for use on FAA certified aircraft is a straightforward and an enlightened process.  Justifiably, they think I’m nuts.

The truth is that these processes are straightforward.  The problem is really one of chicken and egg, egg and chicken, ad nauseum.  Most certification projects experience a seemingly never ending set of surprise delays and costs. It doesn’t have to be this way.  The problem is one of getting set up and understanding the key project control points.

First a little background.  The FAA uses a designee system.  FAA designees (or Designated Engineering Representatives, DERs for short) are engineering process auditors.  The applicant hires a DER to audit a certification project and then either recommend or approve the project to the FAA.  This is a great system.

If applicants had to seek approval from the FAA itself, they would probably never get certified.  Likewise, the FAA gets extra staff when needed, paid by the applicants themselves.  This keeps part of the FAA’s cost structure responsive to the market and paid by industry.

The FAA then uses standards created by committees staffed by the FAA and the industries using the standards.  So the final standards, though written by a committee, are not directly handed down from government.  These documents, RTCA DO-178B and RTCA DO-254, cover the software and complex electronic hardware standards FAA applicants must meet to put their gizmos on aircraft.

So what’s the problem?  There are two big problems.  For the sake of argument, I’ll call the first the chicken and the second the egg

1. DERs are paid to audit.  They aren’t paid to show us unwashed masses how to do certification.   DERs are only to point out, after the fact, what they found that didn’t get done.  It is a lapse in the independence they must retain, to dictate how an applicant should engineer a project.  DERs are not in fact supposed to help an applicant at all, just audit them.
2. The RTCA standards are meant to be general enough to accept many different situations, products and certification methods.  These documents try to address every contingency.  That doesn’t mean the FAA wants applicants to explore and try every possibility allowed by the documents.  For the most part, applicants need to stick to “the center of the road.”  Er, um, what document would that be?  It is hard to know, unless you’ve spent some time doing this, what the expected practices are, and how to translate the general documents into a set of actionable steps.

And there’s the rub.  The person with all the answers won’t tell you, and the manual sucks. It seems to boil down to this with computers fairly often doesn’t it?  Increasingly however, folks like me are distilling some of this critical information and capturing it online in ways useful to applicants.

I’ll be doing a fair amount of laying out best practices for FAA certification here in this blog and on the company website.  We’ll cover key parts of the documents periodically as we go along.  In the not too distant future I hope to have both eggs and chickens cooperating, and maybe even flying.

Zac Sunderland is about to complete his trip around the globe in a sailboat.  At 17, he will be the youngest ever to accomplish such a sailing circumnavigation.  To read his posts is to see a young man full of energy, intelligence and humility.  Necessary for such a trip in all likelihood, and uncommon at his age.  Cheers to Zac.

However, if you’ve been following along, or read back through some of Zac’s posts you’ll find lots of  thanks for a hidden army of helpers behind him.  Of course, his friends and family are tirelessly aiding him and supporting him.  However, other helping hands are guiding, repairing, sheltering him and facilitating his trip at every turn.

It takes a lot of moxie to do what Zac is doing.  It takes a lot of help too.  My point is, if we think about it carefully we are all in the same position.  Even if we don’t reach to the heights Zac is, we rely on a bunch of people to do what they do, for us to do what we do.  It is useful, I think, to extend our minds for a bit to think about this occasionally.

As social animals we rely on others and many rely on us.  I think I mostly regard my life as a ship on the ocean.  But big ships need a bunch of help too.

• Zac Sunderland blogging his trip around the world
• The Power of Nice: How to Conquer the Business World With Kindness, forward by Jay Leno
  
• Look Out For Number One: Give Thank You’s

There is talk about stimulus packages, and economic recovery.  There is also talk about cheap offshore labor and sometimes slave labor.  There is talk of more wars.  It seems to me that these are issues our country has had to deal with again and again in its short life.  We also have some new issues like global warming, finding sustainable energy and global (possibly nuclear) terrorism.

Being builders, we Americans tend to create new stuff to work through our problems. While we need a new spurt of innovation to meet new needs, I think that we also need to think, as a society, or as communities, on how to sustain innovation.  I think in the process we need to teach the world to fish.  The way to accomplish this is to funnel stimulus funds to inventors.  Some ideas:

• Scholarships to a Techshop type institution, or opening existing University-run shop facilities to the public.
• Scholarships for non-University students to get training in applied science, electronics, welding, chemistry, etc.
• Just like we have business advisers available through the Small Business Administration, we could have engineering and science advisers available.
• Encourage industry to support inventors through training and equipment by making such “inventor charity” tax-deductible.
• Subsidize the next generation of automated prototyping and manufacturing equipment, called fabrication machines.

Yes, this can be done on the cheap and still be effective.  Big company reform and the usual consumer-oriented stimulus might move the economy a little bit.  But if we decided to save the world, I bet this country could make it look easy. Let’s get out and build stuff together, and teach the world how to solve its own problems at the same time.  Hurricanes are coming, shall we get to work?

• Fab: The Coming Revolution in Personal Fabrication, by Neil Gershenfeld
• Techshop
• Shaping Things, by Bruce Sterling

I think groups going Agile need the one sheet Principles Behind The Agile Manifesto.  Short and clear, it has a good chance of galvanizing change.  In true contrarian manner though, I’d like to point out why blindly following these principles is a bad idea.

1. Our highest priority is to satisfy the customer
   through early and continuous delivery
   of valuable software.

   Most teams need to focus on delivering must faster with smaller iterations.  However, customers are not always satisfied just by valuable software.  We need to make sure we look at every aspect of what customers want.  Make sure you have an analytic method to listen to customers!  I’m certain you’ll be surprised.

2. Welcome changing requirements, even late in
   development. Agile processes harness change for
   the customer’s competitive advantage.

   Yup, there’s no point in complaining about late requirements.  They happen, and they are usually important.  However, it is critical to note that the vast majority of the quality, cost and delay problems in software stem directly from late requirements.  Get involved early to help make requirements development, from a business perspective, successful.

3. Deliver working software frequently, from a
   couple of weeks to a couple of months, with a
   preference to the shorter timescale.

   Yup, the more often a complete release cycle is done, the better off everyone is.  However, customers can be irritated and confused by software that constantly changes.  If so, find a way to make releases to a select group of “mavens” that appreciate the chance to use software before public release.

4. Business people and developers must work
   together daily throughout the project.

   Duh.  However, having this ideal and getting it to fly is something all together different.  Talented project management, a good understanding of the cultures and corporate cultures involved, and solid requirements processes are needed to survive this.  Ideas are one thing, knowing what actions to take is another.  If you’re not succeeding here, don’t wait.  Get help.

5. Build projects around motivated individuals.
   Give them the environment and support they need,
   and trust them to get the job done.

   I would just like to point out however that human beings are complicated.  If we don’t have goals and measures, subjectivity will lead to judgment, and then to emotionalism.  Not good.  We all like to think we’re above this.  We aren’t.  Get a performance methodology in place and use it.  I like HP’s Management By Objective.  In the long run, it will create the fairness to allow trust to happen.

6. The most efficient and effective method of
   conveying information to and within a development
   team is face-to-face conversation.

   This is a red herring.  Psychologists continue to discover all the ways humans use body language, gestures, micro-facial gestures, etc. to communicate while we are face to face.  That said, I’ve had super effective technical cooperation with people I’ve never seen.  Mind you, I don’t have a bullet proof recipe for virtual teams, but I’ve had them work wonderfully.

7. Working software is the primary measure of progress.

   Yes, yes, we’re programmers after all, right?  Wrong.  When we ship a product, what we really have is a relationship with a customer.  They give us money (hopefully) and we give them what they want.  It may be software, support or back rubs.  Maybe even prestige!  You know about the customer always being right, right?  As programmers we need to make sure we are getting measurable feedback that we are on track to a happy customer.  Think analytics.

8. Agile processes promote sustainable development.
   The sponsors, developers, and users should be able
   to maintain a constant pace indefinitely.

   In theory this is true.  It will rarely be true.  Reality can be crazy.  I’m not saying that being out of balance is a good thing.  However, if we accept requirements change at the last minute, we need to be ready to work quickly.  Life happens, sometimes fast.

9. Continuous attention to technical excellence
   and good design enhances agility.

   So often when deadlines hit the emphasis on doing the best job possible on the software slides out the window. However, engineers tend to noodle over stuff.  Do not get stuck looking for the “right” design. That’s what smaller iterations are helpful in doing, refactoring towards better designs.

10. Simplicity–the art of maximizing the amount
    of work not done–is essential.

    Just realize, doing something complicated is easy.  Simple is hard.  There may be several iterations of complicated before everything gets boiled down to simple.  However, always ship the simplest and most usable interface, no exceptions. If you’ve got tests, you can always clean up what’s behind the curtain.

11. The best architectures, requirements, and designs
    emerge from self-organizing teams.

    Yup, as long as the team has direction and no-one is actively trying to kill another team member.  There is nothing toxic about roles and responsibilities handed out by leadership.  The best teams self-organize, others might need direct help and facilitation.  Just be nice about it.

12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly.
    
    Continuous improvement is absolutely critical for everyone in the software field.  Fall behind and we are penalizing ourselves and our teams.  It’s easy to calculate the cost of everyone in the same room, and stop doing postmortems.  What is the cost of having poorly trained and performing folks adding to your source code base?

Okay, so I agree with this last principle without reservations.  With Agility, like any fad, there is an underlying truth to the doctrine.  However, blindly following a doctrine, even a good one like Agility, is a lemming’s plan.

Isms in my opinion are not good. A person should not believe in an ism – he should believe in himself. I quote John Lennon: “I don’t believe in Beatles – I just believe in me”. A good point there. Of course, he was the Walrus. I could be the Walrus – I’d still have to bum rides off of people.  — Ferris Bueller

• Principles behind the Agile Manifesto
• Deal With It: Retrospectives Are Postmortems
• Ferris Bueller’s Day Off
• A Firm Agile-ism Debunking from a Google Engineer
  

The Alchemist is a special book to a great many people, including me.  The story has all the things that tend to happen in life when searching for something.  It’s a fable I’ve already read twice.  Might just read it every year till I’m gone…

• The Alchemist, by Paolo Coelho
• The Dip, by Seth Godin

Designing data into art may be a key web skill in the future. As we get more and more data, companies will need ever more attractive ways to lure information saturated users. While certainly this kind of design has been around for a while, the newest work made for the Internet, visualized using Internet data is cutting edge great.

• [via] Neoformix
• Information Aesthetics
• Visual Complexity

In the wake of Air France’s recent loss of flight 447, and the resulting deaths of over 200 passengers, I am forced to revisit one of the most irritating analytic farces (and one of the most long lived).  Aviation experts, pundits and safety professionals will often flippantly instruct the less worthy that flying in an airplane is safer than driving in one’s own car.  If you Google for this, you will see a variety of arguments (concocted) to support this claim.  It’s all Bull.

I’ll tell you the mistake is ignorance.  But that is one of the insidious problems in analytics.  Conclusions based on numbers have an unapproachable claim to correctness in most people’s mind, an inarguable claim to the truth. So much so, that people actually make up rationales to support numbers that they believe without wondering for one second about the source and validity of such data.  Inevitably when the analytic methodology is examined, there is usually very little data, lots of assumptions, and often, a driving desire to come up with a certain answer.

Here’s how the plane safety one goes: the number of plane and car accidents per mile and per passenger are compared.  Using such a measure aircraft win on safety, with the airlines clearly the most safe.  This is the erroneous message we receive year after year.  The truth is that this is the only data available.  And it helps that it works out well for commercial aviation.  However, if we imagine that we could get some more data, what kinds of things might change this number?

• If one were to compare hours, things would change very quickly.  If one were to spend as many hours in an airplane as a car, you’d be more likely to get hurt in an airplane.  Its a more complicated system, with a much more severe consequence on failure.
• Cars are operated by anyone (often in any state of health or intoxication) with very little training.  Aircraft operators are highly trained.  To a lesser standard so are bus drivers.  If we hold ourselves to high standards, we too are among the safest.
• Airplanes hold lots of passengers, cars hold few.  If we instead compare vehicle hours, instead of passenger miles, how would the numbers look?

No doubt this kind of brainstorming can go on for a while.  The point is when we start looking at how our numbers are generated, we get a feel for how much data we do or don’t have.   And that leads us to how valid our conclusions are likely to be.  To be sure of ourselves, we’re going to have to ask a lot of questions and get a lot of different kinds of data before we can make safety statements based on numbers.

This was underscored in the aftermath of the Challenger disaster.  The Challenger space shuttle blew up on launch.  One of the people examining the safety numbers was Richard Feynman.  He pointed out that intuitively it was unreasonable to expect a vehicle that had enormous fuel tanks, white hot rocket engines, capable of traveling many times the speed of sound into space, to fail once every 300 years.  But that’s what NASA estimated the failure rate as.  The same kind of common sense can be used to compare my minivan with a 500 mph jet plane.  The van is the safer bet.

Dr. Feynman went on to look at the many factors that affected the NASA managers that produced the numbers: groupthink and pressure on management to produce good results.  You know the human animal’s social-psychological foibles.  Optimism in those who don’t know the details, but need to have good answers.  Bad estimates of risk, complacence, economic pressure, politics, plausible deniability and plain old wishful thinking all play their part in the vast majority of accidents in every vehicle type.  Apparently Dr. Feynman was right, as NASA played out the same bad decision making process later leading to the loss of Shuttle Columbia.

Now lets think about this:  the same human beings who make the mistakes that wreck the vehicles, also produce the numbers about how safe the vehicles are.  Hmmm, maybe we humans just show a lack of humility?  Maybe we just want to be convinced?  Maybe convincing others is leading them, making the bearer of the number more important, more powerful?  Sounds like what a social animal might do.  Our socialization would explain the ridiculous failure to question these clearly ridiculous numbers.

Analytics is a process of using data to deliver better decisions.  However, just because some data is collected, some numbers produced, does not mean the truth is discovered.  Analytics requires discipline and independence.  Discipline to understand the data and analysis thouroughly.  Independence so the person running the numbers is not the person to gain from good results.  Human nature being what it is, anything less is gambling.  We all know what happens in gambling over the long haul.

• Air France’s Flight 447
• An Air Safety Analysis, by a Flight Instructor
• The Space Shuttle Challenger Disaster
• The Space Shuttle Columbia Disaster
• Richard Feynman’s Personal Challenger Disaster Observations

The truth is retrospectives are postmortems.  Whether you call them code reviews, retrospectives or love-ins, the work is now dead.  There is no more time, or money, or energy or fresh ideas to work on.  We are just picking over its bones.  I think people dress up these events with nice names to avoid the connotation, and continuous problem, of postmortems turning into group slugfests. Fair enough.  Anything to keep the team from killing each other…

However, putting sunshine and spin on postmortems doesn’t actually get us closer to preventing our own repeated screw ups.  I look at it this way: In all things there is a up and a down, a positive and a negative.  So with postmortems I think we need to have a balance of the positive and negative to succeed.  The way to do it is in two phases.  The first is the yin, or touchy feely part.

1. Ask the developer to set up a meeting, invite the team, and show their code on a projector, walking through the code with everyone in the room.
2. Have the developer ask someone to take notes.  The idea is for this note taker to capture all the chatter that happens in the room as short bullet points.
3. Learn.  Listen.  Ask questions, but don’t codesmith.  Let the developer run the meeting and explain what they are doing as the code is shown overhead.  The team needs to resist the temptation to tell the developer what they think, or how they would do it.  Tell the team the truth, there is no one way, we’re all where we are.  Get over it and be nice.
4. Most of the time everyone learns something.  Every time the developer discovers bugs in their code.  It always happens.  Promise.

The second phase is the yang, the not so touchy feely part.  The purpose here is not to fault-find, blame or carry on about people not working hard enough.  That stuff is buck passing.  Go see a shrink or a priest.  To do this we need to know we are all in it together.  What this is about is trying to find and confront the parts of our efforts the outside world will not like, will not buy, will scream at us for:

1. Review the objectives set at the beginning of the iteration, project, milestone or whatever.  Make sure that you as a group lead are very clear with your stakeholders, boss, owners, customers, etc. about what those objectives are.  Sometimes at the end of a project it’s hard to remember how it all started, what the original plan was.
2. What internal issues are holding the group back?  Meet with the group to discuss the original objectives, the product goals, the quality, time it took, the resources, the test results, and anything else you are tracking.  Don’t bitch or whine.  It’s not their fault.  However, these things are the group’s shared responsibility.  Ask them what didn’t go well.  What do they need?  What wasn’t clear?  What do they want to do differently?  What random ideas have come up?  Do we need a whole new direction?  Take notes.
3. Now is the time to capture what outside the group is affecting it negatively.  What didn’t happen?  Why?  Were inputs clear, was teamwork there, was the design good?  Let’s see some accountability!  It’s not about blame.  It’s about: if not this group, who else?  Does management need to be told they are asking for the wrong thing, too much of something, or something stupid?  Maybe the group is just being set up for failure?  Are the customers really wrong?  Is marketing driving us all into the sea?  Did we take the time to understand what our stakeholders wanted?  Or did we build what we wanted?
4. The market is not a friendly place.  Your organization needs to defend itself against the others looking to steal your lunch (or make you their lunch).  Challenge the group: think fast people, what do we need to do better to survive?  What did we work on that really doesn’t matter to our continued survival?  We’re going to succeed or fail as a group, lets be clear before we get back to it.  All of us share the responsibility.

This twofold perspective is meant to capture the other side of the coin.  As businesses we cannot afford to loose sight of our competitiveness.  As software engineers we cannot afford to stop learning.  If blame is avoided in both phases, shared responsibility and teamwork can be built on both positive and negative.  Avoiding the negative isn’t going to help anyone, or make them feel better in the long run.  Meeting the challenge and succeeding will please all.  Nuff said.  I leave you with these:

This is a very important lesson.  You must never confuse
faith that you will prevail in the end – which you can
never afford to lose – with the discipline to confront
the most brutal facts of your current reality,
whatever they might be.
– Admiral Jim Stockdale

Let us not pray to be sheltered from dangers but to be fearless
in facing them.  Let us not beg for the stilling of the pain
but for the heart to conquer it.
– Rabindranath Tagore

Not long ago the idea of usability was new to web designers.  Now almost anyone in business today will need to start thinking about usability. Whether crafting an HTML message to customers, or evaluating a new product’s concept, usability is not just a topic for designers anymore.  Luckily Steve Krug’s Don’t Make Me Think is the classic book on web usability and can be read in no time.

Don’t Make Me Think doesn’t just address usability technicalities, though it does that.  It also covers a few simple usability principles that will keep most doing routine work out of trouble all the time.  Ironically, one of the most helpful things about the book is the advice it has on dealing with conflict between a web site’s creative, editorial and executive staff.

This is important stuff, not only is everyone different, other people’s notions of usability can be irritating.  It is important to make usability progress, avoid making terrible usability blunders and avoid design by committee.  No small order.  This book has some nice suggestions on these issues.

I think that usability is a commonly misunderstood topic.  Passing this book around is a great way to tune people in to what the issues are with even non-web product design. It can help educate those who are not actually designing anything.  You know, the folks with the money, folks passionate about good design, and those of us who just need to think less

• Steve Krug’s Don’t Make Me Think