I had previously been doing business under a different brand name, which was somewhat corny and I will not utter it here nor embarrass myself with my programmer-created artwork.  The business name change went through a few weeks ago so it’s now safe to introduce myself as the owner of Hand Waver, LLC.

The logo was done by http://www.aftermarketrobot.com/ , taking some time off of their world domination plans to help me with a brand.  What do you think?

Read Seth’s latest article.  Read it twice.  Now, I’m going to quote my favorite line:

“The obvious reason is that the person at this post office has no incentive to make a sale.”

The person at the post office and indeed the post office itself has no reason to make a sale.  If the post office loses 50% of it’s business nothing happens.  That is because you, the taxpayer, will provide them with a wheelbarrow of cash to fund their operation no matter what.  Imagine if the post office had to compete with FedEx to carry your mail?  If my neighborhood garbage pickup was competitive would they stop losing the lid to my garbage can for fear of losing my business?  Now imagine the (very likely possibility) all incentive is removed from providing you with health care, that the hospital is looking for any reason to get to no.

The people who think we need more, or different, or smarter regulations are missing the boat.  It is human nature, and the nature of life on Earth that would have to change in order for the USPS to have the same motivation as FedEx.  We can’t keep making rules contrary to our best interests and expect no consequences.  We cannot simply pretend there is no difference between working for incentive and “collecting a paycheck”.  We cannot keep claiming that while we can connect the world with technology, plan missions to Mars, and constantly push out our understanding of reality we “could never solve the logistical problem of of privatizing bulk mail”; that “health care will never work unless the government takes over.”  The folks who claim this is the case are looking for any reason not to Get to Yes.

Created by Train Horns

High frequency hearing, particularly in men, tends to drop off noticeably as you get older.  Because my audio elitism goes only so far I naturally assumed I could not hear the so called “mosquito ringtone.”  However I can indeed hear this sound in all its annoying glory.  Give it a try.

I just learned that my Image Hotspot Designer article was mentioned on TCS Weekly #005:

http://channel9.msdn.com/shows/TCSWeekly/ep005/

The article is mentioned briefly around 2:30 in the video.  Now the entire world knows about my love of wine and my messy (if well supplied) office.

I have taken first place in the most recent Silverlight: Write and Win contest on SilverlightShow.Net for my article on creating a Designer for Image Hotspots in Silverlight.  Thank you judges!

Despite the obvious advantages of approaches like Scrum, deadlines are a fact of life in the business world.  There are what I consider “artificial deadlines” and “real” deadlines.  If a sales person and a client agree, in a vacuum, that Feature X needs to be done by March 27th, that is probably an artificial deadline.  Where did this date come from?  Is it even possible for Feature X to be done at all, let alone in this time frame?  “Real” deadlines involve some real-world event happening which is going to happen whether you’re ready to take advantage of it or not.  Silverlight must be able to stream video before the Olympics.  The industry trade show happens on this certain date.  We will run out of operating cash on this date.  These are real world events that present a risk or opportunity; they will come and go even if Feature X never happens.  I know of no hard and fast rules for separating real deadlines from artificial ones, but there’s often a certain “taste” to the artificial ones.

Regardless of the real-ness of a deadline, committing to one should not be taken lightly.  Even if there is no real business consequence for missing a date, it affects your credibility.  Consultants who lose credibility have a hard time earning long term success.  Employees who lose credibility get “tuned out” by their co workers over time.  Products that lose credibility sit on the shelf/lot/floor.  Companies who lose credibility have a hard time earning and keeping customers.

Nonetheless, sometimes a deadline that you’ve agreed to simply cannot be met for any number of reasons.  This is often OK, but I try (not always successfully) to follow one simple rule I learned 9 years ago from a much more senior consultant:

You can only push a deadline out by an amount of time equal to {Deadline} minus {Today}.

For example: if the deadline is in a month I could conceivably push it out another month without looking like a moron.  If the deadline is in a week I could ask for another week.  If the deadline is 2 days I could ask for two more days, or partially deliver, or pull some heroic hours and get it done anyway.

This isn’t an arbitrary statement, we can see how this makes sense.  Consider a situation where the deadline is 5 business days away and you ask for two more months.  Did you leave the biggest risk or uncertainty for last?  How intelligent was that?  Did you do a poor job of discovering what needed to be done?  Did you over-promise on how quickly you could deliver a solution?  Did you agree to various scope changes without any concession on timeline?

To put it differently, we can propose a way to calculate the magnitude of the planning/managing/over-committing/qualifying mistake.

let maxPushbackDays = deadlineDate – today; // give us a number of days

let pushbackDaysRequested = someNumber; //How much more time are we actually asking for?

