People who’ve never programmed or written large amounts of code will sometimes mistakenly, apres a few pints, ask me about it. One thing pints will do is guarantee you a long answer from me. The one aspect I often describe that tends to surprise non-techies is the art and authorship aspect of writing code.

Fictional friend says…”I just thought code was code, I didn’t quite realize there was an art to it.”

Ultimately, writing code is no different than traditional writing where the result’s are novels, articles, etc. A hundred different authors will write about a topic in a hundred different and unique ways. Most will be painful to read and downright ugly but will achieve the task of conveying the details of the topic. You can achieve success in the result of conveying a topic without people actually enjoying the act of reading it.

Writing code is no different. A hundred different developers may all achieve the end result the code is meant to achieve, however, a minority will do it in a graceful, well crafted way. Generally speaking, no one wants to read other people’s code but if you have to it’s a rare pleasure to read good code.

We’ve all heard about disruptive technology, maybe even choked back Clayton Christensen’s sometimes painful prose which lead to the term. Did you ever think that the pizza industry had to watch out for it though?

Super Fast Pizza

“Our high-tech Mobile Kitchens are licensed restaurants. We outfit them with Custom Ovens that can cook your pizza at a speedy 600 degrees. Our Mobile Pizza Kitchens utilize the latest in wireless internet technology, and produce enough electricity to power your home. (And they look pretty sporty too!) Remember, we cook your pizza while we drive to you. “30 seconds from our oven to your door” insures your pizza arrives hot every time.”

Years back, I took a 3 day course on Design Patterns. I’ve never been successful in acquiring knowledge in the classroom format, however, the course did provide a thorough introduction to the idea of design patterns as applied to software development.

It’s always irked me how little props are given by software folks to the originator of the idea of patterns, that being Christopher Alexander. While the concept of reusing patterns of problem solving have been around longer than dirt, it was Alexander who formalized them with his books The Timeless Way of Building, A Pattern Language, and The Oregon Experiment. I believe the rest of the history consists of Kent Beck and Ward Cunningham playing with the application of these ideas to software design back in 1987, presenting their results at OOPSLA that year.

Some pattern related links…
Design Patterns Java Companion
Patterns and Software: Essential Concepts and Terminology
Pattern Depot
Chapter 1 from the book – Pattern Hatching
JavaWorld Java Design Patterns
Design Patterns in Java Reference and Example Site

Some old rewards related quotes to make you love your paycheque…

“Not only are financial rewards not the most important thing to most people, but a substantial body of research has demonstrated, both in experimental and field settings, that large rewards can actually undermine intrinsic motivation. This process involves self-perception and retrospective sense-making: If someone works for a large reward, when called upon to account for his of her behaviour, the reward is a salient explanation – I did it for the money. When working hard for less money or for money that is less salient a rationale, people will come to see intrinsic interest in the work or the organization itself as their motivation.
An emphasis on financial incentives is controlling, and this control can set up psychological reactance in which people rebel against attempts to control their behaviour. ‘By making that bonus contingent on certain behaviours, managers manipulate their subordinates, and that experience of being controlled is likely to assume a punitive quality over time.’”

“The legendary statistical consultant W. Edwards Deming, with his characteristic gift for understatement, has called the system by which merit is appraised and rewarded ‘the most powerful inhibitor to quality and productivity in the Western world.’ He adds that it ‘nourishes short-term performance, annihilates long-term planning, builds fear, demolishes teamwork, nourishes rivalry and …leaves people bitter.’ To this we can add that it is simply unfair to the extent that employees are held responsible for what are, in reality, systemic factors that are beyond their control.”

“All this is not to say that pay is unimportant to people. If individuals are not treated fairly, pay becomes a symbol of the unfairness and a source of discontent. If the job, or the organization, or both, are basically unpleasant, boring, or unchallenging, then pay may be the only source of satisfaction or motivation in the work environment. But, creating a fun, challenging, and empowered work environment in which individuals are able to use their abilities to do meaningful jobs for which they are shown appreciation is likely to be a more certain way to enhance motivation and performance – even though creating such an environment may be more difficult and take more time than merely turning the reward lever.”

“As Bill Strusz, Director of Compensation at Xerox’s US Customer’s Operations division, is fond of saying, if you focus solely on compensation and change compensation only, you will get two results: nothing will happen, and you will spend a lot of money getting there.”

“To this point, I have argued that money’s role in the context of work is less prominent than we have assumed. When we widen our inquiry to look at the significance of money relative to life itself, the results are even more striking. As the sociologist Philip Slater once remarked, ‘The idea that everybody wants money is propaganda circulated by wealth addicts to make themselves feel better about their addiction.’”

