We Hold On

It's common behavior in the technology arena to hold on and wait for the next big thing. Sometimes we wait for bug fixes. Sometimes we wait for new features. It's not just software – I've waited for phones and TVs because I know the next generation will be so much better.

Have you ever picked up a piece of hardware or software and said, "this is perfect - I can't imagine anyone ever making this better?"

If so - how long did that feeling last?

Malignant Narcissism

I've been thinking about getting a MySpace page, but first I need a good design. What do y'all think of this?

K. Scott Allen The K stands for Kewl My Interests C# AJAX Maple Syrup Daytime Soap Operas Other Kewl People Omniscient Eyes El Maliko Bald People Blogging Another Bald Blogger Soccer Boy A Wumpus Turn Ons Semicolons Curly braces Leetspeak	Pics of Me, Me, Me, Me, and Me
	K. Scott Allen Is In Your Extended Network!

Define: Web 2.0. It's about me, me, and me.

Good News First

Three Windows Mobile developers, Mort, Elvis, and Einstein, are sitting at the lunch table when their project manager bursts into the room.

PM: "Guys, I have some good news and some bad news."

Mort: "Tell us the good news first!"

Elvis: "Wait! I need to grab my laptop and take copious notes."

Einstein: "I have a theory about what you are going to tell us."

PM: "Be quiet and listen. The good news is that we bought iPhones for all the software developers".

Mort: "iPhones? But the product only targets Smartphones!"

Elvis: "Cool! Where is the SDK?"

Einstein: "You should've waited for an updated iPhone that includes GPS!"

PM: "The bad news is your iPhone is also your severance package. We've just moved all product development work overseas."

Bravest Face

One of my first evaluated public speaking events was a disaster.

In high school, my teacher filled a basket with index cards. Each card had a "topic" printed on it. One by one, we had to go to the front of the room and pick a random card from the basket. We then had 60 seconds to prepare a 5-minute presentation on the topic we selected. 

When it was my turn, I went to the front of the room and picked out a card. I looked, and my card said, "Break on through to the other side". I put the card in my pocket.

An abbreviated version of the next 60 seconds inside my head went something like this:

What does he expect from this? A motivational speech? I can't give a motivational speech! What are we suppose to break through? School? What's on the other side of school? This is terrible. I don't know what to talk about. I should say I'm going to the bathroom and pull the fire alarm.

Wait - this is a Door's song. Jack likes the Doors. I remember seeing another song called "Peace Frog". What a strange name for a song. "Peace Frog". Frogs eat flies.

Is my fly open? No. 

If my fly was open in front of class, Melanie Weigel would be laughing and telling the whole school. She's such a drama queen. One day I'm going to fill her locker with shaving cream – just to see the scene she creates.

Flys.

Frogs.

Frogs are green.

Kermit the frog is green.

I loved the Muppet show. Especially those two old guys sitting in the balcony, razzing on everyone. I wonder if the show is ..."

Ding!

With no escape in sight, I put on my bravest face and stood behind a little podium at the front of class. Having completely forgotten my original topic, I proceeded to ramble for 5 minutes about characters on the Muppet show. You can't go wrong talking about Muppets. Everyone loves Muppets!

I could tell by my teacher's expression he wasn't loving Muppets. He asked me what was printed on my card. When I pulled out my card and announced my topic, there was about 10 seconds of dead silence. Everyone was trying to figure out how I went from "Break on through to the other side" to a television show about hand puppets named Miss Piggy and Dr. Bunson Honeydew.

Grade: 2/10.

I've worked really hard over the years to get better, and stay on topic.

Faithless

I respect faith, but doubt is what gets you an education. - Wilson Mizner

Everyone starting a new software development project needs to have some faith. You might have faith in a particular tool, or programming language, or development process, or all the above. I hope you also have faith in yourself, and your colleagues, too, because that kind of faith gives your project a greater chance to succeed than any faith based in methodologies or silicon. At least this is what I believe.

Blind faith can be bad. It's good to occasionally look around with an open mind to see what works for the rest of the world. If you think your choice of programming languages is the best, for instance, go search for criticisms and look at alternatives. You don't have to switch to a new language, and you just might come away with a better perspective on technology and learn a few new tricks.

At least once a year, go faithless for a day.

Hope

Back in the old days (just last year, in fact), the stock disk defragmenter in Windows looked something like this:

If you had no choice but to defragment a drive immediately, then at least you could entertain yourself by watching little green and red stripes bounce around inside the window. A quick glance could tell you if the defragmentation was nearing completion.