let mistakeQuotient = pushbackDaysRequested / maxPushbackDays; //Give us a quotient

Here’s some simple math that gives us an arbitrary number.  If my maximum sensible amount of time I can postpone delivery is precisely equal to what I ask for, I get a “mistake quotient” of 1.0.  If something is due in two days and I ask for two more business weeks, I get a much higher mistake quotient of 5.0.  If something is due in 10 business days and I ask for 3 more days, I get a mistake quotient of .3.  Missing a deadline is never good, but it may help to think about things in a quantitative manor in order to plan what you’re going to say and how you’re going to say it. At an MQ of .3 you might only need to say “If you look at it this way, it’s really not that bad, we’ve discovered this misconception early enough to correct scope and deadline now…” whereas at 5.0 you might need to have a very compelling story indeed.

Of course, with “real” deadlines it’s different.  If the Olympics come and go and you didn’t take advantage of the opportunity, what then?

Back to basics: If you’re going to be late, it’s best to let it be known as soon as possible so there’s time to react.

My entry for the latest Silverlight code contest has been posted over on SilverlightShow.Net.  Go and check it out!

I had to comment on the latest Hanselminutes podcast.  I would absolutely love to do an article in the same style as AGT, but building up a Document instead.  I have not written a document/text editor from scratch so I would be starting from zero knowledge, but it sure sounds like fun.

There's at least 10 more AGT articles to go, so don't hold your breath.

"Everyone wants to save the planet, but no one wants to help mom do the dishes"

-Unknown

We are increasing the failure rate of projects and decreasing quality of- and relevance of- software projects in America by the way we treat our top performers.

I have written in the past about what I feel is one of the greatest sicknesses in Corporate America - namely that businesses have an impendence mismatch between that which will actually help the organization meet its goals and that behavior which finds itself rewarded in the same organization.  I haven't always put it so gently.

The Corporate Ladder, and the drive to climb it,  is having a negative impact the profession of Software Architect.  The Software Architect is in some ways falling victim to what I call Fry Cook Syndrome.  In my late teens and early 20s, I was a fantastic burger flipper and all around food production prodigy.  A point comes when the owner/manager can no longer justify further rewards to a lowly burger flipper and so I was promoted to Supervisor.  The problem was, although I could make delicious burgers and a beautiful sundae I was not in possession of any leadership abilities.  Sure, working hard and leading by example is a step in the right direction, but it won't turn a sarcastic college kid into a good leader.  Furthermore, the business had lost a top producer in the attempt to reward him.

While I joke about Fry Cook Syndrome all the time this article isn't about Architects getting into something they aren't suited for.  This is about the how the organization recognizes and rewards Producers.  We have some groundwork to lay down before we tackle the core issue: Titles, Perspectives, and Recent History.

Title Wars

I once worked at a consulting company where for a long time we were able to pretty much choose our own titles.  This led to one person calling themselves "Senior Internet Architect".  Not to be outdone, the next person crowned themselves "Principal Architect", while a "Chief Enterprise Architect" won the day.  I have even heard of someone who calls themselves a Galactic Architect; presumably the architectural needs of the Galaxy trump those of the mere Enterprise.  Attaching nonsensical names to ourselves as part of an effort to be "More Architect-y" than the next Architect is clearly a sign of cultural sickness.

Perspective

I was recently operating under the ostentatious title of Director of Solution Strategy.  In a way, I'm at a crossroads where my current position would lead easily into a more management or Enterprise centric role on one hand and back into more solution architecture and technical leadership on the other.  One thing that has repeatedly spilled out as I have meetings with interested parties is that I need to ship systems  right now and I don't want to get further from directly solving problems.  There is a process of turning requirements into code and fully participating in it means getting your hands dirty.

I was once working with a most excellent architect.  He understood his particular business, was a great abstract thinker, could write code as good as anyone's, but he felt he had an issue with how he and his group were fitting into the organization.  The high level architects, he claimed, needed to get away from "shepherding projects".  I never forgot this statement for two reasons.  For one, I thought that "shepherding projects" was a good way to put the leadership responsibilities of a good architect.  For two, I thought "Well, what else should your team be doing day-in, day-out?"  When did it become taboo for technical people with Computer Science degrees to write code?

In other words, who's going to help with the dishes?

The Evolution of the Architect in Corporate America