“Organizational incentive systems send important messages about how and what the organization thinks of its members. A system that is reasonably complicated and comprehensive, rewarding myriad micro behaviours, sends the message that management believes people won’t do what is necessary unless they are rewarded for every little thing. A system of micro-level behavioral or outcome incentives also tends to convey an absence of trust, implying that people must be measured and rewarded for everything or they won’t do what is expected of them.”

“Individual incentive schemes erode teamwork and trust and set people against one another in a competition for rewards. Such systems do not promote sharing knowledge. Why should I teach you if we are competing for a fixed pool of salary raises? Such systems also don’t do much to promote concern about organizational well-being. Climbing the corporate rank or salary ladder becomes a more important objective than ensuring the organization’s overall success, particularly if job security is limited and the real goal is to get ready for a move to the next job, building a track record through a salary history and not by actual accomplishments.”

“By emphasizing financial rewards above all else, organizations signal that money is basically all they provide to those who work in them – not fun or meaningful work, only pay. Intrinsic motivation diminishes.”

Another good link courtesy of Joel. The article is about a software developer attending a course on lean construction management since the so-called ‘old trades’ have it all figured out.

“What are you doing here?” they asked.

They were construction foremen, superintendents and project managers attending a course in construction planning from the Lean Construction Institute (LCI). Indeed, what was I doing there?

I started to explain: “In software development, we are told we should manage our projects like construction projects, where a building is designed at the start, cost and schedule are predictable, and customers get what they expect.

”Silence. “You’re kidding, right?” “No, honest, that’s what we’re told.””In my construction class, the idea of “freeze the design” meets the same fate as “follow the master schedule.” Laughter. Not only is freezing the design impossible, but given the long building times in construction, attempting to do so is sure to make the real customer – the people who move into the building – unhappy with the result.”

During the look-ahead period, incomplete designs are identified and arrangements are made to fill in the blanks. In the same way that lack of materials is the biggest cause of construction delay, lack of requirements is the biggest cause of design delay. The ‘Last Planner’ system pulls in requirements just as it pulls in materials, and LCI recognizes that designs done as late as possible are often the best. In fact, they recommend that design decisions be made at the ‘Last Responsible Moment’ even as materials arrive ‘Just in Time’.

The above quote reminds me of most traditional software processes and their attempts to delude people into thinking that certain elements are frozen. There are stages such as code-freeze, featured-freeze, etc. While these processes are certainly well thought out and battle-hardened they are also troubling in the possibilities they ignore. The reality that we prove to ourselves time and time again is that code, requirements, features, etc are never frozen.

Why is this a problem? Let’s look at requirements since the issue is similar on all fronts. Developers are often asked to adhere to requirements that no longer make sense. The process of implementation continually clears an initially muddied picture. We learn a ton through the act of writing the actual code.

The concept of freezing requirements places a developer in a difficult spot. They have to either admit that the requirements they wrote were ‘wrong’ and correct them given current information and understanding, or stand their ground and argue that their original requirements were sound. The latter most likely involving deluding themselves or ignoring the reality of this new context. To be clear, what I’m talking about here are requirements that were valid when they were written and have been invalidated over time. Invalid requirements are still invalid requirements and I’m not talking about a process of correcting poorly crafted work.

Forcing developers to admit that their requirements were incorrect in this style of environment is toxic to that individual. As a programmer, not being able to write valid requirements means you may not be capable of designing software, which means you’re nothing more than a code jockey. This makes little sense. The original requirements were valid in the context they were written. That context has changed so it’s reasonable to assess whether the requirements should change.

The reality is that requirements are never frozen. Should we willy-nilly change requirements day in and day out? Obviously not or we won’t finish anything. If, however, we embrace this reality and drag it out of the developer’s closet then we can look to leveraging it to improve our work. Construction’s adoption of the idea that “design decisions be made at the ‘Last Responsible Moment’” is a good example of facing these types of realities.

The alternative is having a developer spend their valuable time and energy forcing the square peg of an out of date requirement into the round hole of an implementation phase. This wasted energy cannot be underestimated. You now have a developer using their creative energies to write code to invalid requirements.

None of this line of thought negates the need to craft the most accurate requirements possible at any point in the design, including the beginning. What’s being suggested here is that we should strive to make developers comfortable with the fact that the requirements they write can become invalid during the implementation process. That’s a reality we wish to deal with straight on, and it is in no way a failure on their part. This last part is the key. Developer’s must understand that a requirement that changes, or becomes invalid during the implementation process, is not a bad thing or a failing. Address the changes, learn from them and move on.

