Podcast #2 : QCon revisited

Tue, 25 Mar 2008 10:23:20 GMT

As promised the 2nd CTA podcast is a roundtable discussion between some of the CTA contributors - namely Simon Brown, Sam Dalton and Kevin Seal. In this podcast we discuss some of the themes emerging from the recent QCon conference held in London and our views on those themes.

The podcast can be downloaded here or you can subscribe. Full show notes follow below:

1. Introduction

QCon Conference London detail can be found here.

2. Monitoring and Management (0:27)

Roll your own vs. "off the shelf" monitoring
Asynchronous monitoring
JXInsight
The need for an System Architect and an overall understanding of WHAT to monitor and a holistic view
Including Monitoring NFRs upfront in SAD
Monitoring the monitoring vs. best effort
eBay and 1.5TB of monitoring and logfile information per day

3. Rehashing Refactoring (11:56)

Refactoring now mainstream, now emphasizing at the micro-level
Code-debt - how can you measure it?
Refactoring is not something to be "saved up"
Lots of rearchitecture projects sold as refactoring
Sometimes starting again is a better solution than large scale refactoring
Why do things end up in such a mess so often?
Need to get back to writing code for humans to understand
Worry about emphasis on low-level code optimizations rather than architecture
Is refactoring its own worst enemy being referred to as a separate discipline to regular software development?
We are our own worst enemies - we (especially the architects) need to stand up for the quality of our code - stop allowing ourselves to be convinced to make shortcuts

4. The Return of the Architect? (25:08)

Thinking about performance, monitoring etc upfront
Terracotta, Coherence, Gigaspaces
Kevin's views on Terracotta
How much performance could you squeeze from a system in 2 weeks with code changes alone?
Real-time VMs and performance improvements
The benefits of continuous performance testing
Premature optimization
Understanding a system's deficiencies can be as valuable as fixing them

Give the user what they want...

Fri, 17 Mar 2006 16:02:28 GMT

I used to subscribe to the school of thought that you should write, or at least design, your system solidly and then build your user interface(s) on top of this sound foundation. After all, it's got to work before you can use it, right?

I'm not so sure anymore, though this is mitigated somewhat by an iterative process. I've more recently shifted towards the notion that each function must be usable before it can be used. After all, its main purpose in life is to be used, not to be strategic/beautiful/standard/optimal, right?

People, particularly developers, tend to dismiss the user interface as being the "front-end" to the application, simply adapting between business function and user. This is only really true once it is complete; during development the UI is defining and refining the business functions - it is part of the development process. When implementing user interface first it is often the architectural assumptions that get changed since they don't fully support the desired functionality. This is a good thing - it is refining the architecture and making it fit for purpose, the purpose being to serve the user.

Of course you're stuck trying to balance functional and non-functional requirements - just remember that the users carry a lot more weight than you might first think! If the end users don't want to use your application you'll struggle to get it adopted whereas if the end users do want to use it they'll give the project real inertia, biting your arm off for new features.

Also, whilst it may seem a bit Machiavellian, it's quite easy (and sometimes fun) to ride an unrelated architectural improvement in on the back of some new user functionality. The development effort's got impetus so why not make the most of it and champion your own requirements?

The overall quality of your system should improve with the addition of functionality.