Along comes Vista, with a new defragmenter interface:

The defragmenter takes more of a Hollywood "don't call us - we'll call you" approach. I haven't found any red, green, and blue bars moving around to pass the time.

All I have left is hope.

I hope this finishes.

I hope this finishes soon.

The Way The Wind Blows

You don't need a weatherman to know which way the wind blows – Bob Dylan, Subterranean Homesick Blues.

What direction does the wind blow in your software?

It's easy to feel the direction of the wind when standing outside, but software is subtle. One of the guiding rules in interface design is the Principle of Least Surprise (POLS). This principle states that developers should choose sensible defaults and implement behaviors that don't surprise or astonish users. We can use the rule as a guide when implementing a user interface, or building an API / library / framework.

POLS is more of a policy than a rule, though, because it's impossible to enforce a rule inside the gray zone of how users think. Typically, you have to pick what sort of user your interface targets, and try to give that class of users the least surprising behavior. 

For example, Subversion applied POLS like so:

We should behave as similarly to CVS as possible -- the Principle
Of Least Surprise. This is really important, and was not given
enough attention in the previous discussion imho. There's no
point being gratuitously different if we can be an intuitive
superset instead.

Of course, your approach won't make every user happy. You'll still need to make trade offs. In "10 Things I Hate About Ruby", Elliote Rusty Harold (author of Java I/O) is surprised by some of the conventions in the king of POLS:

Naturally you think the constructor would be defined in a method called new, right? Or just maybe a method called Car like in Java? But no, instead it has to be called initialize like this:

It's impossible to keep every user unsurprised, but it is possible to surprise a large percentage of your users. I tell people all the time that trying to disable the back button in a browser window isn't 100% possible and will astonish the users. Many users like the back button. I like the back button. Still, developers insist on trying to disable the back button. This tells me the software wants me to work under a different set of rules than I expect. When the back button disappears, I know an ill wind is blowing.

The Main Monkey Business

I want to ask you a question about ethics.

Let's pretend you've been working under contract to write a handful of components for some larger project. Nobody told you what the larger project really is, but the contract pays well and you've been given all the information you need to finish your work.

About the time you've reached the halfway point in your work, you uncover the goal of the larger project. The project is an application that will email thousands and thousands of phishy messages and collect information from users through a website. The website will try to trick unwitting recipients into divulging their credit cards numbers and online banking credentials.

At this point, you have to make a choice. Let keep this hypothetical questions simple, and restrict you to one of two choices:

1. Finish your work. Take the money.
2. Breach the contract. Cease work immediately.

Do you consider #1 unethical? What about #2?

Let's throw in one more option:

     3. Keep working on the project, but inject some monkey business.

What if, for #3, you delivered some code like this:

Or this:

Or this:

Those code snippets give the software problems that are hard to track down. Is #3 being unethical, or being a vigilante?

Note: I've never been in such a situation - I'm just taking a poll.

Spindrift

Once you've worked in as many software startups as I have, then you'll know there can be a Dilbertesque relationship between engineering and sales/marketing. If you use a microscope to examine the brain of an engineer, and the brain of a marketing person, then you'll find obvious biological differences - the brains are wired differently. The two brain types tend to blurt out dissimilar and conflicting ideas when sitting in front of potential customers, and thus we have plenty of stories to laugh about after the pain subsides.

When you return to the office from a "sales" meeting, all of your colleagues want to know "how it went". Since we don't have an empirical measure for these things, it takes a lot of explaining to describe "how it went".

Ship captains faced a similar problem describing wind intensity until Sir Francis Beaufort devised the Beaufort Scale in 1805. Let's say you are a captain returning to the pub after a rough day at sea. You meet another captain, who wants to know what the conditions are like. You could say, "There were moderately high waves with breaking crests forming spindrift – and streaks of foam, too." Alternatively, you could say, "Today was a total 8 on the Beaufort scale." The latter answer is shorter and helps you reach the pub in less time.

I've devised the "Sales Force" scale in the interest of saving time. Sales Force measures the intensity of the reality distortion field in a sales / engineering / customer meeting.

Sales Force Level 1
Description: Calm.
Conditions: Sales presented all the material prepared by engineering without alteration.

Sales Force Level 2
Description: Gentle.
Conditions: Sales presented some technical inaccuracies that nobody else noticed. For instance, "our database is written entirely in Microsoft's awesome C# language".

