Dotmad.net

I went to a lecture by David Platt on the subject of “Why software sucks”, which discusses what is wrong with software today (hint: it’s mostly designed by programmers) and how we can improve it.
From listening to a previous ARcast with him I already knew he is a very entertaining speaker, and he proved me right (in fact, I kept thinking I could bring my wife to one of his lectures and she would have enjoyed it as well).

David began his presentation with a screenshot from the Better Business Bureau in the US, listing complaints by industry, and the amazing thing about it - people dislike software more than they dislike used-cars salesmen!

The main idea of the presentation (backup up with all sorts of amusing anecdotes):

• People don’t buy software for the sake of the software itself - they buy software to get something done. They are not interested in using the software, they want to have used it.
• Programmers tend to design software for people like them, while most users are very different.

Platt’s solution resolved around 5 key points:

1. Add a virgin to the team - add someone to the team with zero knowledge about the inner workings of your software.
2. Break convention if needed - don’t behave in a certain way just because all every application behaves the same way.
3. Do not let edge cases complicate the main stream - extra features aimed at edge cases complicate your software and make it counter productive.
4. Instrument (Carefully) - Try to gather information about the way users use your software without harassing them.
5. Question each decision - ask if each decision is taking your project closer to the result or further away from it.

The lecture itself was followed with a Q&A session, in which I asked him a question (which landed me a signed copy of his book - thank again, David!):
If programmers are so bad at designing UI, why not bring in a specialist to do it?
His response (after correcting me for saying “Graphics designer” instead of “User interface designer”) was it’s actually a good idea, since most of the industry is already headed for specialization in various subjects.

I found another podcast on ITConversions network, and here are two short videos from the presentation:

Let’s suppose you have been saving to buy a new apartment, and you approach building firm as the building is still being build. The sales person says: “The building should be finished in two years. However, we just started working with Agile methodology, so we can’t promise you windows, doors or a sink“
Would you pay your life’s saving to this person?

But that’s what Tom Hollander suggests: “Nobody should promise exactly what will be delivered at the end of the project“
I have recently listened to a screen cast dealing with Ruby On Rails, and it began with similar explanation of what is Agile development, leading to the same conclusion.
I’m a big fan of the Scrum method, which is Agile, but only when it comes to the way the team is working together.

Most developers I’ve met know the exact specifications of a computer before they buy it. They know the various systems in the car they intend to lease or buy. They know the exact contrast of the LCD TV they just purchased.
But when it comes to software, they claim “specs is speculation”.

Wrong.
Specs is specifications, and that what’s brings in the money.
A customer is expected to pay huge sums of money - of course that customer requires some sort of a promise, in the form of specs.
Saying “I can’t promise exactly what you’ll get for your money” can only work with open source projects, not in the commercial world.

You may use Agile to modify milestones along the way, but you need to commit to an end result.
Just imagine your customer saying: “well, I can’t promise exactly how much money will be delivered at the end of the project”…..

Worried about SQL injections, user spoofing and other hacking methods?
Worry no more - here you can find various security checklists from the P&P team.

Eric Sink wrote a long post about writing requirements/specifications for a software project.
He lists lacking specs as a cause for project failures, since the people that came up with the ideas are not the people implementing them.

And he lists some useful pointers:

1. A spec needs to be in a form which is accessible to more than one person. It needs to be written down, either in a computer or on paper.
2. The spec should be logically broken up into a bunch of little pieces (bullets). Each piece should be a self-contained statement about one single detail of how the software should behave.
3. A good requirements spec contains priority information to help the dev team make the right trade offs. If some requirements are more important than others, the spec should say so.
4. A good requirements spec will contain “anti-requirements”, explicitly spelling out things that should not be done.
5. If we choose a development process which rigidly requires a perfect spec before construction can begin, we are just setting ourselves up for pain. We need to be a bit more agile (flexible).
6. Every piece of code in the project should exist because it helps meet one or more requirements.
7. Every requirement needs to be tested.

Regarding item 7, I recently read about an interesting emerging framework, used to write demos the same way you write tests. It’s called “NDemo“.

As an interesting side-note, Eric also mentions a new ALM tool which is about to be released from SourceGear, called “Fortress“. It should be interesting to compare this tool to Team System.

Phil Haack wrote a good post on form design (mainly label placements). Although it focuses on web forms, the same principles apply also to winforms.
You can also read some useful tips here.