I've been reading Thinking, Fast and Slow by Daniel Kahneman, and one lovely little idea I couldn't let slip by was the idea of the premortem. It's simple. (And attributed to Gary Klein.)

When the organisation has almost come to an important decision but has not formally committed itself, Klein proposes gathering for a brief session a group of individuals who are knowledgeable about the decision.

The premise of the session is a short speech; "imagine that we are a year into the future. We implemented the plan as it now exists. The outcome was a disaster. Please take 5 to 10 minutes to write a brief history of that disaster."

It's wonderful because it forces a group to completely switch gears, right at the time when typically the most enthusiasm for the plan is being circulated and provides a reasonable way to uncover things that may not have come to light.

I'm in the last throws of a web app build that has been in progress since a first code commit on September 17th 2011. I've been building it entirely in my spare time while maintaining my usual job. There's lots to cover on my experience in building the app (starting with what it is) but this post is about closing.

What do you mean by closing?

I mean the process by which I arrive at the application being feature complete. I'm in the rather relaxing state of being able to pick any kind of launch date I want. There's no commercial pressure, no time pressure - no one is calling up and screaming. But there in lies a problem - I've found as the major features were finished (e.g. tested to death and appearing to be working), all the small stuff (not minor, but small features that will make the app good to use, e.g. design tweaks, conveniences, help documentation) has become harder to complete. I recall the specific personality type of finisher, a person who is happy to close out all the details - that sounds useful right now. Since it's a one man band situation I'd prefer to think about what is needed in terms of a pivot in thinking.

From idea creation to feature solidity

Badly put for sure, but solidity is how I feel most comfortable explaining the shift needed in thinking. Major features require huge effort to bed in and test, and as that has completed, focus has had to turn from the very creative and interesting task of dealing with big tough challenges to dealing with lots of easy challenges and maintaining focus. No one will care if the backend creates unicorns if they aren't using a frontend that screams of quality. That transition has been hard. Weirdly, I found it strangely easier when I discovered major bugs in the big bits - they screamed 'MUST FIX!' wheras the current work is very much in the 'that would be nice' box. So to move on, I did the only thing I could think of when operating in a scope, time and cost vacuum - got rid of the vacuum.

Set a date

I set a date to launch into final closed beta. This product is beyond MVP as it's had two closed tests with customers and huge rounds of customer feedback from both. So while features required to launch and nothing more is still key, I've still found myself slipping into a mode where I pile in every nice to have due to the pivot to small features. But I can't continue doing that or I'll never launch. So I've created a specific list in pivotal where the last few perceived must haves are in, and then I'm being really aggressive on kicking them out. I poked around with a nice to have UX feature yesterday, and had it done in an hour so it's in. Today I poked around with another one and after an hour it was clear it was a bigger job than first thought, and so I applied the questions: a) Will users quit without this or b) come back because of it? Unless the answer to both a) and b) is a strong 'yes' then the feature is axed. It could obviously be a useful feature, but it's not critical to launch.

By forcing the deadline it feels like I've made every feature fight harder to get in and also helped to put some light at the end of the tunnel. For sure, I'll keep cramming in the small details that hopefully will delight users (thats the whole point of not just saying screw it and launching right now) but it's also the much much bigger point to launch properly. The date forces the finisher to the forefront and puts the breaks on that voice who says 'wouldn't it be cool if?' - sure it probably would, but there's nothing cooler than launching, and that's all that matters.

I went to the NY Tech Meetup last night. One of the projects demoed was The Imaginary Marching Band. Built with Arduino chips and a few sensors stuck onto some white gloves, the tech allows the performers to play via gestures and breath sensors. Don't take my word for it, check out this video I took of them performing:

Also entertaining was Ad Runner, click here to play it. It's an ad-api driven webgl game where you have to dodge ads. Hit an ad? You get taken to the ads click thru. Funniest question asked the guys if they would get paid for the click-thru - it's only a beta ad api they are using, but if it were real they say they would. Nice.

Patrick McKenzie has just written an incredible post for those in software engineering / wanting to be in it. 

Don’t Call Yourself A Programmer, And Other Career Advice

