“Without appropriate design, yesterday’s success is tomorrow’s straightjacket, since today’s great applications are tomorrow’s legacy systems.”, Buxton.

We’ve all worked on projects with ‘crappy code’. How do they get like that since none of us writes crappy code? The more successful a project is, the longer you have to survive with that codebase. We never have to live with codebases on unsuccessful projects. They disappear into the abyss. So it’s a waste of time to properly design a project that won’t be successful and it’s extremely detrimental to a successful project to poorly design it.

So does that mean a project’s design time should be relative to how successful you intend the project to be?

Joel explains why Human Task Switches Considered Harmful.

I could have sworn I posted this but wasn’t able to find it when searching so here it is for possibly the first time.

I’m not sure Alan Cooper created the concept of personas, however, he certainly contributed heavily. I’m a fan of Alan’s work and I’ve always liked personas.

Jason Fried, CEO of 37signals, comments on personas:

“Personas can’t make mistakes. Personas can’t make value judgements. Personas don’t use products. Personas aren’t real.”

Tough to argue with, however, isn’t working with personas a lot better than nothing at all? Following along, isn’t working with real users a lot better than personas?

According the site, John Reel is a “Renegade Super-Programmer”. I can’t confirm or deny that or any of the other claims on their site. What I do know is that he and his partner demo’d at the recent DemoCampGuelph3.

They demo’d an application they’d written to handle the installation of a php, server based web application that they sell. Nothing too exciting except for one key difference. They claim to have sold over 1500 copies of that software in less than a week. That’s a lot of different environments to install on.

If you’ve ever installed a php, web app then you know you typically ftp a zip to the server. Unzip/tar the files in a location. Play with permissions, add a database, set more permissions, etc, etc. The good apps have useful config pages which clearly explain to you at any stage in the process what’s wrong and what you can do to remedy the situation.

What John did was much cooler. They took it all out of your hands. Of course that requires you provide them with some serious credentials and full access to your server, however, you have the option of doing it all yourself if you prefer.

How could you possibly test and support the infinite number of server configurations out there? You don’t. In their case they tested 50 setups. Then they staffed a team of 7 developers around the clock to monitor client installations. When a client ran into issues, those developers fixed the issue for them. They then used the lessons gained to make the software better.

I like it because it’s a non-technical solution to a technical problem. Software companies can easily lose site of the available non-techie solutions available to them.

If you missed DemoCampGuelph3, sign up for the google group and join us next time.

“Making a plan and sticking to it guarantees a sub-optimal solution”, Andrew Fitzgibbon.

Ahhh so making a plan is bad? Writing code early is bad? I wonder where stalling and doing nothing fits in?

[Above quote originally read in Bill Buxton‘s Sketching book.]

If you’re asking me, where design fits in the software production process and what it actually looks like is one of the biggest issues facing the technology world. It’s a human problem and will not be solved with processes and tech tools. Alan Cooper chimes in….

“Generally the last thing you should do when beginning to design an interactive system is write code”, Bill Buxton.

I can’t really argue with Bill on this one. Unfortunately it flies in the face of agile methods which suggest that you write code as soon as possible. While I’m a fan of what agile methods strive to achieve, generally I see more cons than pros in practice.

Just to confuse myself, I’m about to completely contradict myself. Here’s why you should write code early, and it has nothing to do with the quality of experience of the resulting product, it’s about everything else. What else is there? There’s your team and getting them to work together, getting them up to speed on the problem domain you’re working in. There’s the technical bits like setting up source code control, issue trackers, development and qa servers. There’s the actual act of building and deploying a piece of working software.

All these are non-trivial bits that have very little to do with the quality of the experience the software delivers. You can deliver on all these and still end up with useless products. They are, however, real reasons why you want to deliver working software as early in the process as possible. To be honest, what you deliver in these early stages is almost irrelevant. It’s about getting the team and tools in place and working together. Think of it as training camp in sports.

Now for the contradiction. Writing code as a means of design is an expensive way to design poor software. It’s a great way to build a development team but clearly there’s a required balance here. Software is about the only industry that prototypes almost immediately. Look at architecture and automobiles as an example (Before we take this too far, I’m not suggesting we simply copy those industries). In both those more mature fields, they involve lengthy design phases prior to prototyping. As Bill mentioned in his recent talk, every automobile built today first had a full scale clay model rendered at costs of upwards of $250,000. The key being that they don’t get the clay out on day one. They spend months researching and designing long before they move to the prototype.

This isn’t a power play. This isn’t about removing software developers from the design process. This isn’t about no longer allowing the software construction process to inform and influence design. This is about building software that delivers a better and more relevant experience to the end user. This is about respecting and making effective use of one of your most valuable ‘tools’, your software development team. Yes, I just called myself a tool.

My buddy Mark runs a restaurant here in Guelph named The Cornerstone. I often use him as a real world example of how we should be building applications.

Recently the location two doors down from the cornerstone became available and Mark rented it. Obviously people started asking him what he planned to do in the new space. His answer was that he had no idea. He simply planned to talk to people around the cornerstone and see what they’re looking for.

It isn’t easy but that’s how software should be built. It requires real listening and a true lack of ego to pull of. The reward is that you end up with a business, or software, that people truly need and want.

Where did Mark end up? He’s working on opening a store focusing on handmade local food such as bread, cheese, etc.

Oh lordy I wish I could say I don’t relate to pretty much all of these…

“There’s no way in hell this is going to be under thirty minutes. Why are you lying to me? It’s not possible. You know it’s not possible. You are a liar, sir.”

“You want to rank and hide comments on your “Completely open and honest corporate communications blog,” but only after an admin / editor has approved the comments that have been made? Do you not understand the concepts of “Completely open?” And for that matter, ranking and hiding?”

Cooper has a recent article about a design process. What jumps out at me was how many attributes their approach shares with some of the development processes we’ve been using/creating. We use a heavily modified version of scrum for a lot of our projects. The parts that are shared with Cooper? Two to three week deliverables, daily meetings, and embracing and encouraging collaboration over documentation.