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.