Andrew Stewart investigates the causes for so many bad models, especially in the financial sector, created by various teams including Agile ones.
Andrew Stewart currently leads the business analysis team at LMAX, and has spent 20 years working on software development in organizations ranging from 3-strong start-ups to global consultancy firms. The bulk of his experience is in the data, modeling and MI space, specializing in high volume, high performance and inevitably high technology risk projects.
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
no value presentation
BTW if your test cases cannot identify between an elephant and a square, your application wouldn't either.
Thanks to Olaf Lewitz we no longer call what we use a model. Instead we call it an Olaf.
The model as described here is a simplication of reality. An Olaf is a summary of the examples used to create it.
More research please.
Re: no value presentation
I take the sentiment from both your and Chris' posts. The value in this presentation is to save you a lot of blood, sweat and tears believing there is an "easy way". I don't stand alone when I agree there isn't "an easy way" with models; during a Q&A with Brady Booch in Sydney just under 20 years ago, he said something like, "you can't remove complexity".
You can make more complexity, one of the few exceptions to the first law of thermodynamics(*lol*). Dr Booch did move on to suggest that you can encapsulate or hide complexity in seemingly less-complex (simple) constructs. At the time, and for around 10 years or practice with a model based tool I say practice proved the assertion of the presentation, and not too may things happened to encourage me to invest in 'Silver Bullet' futures.
One last thing, I'm familiar with the 'denial', 'frustration', etc cycle in design/modelling. To me there are some fundamental errors from a practitioner point of view: 'bargaining' -- gives you camels (a horse designed by a committee). 'Denial' -- the house that jack built. 'Theory' is good when it fits the solution domain (otherwise it is a little like opium. Sweet taste and eventually soul destroying).
Effective solutions? STOP. Make a 2nd model, a 3rd model until you know enough to make the First Release.