Sales Force Level 3
Description: Moderate.
Conditions: Sales made some statements you wouldn't agree with. For instance: "our application is totally using AJAX for an awesome user experience", when in fact only four web pages in 100 use AJAX.

Sales Force Level 4
Description: Squirming in seat.
Conditions: Sales is making some bold claims for scenarios you've never tested. For instance: "our software can scale to 10 million users without breaking a sweat".

Sales Force Level 5
Description: It's getting ugly.
Conditions: The customer just asked for a feature of such magnitude that only quantum computers cooled by liquid nitrogen could do the job. Sales replied: "yes, we have that in the plans for next quarter".

Sales Force Level 6
Description: Total WTF.
Conditions: Sales described some feature of the software you've never heard about. Perhaps this was something they dreamed, but you know they'll expect you to build it. Quickly.

Sales Force Level 7
Description: Apocalypse Now!
Conditions: Sales presented screen shots of a "shipping application" where the screen shots were actually UI sketches built in Photoshop by a tattooed designer named Pablo who never came back to work after last year's Burning Man festival.

Next time someone asks how the meeting went, you can just say, "Dude, it was a total Sales Force Level 7 meeting - I'm updating my resume". You'll get to the job boards even faster.

The Larger Bowl (a pantoum)

Let's start a blog -
we'll build a community.
We'll throw out ideas
for a world of diversity

We'll build a community -
attract like-minded thought.
For a world of diversity -
they all need to be taught.

We'll throw out ideas
if they refuse to adhere.
Let's start a blog -
is that an echo I hear?

Workin' Them Angels

Does Microsoft have a set of guardian angels? Think of all the killer threats they've seen over the years.

Threats came from Ashton-Tate, IBM, Lotus, and Novell
Then free software, open source, and the viral GPL
Oracle, Google, Sun, and Job's Apple
All four of them fought, and are still here to grapple.

There was AOL, Sony, Netscape, Nintendo
Palm and Symbian both reached a crescendo.
There are Linuxes and Unixes - NeXT and OS/X.
Some even say Vista is a suicide hex.

Bay Staters and Iowans both had their day.
So did the EU, Real Player, and the American DOJ.
People included Ellison, McNealy, and Judge Penfield Jackson.
If Microsoft were England, they'd all be Saxons.

There is the Internet, the web, and the network computers.
Don't leave out Java, or Ruby (with its great set of hooters).
XML, Hypertext, and a ubiquitous script.
They've all come together to give Microsoft fits.

If Microsoft does have guardian angels ... they've been working overtime.

Armor and Sword

We hold many beliefs in software development. We believe the tools we use are better than the tools "someone else" uses. We believe our process is better than the process "someone else" uses.

Too often I see technical people use their beliefs as a sword to attack someone else. Attacks rarely persuade the other party. More often than not, the attack puts the other party into attack mode. They have their own set of beliefs.

Use your beliefs as armor to strengthen your own position.

Don’t tell me what’s wrong with my approach- show me what works with your approach.

Persuade me with elegant solutions and successful results.

Far Cry

The Days Of Old

In December of 1998, I joined an Internet startup and dove into web development. This was also my first contact with Microsoft tools. I was a stranger in a strange land, having come from the world of embedded systems programming. Although I had written two Windows applications previously, I wrote the applications using Borland tools, and followed the Document-View architecture of Borland's OWL framework.

The startup put together a great team of hardcore C++ programmers, and we built a rich domain model. We didn't use the term "domain model" at the time, but a domain model it was, complete with a commercial, object-oriented database for persistence.

Enter COM

We chose to use classic ASP for the UI. To make our domain model available to ASP, we had to dress up our domain model in COM jewelry. COM provided the binary interoperability for ASP to call into our C++ middle tier. The artificial layer disturbed me and I wondered why we didn't write the entire application in C++. After all, there was this CGI / ISAPI approach we could use to avoid all the COM cruft. Thankfully, my thoughts along these lines never infected anyone else at the company.