As of the time of this writing I've been programming in The Real World for about ten years.  While I cannot personally say this with any degree of certainty, I see enough anecdotal evidence from talking to More Experienced folks that there was a time when the average software developer was more technical; back when there was a Computer Science degree but not an Information Systems degree, perhaps; back when everyone looking for programming work had done their share of pointer math and taken a compilers class or studied the Unix source code.  As more and more businesses discovered the benefits of software systems, the demand for software developers grew faster than the supply.  The supply did not show signs of increasing at a satisfactory rate for two reasons.  The first reason was that a career in Computer Science or any core Engineering discipline was even less sexy in the recent past than today.  It just does not attract people in large numbers and the culture seems to be especially abysmal at attracting women.  The second reason is that compared to many other things Computer Science is hard for a lot of people.  Hard coursework weeded out a percentage of the people who were otherwise interested in being a software developer.

While an answer to the first problem seems to require a massive cultural shift and may only take time, businesses and colleges conspired to create a partial solution to the latter issue.  The Information Systems degree and its derivatives were born.  In these degrees the math component was toned down a bit - most of the businesses did not require programmers with hard core knowledge of Calculus.  The programming was toned down - you might still take C++ classes and write data structures from scratch but you wouldn't be studying compilers or Unix source code.  Businesses soon began to write real systems in higher level languages, so soon C/C++ was considered optional as well. 

Some people come out of these programs and thrive, some people demonstrate a career-long lack of polish stemming from lack of a true Computer Science background.  Only some parts of a system really required this training - Parts like the high-level technical vision for large systems.  The Architect of a system came to be known as the smartest guy in the room, needed to keep the simple proletariat developer in line...

The Problem

I assert that for various reasons there are not enough high level technical people focusing on Solution Delivery because everyone wants to be An Architect who doesn't get their hands dirty in the lowly tasks of writing code or requirements.  When I talk about people involved in Solution Delivery I mean the people who create the architecture for a solution, implement some of the use cases or modules, help other developers get things done.  I'm talking about the people who go to requirements meetings to help the business, and come back to find a line of people looking for code-level help waiting at their workstation/cubicle/office.  These people might be discussing the impact of frameworks on their project with the Galactic level Architects.  These people are on the conference calls with partners.  These people are often considered to have the best estimates, the most accurate perspective, the people you go to if you want to know how the project is really doing.

Companies large and small need people who can help get things done.  As Joel recently wrote, this can often mean that writing code is the most valuable activity.

This might be a good time to re-read Philip Greenspun's ancient wisdom.   A good software developer is often ten times more productive than a mediocre one.  A good software developer who is capable of higher-order abstract thinking, with some leadership abilities, who is not oblivious to organizational politics will often rise to the level of Some Kind of Architect.  Some times this is good, other times the company has just pulled a Fry Cook Operation and in the process hurt themselves and the entire profession.

Businesses are using career path and compensation to incent people to endeavor to become higher and higher level architects and avoid writing code.

Geek Culture is subsequently being transformed in such a way that the title of Architect is becoming more about prestige and pay grade than about one's duties.  I've even seen people declare that they "Architected the HTML and JavaScript for these pages...".  Is that their way of saying "I am awesome at HTML and JavaScript", or a way to declare that they are not "just a mere programmer" ?  I wonder.

The problem is that businesses don't understand the value of writing good code, the true value.  The developers with a proper mindset of Software Engineering and Craftsmanship may very well be providing their highest value possible to a business when they are turning requirements into code.  Too many managers view writing code as a low-value task, something that's just a stepping stone on the way on the way to something bigger.  This ultimately leads to a culture where writing code becomes a "guilty pleasure".  The organization goes about systematically promoting the best developers and the organization suffers for it.  "What can I do?", a manager might wonder, "I can only pay a software developer $75,000 but the pay scale for Enterprise Architect goes up to $125,000."

Nonsensical constructs like this will quickly motivate people to do anything to attach the word "Architect", or "Architected" to themselves or their work.  As Phil so rightly observed, great developers can often implement large systems or tremendous modules entirely on their own, but the organization fails to recognize this as an extremely valuable talent that ought to be rewarded.

Call to Action

None of this is to say that we don't need great Software Architects.  Hell, I (like everyone else) consider myself a great Architect/Application Designer and sometimes those skills are just what's needed.  Businesses big and small need to stop considering writing code a low-value activity.  Software Developers need to have soft skills just like everyone else today.  We need to recognize the value of great developers, we need to recognize that highly skilled developers with human skills who can also quickly turn requirements into code should be rewarded in proportion to the value they deliver and not because of an ostentatious title.  We need to remember that it takes True Craftsmen to deliver great systems and that Craftsmen should not be second class citizens.  We need to be sure that people can be successful without needing the title of Principal Inter-Galactic Senior Integration Architect.

Now, if you'll pardon me, I have some UML diagrams to finish.

I was recently interviewed for The Thirsty Developer podcast.  We talked a bit about home audio but the main conversation dealt with AGT, Silverlight, and the topic of visual tools in general. 

The next AGT article should be out this weekend or next week.