One of my constant heartaches when I see design proposals, or worse finished features, is the lack of thought given to the poor end-user. This isn't a new subject indeed there are currently some insightful blogs from Microsoft employees complaining about the interfaces in some of their own products - Windows Media player springs to mind. With this in mind I thought I'd blog some quotes from 'About Face 2.0 - The Essentials of Interaction Design', please read the book but to whet your appetites...
'...marketing departments are sometimes able to provide requirements, but these often have little to do with what users actually need and have more to do with following the competition, providing feature checklists to IT departments, or guessing based on user surveys or customer wish lists. None of these approaches take into account the users' goals in any systematic fashion.'

'...Developers...centring on technology and engineering methodology...Marketing departments focus on what drives press attention, on features lists, on what people say they will buy...The result...software that irritates, reduces productivity and fails to meet the user needs.'

I'll stop there, if you want to read more then buy the book! But please all you developers and software houses out there, please think about the poor end-user. Take a long hard look at what you've developed or are developing and ask yourself honestly, are you making software that thrills or irritates the user?
 

After attending a number of seminars  (esp. the 'Agile Investment in Software: Who cares how you build it?' seminar by Chris Matts) and talking to other developers/architects I've been considering the pro's and con's of, "chasing the money" (Money). The basic idea is that you should provide the business with the best mechanisms for the company to make money. A core issue with any Agile development processes is what feature to implement next. If you take the Money approach then it can help focus the development on the immediate business needs, thus helping the product get to market faster, the business more successful, etc, etc (see Clarke Ching for a good introduction). I can see why this is a good idea (clever me) and it certainly is worth asking the question for every potential feature that could be implemented. However, as with so many ideas neither is it a silver bullet or particularly new. Recently, on different occasions, I've been confronted with developers who have not considered the non-functional requirements during their development process. When I recovered from the shock that this can happen I wondered if there was some common problem with the teams. When discussing it at XPDay the first conclusion was simply poor developers. I think there is something to that, certainly in one example the team of people were asked to do development when that isn't that primary skill, ah the beauty of false economy. The other common factor was a feeling of them-and-us. The team Chris Matts described sounded like just such a case, "The Business people" vs. "The IT lot" whereas the idea is that everyone should be working together (aaaah sweet). Chris' conclusion was that by using the Money approach the IT team were forced to validate everything they did as a business case. Herein lies the problem, if you combine the Money approach with the lack of importance given to non-functional requirements you run the very real risk of passing over such features in the clamour to grab the money. Some of the features are difficult if not plain impossible to put in afterwards. For example, consider building a house. Customers wants walls and a roof, they don't care too much about the floor.  Obviously the conclusion of this example is you end with a lovely house that falls over in the next strong wind because the boring no-thrills foundations are rubbish and you end up with one angry customer and a reputation in tatters. I'm not suggesting this means the Money approach is wrong, but you must ensure that non-functional requirements are properly considered (with the proper business case) when deciding upon priorities and don't use the wrong people! Like I said, I don't think this is anything new, but it seems to be a lost message when there is a temptation of a quick buck.

Just got back from a SQL 2008 MSDN UK seminar at Thames Valley Park (TVP). I was a fairly simple set of presentations to give a quick flavour of what 2008 may mean for developers. So here is an even quicker flavour...
Data Types: Some new data types including lots of date/time types (probably the ones that were in the 2005 CTPs), File Stream (for files that are actually stored on disk) but the most interesting one was the Hierarchy Id. This allows the developer to construct real hierarchy relationships and ask questions such as who is the ancestor of x. However it does need to be manipulated via a whole set of related functions. The seminar also spent far too long on spatial types, ok map data is all the rage but who cares about this? Ever since SQL 2005 I've been worried about the potential explosion of CLR types in the database, and this just seems to meet my worst fears. I think you can smell a CLR type because of the extra functions, I really wonder how well (or not) they'll perform.

Semi-Structured data: Interesting change, where you can add sparse columns to a table. The idea is that you can create many columns (wide table) to cover many attributes without overloading the table. This could be useful for storing derived types in the database. The classic example would be Animal classification. Not every animal has the same attributes but you can put the whole range in the table schema when in reality only a few will be used on any one row. I'm not sure how the Codd brigade will take to this!

Filtered Index: Didn't really cover this but it seems that you can create an index that only includes data that meets a criteria. For example you could create a dog index for the animal table that would only contain data that matches the "dog" value.

Integration Services: The use of parallel execution and the inclusion of ADO.NET sources.

Tracking Changes: Oh yes this stuff could be great, but will it perform well? Two types; Change Tracking - aimed at synchronisation activities, conflict resolution, etc. Change Data Capture - aimed at replaying changes to a different database.

Merge: This looked very powerful, the ability to use one statement to merge data from one table to another. This seems to avoid the age old SQL problem of knowing if you need to insert a new row or update and existing one, with Merge you can do it all with one statement. Looks suspiciously like an XQuery to me, again the spectre of performance rises.