Seriously, get off this site right now and go read it. It's vitally important that you do.

Chime.in is live and the internets is talking.

Fantastic speech from Cory Doctorow.

To help out I'm providing a bunch of supporting links here that current students and graduates will hopefully find helpful. I may add more as they come up.

Co-founder of reddit on how to get a job:
How to Get a Job Like Mine - Aaron Swartz

Fog Creek are famous for their stringent hiring and interviews process:
How to Get a Job at Fog Creek (and Other Selective Software Companies), Part 1: Résumés and Cover Letters - Tyler G. Hicks-Wright

Good general advice:
How to get my first programming job - Stackoverflow

CV advice:
How to make your IT Resume/CV stand out? - Stackoverflow

Breaking into the industry:
Proggit, I need your help. I'm passionate about writing code and have already written some stuff that I think is kinda cool, but I have absolutely no idea how to get a programming job. Any insights are very much appreciated. - Reddit.com

A Google developer giving good practical tips on breaking into an open source project and making contributions:
Wherin I help you get a good job - Aaron Boodman

This is how I go about designing web application interfaces. It's not really an all-encompassing guide, it's more just how I've done it in the past, with some hopefully  helpful pointers for those who haven't done it or aren't familiar with some of the aspects of the process. If it's your day job, you may be bored.

Where do you start?
Easy, the same place most people do: back of a napkin/beermat/whiteboard/notebook wireframe. Start scribbling. It may sound stupid but if I'm by myself in this process I'll often do it in my own head, just throwing relevant elements around in space and trying to figure out something that makes sense. The wireframes obviously come into their own when used to get the point across to others quickly. Balsamic mockups is a good enough tool for doing this if you are new to it / need to be consistent to show other people. There's a little bit more to this step than just drawing out an interface - it's at this point that you've got to have an understanding of two other fundamental building blocks already in your head to differentiate you from pointless pixel pushing design that doesn't account for usability: the use cases and the data model.

Use cases
What are the use cases for what you are building? Let's wikipedia use cases and get some detail. The page says use cases should:

• Describe what the system shall do for the actor to achieve a particular goal.
• Include no implementation-specific language.
• Be at the appropriate level of detail.
• Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.

An actor is anyone who will interact with your web site. So in the case of Amazon people wishing to purchase items would be an obvious actor, but there are probably many others, such as administrators, suppliers etc. A brief use case description might look like: "A customer needs to be able to login and browse or search books and then purchase one or more of them." That should be further broken down into possible actions: login, browse, search, purchase etc. In this way we can figure out commonalities with other actors. For example administrators and suppliers will need to login too, so that suggests a base user class and then each of the different actors can inherit from that. But I digress - going to far into this isn't necessary on small projects or on straight forward tasks - but being aware of the process is as it informs what the wireframes will need to contain in order to be useful.

So given the actions we can see the implications of it for the wireframes are:

 - Sign up (If they can login the must sign up)
 - Login
 - Browse
 - Search
 - Purchase

...So just from that we can start seeing the bare-bones of what a wireframe could look like in our heads and gets us thinking. How much of that should happen on one page? What sort of interactions make sense? And off we go! There's a lot more to good use cases than this simplistic example, so do have a read of the wikipedia page and it's also well worth checking out use case diagrams if you haven't seen them before. How much detail and time is needed on use cases? It depends. Massive projects where there are many actors will probably require quite a bit of work to iron out use cases, but on smaller projects working by yourself then I think being aware of the use case process can be enough. The important thing to remember is that they are just a starting point - so they don't have to be perfect.

Data model
What's a data model? Jimmy Wales says:

A data model in software engineering is an abstract model, that documents and organizes the business data for communication between team members and is used as a plan for developing applications, specifically how data is stored and accessed.

Should the data model exist at this point? It most likely won't. If you or someone else has been scribbling one out then great, but it will probably be very rough at such an early stage. So if it barely exists, why am I mentioning it as relevant to creating the user interface wireframing in the first place? Because you should know. A designer working without any understanding of the underlying data model that exists or will exists is really annoying. They tend to come up with absolute crap because they have no common sense in terms of how the user interface will relate down to underlying business logic and storage. They can throw any types of fields all over the screen or infer extremely complex associations with the twirl of the pen tool. Useless.