Ok I get why I’m obsessed with playing ice hockey. I grew up in small town Canada with a father who dabbled in the game himself. How do you explain Guy Kawasaki‘s passion for our game, a Hawaiian living in California?

I love the way he describes his new religion:

These are some old notes from my time spent in more “traditional” organizations, reworked for the year of the dog….

One of the more intriguing parts of introducing a new review process in which people are asked to review their managers, is how those managers respond. Not how they respond to the actual reviews but how they respond to concept of being reviewed.

I’ve witnessed this several times and it universally involves a lot of tedious arguments. The managers throw their arms up and resolve “fine, go ahead but it’s a mistake”. They demand a line in the sand that frees them from being held accountable to the content of the reviews. The reviews must not be kept on their files, “it’s just a waste of paper”. They request that reviews only be used by the manager under review in order to improve their behaviour as they see fit, and that’s all.

In making these arguments the managers produce all kinds of excuses and justifications. The people who work for them don’t understand what their jobs really entail. They don’t see all the behind the scenes work they have to do. They don’t understand how difficult their jobs really are.

What you will rarely, if ever, see is a manager in the midst of a group of other managers having one of these earthshaking discussions reach a moment of true clarity. “Wait a minute, maybe that’s the point? Maybe this whole review thing just doesn’t make sense…for anyone? How could it be such a great tool for us to use on our people yet such a wrong tool for our people to use on us? Maybe the point of this exercise is for us to realize and understand that there are flaws in this concept?”

Oh to dream.

Meetings cost time and are both physically and mentally draining to people involved. They can also be valuable tools for people in getting to know each other and solving important problems cooperatively.

Every company I’ve ever worked for has too many meetings. Somewhere along the way we forgot that no one’s actually working when we’re meeting. Meeting is not working.

Love them or hate them it’s tough to argue that meetings are free. They cost money, at the very least they cost salaries. Maybe the people holding meetings need to be accountable for those costs?

Maybe companies should charge people for holding meetings? I know some companies charge the appropriate project budget for the incurred salaries of the people sitting in those meetings, however, that’s just a client billing. If you want to drag the CEO, the CTO, and 5 developers into a 3 hour meeting then that’s fine. You will, however, have to play that return on investment(ROI) game that MBA types love to talk about.

A related Fast Company article, Change Is Sweet

It’s nice to see an idea clearly stated that’s been jumbling around in my head for years. Choosing a business name, or domain name, isn’t about taglines, service offerings, etc. It’s about memory.

The only rules I have in choosing a domain name are:

• Difficult to spell wrong.
• Easy to remember.
• Easy to accurately convey to someone, support viral marketing, ie. broken telephone syndrome.

Does Amazon make you instantly think of a bookstore? Does Google have you saying to yourself ‘sounds like an internet search engine to me’? No but how easy is it to remember how to get to Amazon on the internet or how to tell your buddy where you bought your last book? It’s dirt simple and when was the last time you heard someone say they couldn’t figure out how to spell amazon?

I first tried O’Reilly’s Safari bookshelf by signing up for a free 14 day trial last summer. Eventually I moved to their personal version until finally landing on clearspace acquiring our own corporate package which offers us all slightly better rates.

I’ve tried one competing offering out there, that being Books24x7. Their interfaces, number of books, prices and features differ only slightly. The main differentiator is the books in their libraries, ie Wrox versus O’Reilly. If you prefer Wrox books, you’re best on books24x7, if you prefer O’Reilly then get Safari. Actually, just try them both out as I believe they both offer free trials. I ultimately prefer Safari because I have always trusted O’Reilly books in general.

To be blunt, I’m unsure how I coped without this. Regardless of which service you choose, the bottom line is you have instant and complete access to over 3000 books. For me, this supports my work in a far better fashion that traditional books. I need to quickly research a topic by hearing or reading a variety of voices and opinions. In the past I would rely solely on the free publishings on the internet. For anything more in depth I would search around on Amazon, do my best to pick a reputable book on the topic, and either order and wait days or head to the local bookstore and hope they have a title.

At best I’m able to get a book that day, most likely paying $50 to $100, at worst I’m waiting up to a week. If I’m lucky I choose well and end up with a book that solves my problems. If I make a crappy choice then I’m stuck with more useless dead trees. With Safari I have instant access to over 3000 titles allowing me to hunt around in a multitude of books in order to get a well rounded perspective on the topic at hand for the cost of about six books a year.