Eventually, venture capitalists came along and told us we had to kick our object-oriented database into the street. If we wanted to support millions of users and roll like pigs in a sty full of cash, then we needed to use a scalable database like Oracle. With some homegrown code generation tools, we buried all the relational database cruft underneath our domain model (I've been a fan of code generation ever since). Again, we didn't think of our class hierarchy as a 'domain model', we all assumed this was how software was built. You keep the cruft outside the heart of your application, or the application runs the risk of infarction.

Over the next couple of years, we ripped through $60 million dollars in venture capital and joined a sock puppet in the Internet graveyard. I did some consulting and some video game work, and then ended up back in web development and the Microsoft world.

Enter .NET

.NET was an exciting technology to me. The middle tier and presentation layer could use the same runtime, the same string type, and even the same language. No artificial cruft! There was even a clean data access API in the form of ADO.NET. If that sound's crazy, then try to understand my perspective. Based on the majority of my previous work, I expected the following from a software tools vendor:

• Some library files
• Some header files
• A command line compiler

In other words, I expect a generic tool for building the least common denominator of applications. Visual Studio is more than just a command line compiler - it provides all sorts of designers and wizards, too. I initially found these additions interesting. Then I realized the designers and wizards only make short work of creating an application, which misses the hardest part of software development.

The Hardest Part

One thing I've learned over the years is that writing the initial code for an application is easy. No matter how much you struggle with language syntax, or thrash around to find the magic incantations for a finicky API – the initial code is easy. At least relatively easy.

The hard part is coming back and changing the initial code. This is an area where many of the designers and wizards in Visual Studio fall flat, or lead developers in the wrong direction. For instance, the typed DataSet generator requires you to fill in all sorts of information about your data source, yet it doesn't detect simple schema changes that can break an application. The declarative data-binding features with embedded SQL commands make drag and drop development simple, but produce a brittle application that is resistant to change. Visual Studio seems headed in the wrong direction for enterprise developers.

When the inevitable changes come, the best weapons I've found to have in place are refactoring tools, unit tests, and a rich domain model. Refactoring tools help you make common changes to a code base, while one of the many benefits of unit tests is that they can ensure those changes didn't break expected functionality.  The domain model / business layer is the heart of the application and is what differentiates each software project. Everyone has user interface code, data binding, and XML parsing. These are the easy parts to pick up and maintain from project to project. The business logic is unique, and deserves isolation and maximum clarity. 

Visual Studio only provides a unit-testing framework in high level SKUs. Refactoring tools exist in Visual Studio, but are cumbersome. A rich domain model? Don't expect too much help from Visual Studio in this area. The good news is we might be getting closer in the future with an entity framework– or at least we can still hope.

Where Are We Now?

Visual Studio is a far cry from the land of command line compilers, yet it's still far cry away from what we need for non-trivial applications. That's ok - we should never expect a single tool or environment to give us everything we need. Instead, we need to apply thinking, theory and design with a mix of the best tools available for the job at hand.

The good news is there are plenty of resources and tools available outside of Visual Studio. Here are some links to resources and tools I know. If you are only using Visual Studio today, I'm sure you can find something in the list to improve the maintainability of your application.

Reading

• Karl Sequin's Code Wiki
• Scott Bellware's blog
• Jeremy Miller's blog
• David Laribee's blog
• Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

Tools

• NHibernate for .NET
• LLBLGen
• Wilson ORMapper
• SubSonic
• CLSA.NET
• Resharper
• NUnit
• MBUnit

Now For Something Completely Different

For years, I've owned a note pad where I jot down thoughts. My note pad is electronic now, but the purpose is the same – capture an idea before the current of the day sweeps the idea away. Keeping an idea journal isn't a new concept. Comedians, scientists, writers, professors, inventors, and others have found inspiration in their notes for centuries. My notes have certainly provided stimulation for this blog.

I have a section in my notebook to store "blog-able thoughts". Over the last year, however, many of these blog-able thoughts haven't seen the light of day. I have time constraints, but I've also had reservations. I began to have reservations when I realized more people were subscribing and reading these posts. I felt like I'd be wasting your time if I write opinion pieces and rants, both of which are cheap and readily available on the Internet. I've also purposefully avoided specific topics because I didn't want to contribute to the echo chamber. This reserved approach has turned blogging into a chore, and chores are no fun – just ask any teenager.

I need to shake this blog up, and clear out my notebook.

The tag line on this blog is "Experiments in Writing". When I started, I intended to write about experiments (by demonstrating code that works (or doesn't work)), as well as experiment with writing (by throwing in the occasional comedy, poem, or piece of art). The time has come for a writing experiment. I just picked up the last music CD I purchased, and I'm going to use the track titles as the titles for my next 13 posts. I'll try to match the titles with thoughts in my notebook for some stream of consciousness writing on software development, ala Jeremy.

This was just a fair warning to anyone who doesn't like wasting time on opinion pieces. You might want to check back in July.