Gojko Adzic

The adoption of reflection into main-stream programming tools and languages over the last six or seven years gave developers almost telepathic powers, allowing us to instantly understand any object without having to read through 200 pages of boring manuals. Code insight, instellisense, class browser, or whatever the feature is called in your favourite IDE, started as a helpful utility but has now almost completely replaced API documentation. Most developers simply do not read supporting documents at all any more. Continue Reading »

A friend of mine has a problem – his team worked for months on a big system with great success, marvellous technical achievements and a very elegant architecture. However, the users don’t share his enthusiasm. They don’t appreciate the architecture, flexibility and openness to change. Somehow, they seem ‘blinded by the user interface‘. Although the statement is completely correct, it’s hardly something that developers should be moaning about – on the end, ‘user interface‘ is called like that because it is exactly what users see. Instead of complaining how users only see ‘the stupid UI‘, we can embrace that fact and improve their feelings about our software.

Developers tend to over-emphasise functional aspects, underlying structure and technical achievements. But users are blind to that – they only see what the software does, not how. Most users are only concerned about how the software will help them get their regular job done, and how pleasant it will be to work with. For them, the underlying structure, service layers and database optimisations exist somewhere over the rainbow… Continue Reading »

From the naïve view of an average enterprise software developer, the situation today is a bit insane. Most customers will always choose more functionality and faster delivery over testing and documentation – not to mention GUI polishing. They will look you in the eye, tell you that they sincerely understand the software will have problems once it is live, and then come back furious when the software does not work. As if we were not all speaking the same language, somewhere the meaning of ‘it will have problems‘ gets lost in translation. Or maybe it’s not the definition of ‘problems‘, but the definition of ‘done‘¹, or maybe developers and customers really come from different planets. Continue Reading »