The JavaScript/HTML mockup
So we have our very rough wireframes and a basic understanding of the app. Next? Start coding. Very much in the 37 signals vibe, (relevant part of Getting Real is here) if it's going to end up as code then there's no point in sticking an intermediary photoshop mockup step in or anything else. In fact I believe designers who design web applications in photoshop are at a disadvantage from the start, because photoshop allows you to hide from the hard parts and the translation afterwards is a pain. Even worse, a photoshop-only designer without extremely strong HTML/CSS/web app knowledge just won't understand the implications of a dynamic interface on their beautiful pixels. Classic examples include when the designer presents a wonderful looking interface shot from photoshop, and the developer in the room has to ask "what does it look like with no data? Or 10,000 bits of data?" Also, we want to minimise any work that doesn't actually end up as executable code.  To this end I implement a HTML/JavaScript mockup based on the previous rough wireframes. Really, this is where I believe the real work begins. It's only knee deep in the user interface that you encounter the real implications of the use cases described and their impact on the data model. No amount of planning can match actually throwing forms onto a screen and working with actual javascript to simulate AJAX interactions. jQuery is my weapon of choice for rapidly deploying rich prototypes. I tend to go the whole hog and implement proper grid layout systems (eg. 960 grid, blueprint), css resets etc. so that the mockup is as close to proper implementation as possible. If it's your first time then this kind of work can add a bit of time, but it's worth it and once you've done it a couple of times it'll be very efficient.

This design phase tends to be extremely iterative, in terms of starting with the wireframes and laying it out but then moving beyond that once a first version is built. One piece of advise often levelled at writers struggling with writers block is to just write something and the same thing holds true for this type of work. Using the wireframe as a starting point gets things going, and takes care of writing HTML/JS to represent something. But once things are actually live in a real browser window I find that extremely quickly I fall into full flow and at the end of it have a really great set of ideas on the screen and tonnes more to work with. No doubt there are others who like to wireframe everything and then follow these religiously, but I think that misses out on a lot of the power of the full coded mockup - it's at that point I have my best ideas. The first version is usually pretty boring, but seeing it on the screen lets me start to be creative with how things should be solved from a usability and user journey perspective. I know that in some working environments that wireframes (or Photoshop mockups) have to be approved and then followed to the letter, and so my approach doesn't work, but I feel that it is just fundamentally wrong to have such rigid guidelines from the start. It's the HTML/JS mockup that should be the agreed layout, the other steps before were just building blocks and exploration towards it.

Once the HTML/JS is good enough, start templating it and moving it into an implementation.

Problems
This approach is built for speed. I believe the timeframe between concept and the html/js mockup should be as small as possible. This is a 'suits me' approach which just can't be applied in certain types of environment. Particularly when approaching an external client's needs, far more time could be necessary in the use case / data model and requirements gathering phase - the deployment of meaningful wireframes and the follow-up mockup depends on deep understanding by the creator of both. Good news though: There's nothing like trying to draw wireframes without really understanding the purpose of an app to highlight what you don't know. If you do manage to get that done, massive holes will appear when you move onto the full html/js mockup.

An interesting blog post about the inner-workings at Facebook regarding code (Not verified as definately true but interesting all the same). As I've written about testing before these two bullet points really stuck out for me:

• no QA at all, zero.  engineers responsible for testing, bug fixes, and post-launch maintenance of their own work.  there are some unit-testing and integration-testing frameworks available, but only sporadically used.
• re: surprise at lack of QA or automated unit tests — “most engineers are capable of writing bug-free code.  it’s just that they don’t have an incentive to do so at most companies.  when there’s a QA department, it’s easy to just throw it over to them to find the errors.”

Read the full article: How Facebook Ships Code

A good article over at The Register about the lack of quality computer science graduates. It's so true; in the comp-sci courses I've done only a small fraction, maybe 10% of the graduates were actually capable of becoming full blown programmers after their courses.

The Register: No wonder CompSci grads are unemployed