Confused? dot com
Flippin ek. Has anyone ever got me more confused, (and annoyed) than Confused.Com.
This site is supposed to unravel the complexities of getting quotes from multiple insurance companies amongst others. But the clunky user interface, makes it clear that the fine underlying business concept is still struggling to get out.
But maybe Im on the wrong site. Anyone interested in going up against these monkeys, how about www.notconfused.com?
There comes a time when we know things aren't going rignt, the sooner we realise it the better, but only if we have the courage to act.
I am going back into the office tomorrow to admit I was wrong.. again. Having spent the weekend walking the dog and playing with the kids, the fog of war cleared and realisation dawned that I was fighting the wrong battle.
I am always keen to provide abstraction between architectural layers, in this instance I have won the argument about the need to decouple business logic and business domain representations from the Data Access and storage logic and relational schemas.
I usually go for NHibernate as the weapon of choice for providing a Data Abstraction Service, but with ADO vNext in the wings, I have spent some time looking at simpler interim solutions untill the brave new world ships with Visual Studio 2007.
Now, I finally decided that we could get away with a simple Code Generated Data Access Layer, and a hand carved layer of Mappers, to transfer state between the data and business models.
Spent last week putting this together, replete with functional and unit tests hoping to be able to move ahead, its not neat and its not pretty, but it works, kind of.
Anyway, to cut a long story short, it won't be easy to move forwards with what we have now, we do, after all need a propper OR Mapper, and Im going in tomorrow to chuck last weeks work away...oh, except for the tests.
This reminds of my Dad. He is a goldsmith, and works alongside my Mum. When she starts to make mistakes she soldiers on and tries to salvage as much of the work she has done. My Dad, on the other hand, chucks his work in the scrap pot as soon as it starts looking vaguely pear shaped, and starts again. - He always finishes first.
For me. the value of test first may have proved itself again. At least I can show that last week wasn't totally wasted, and I have the courage to chuck my hand wrought mappers in the scrap pot and start over.
Thanks Dad.
Have pattern users adopted one of the least attractive antipatterns, "Intellectual Violence", or are patterns just being communicated badly?
For all their utility, I am finding patterns more and more of a hinderance in my day to day communications with developers, architects, project managers et al.I recently heard that a client was planning to "remove the patterns" from a solution I worked on a couple of years ago, because they didn't understand them anymore.
It seems that the communication value of patterns is being lost, and the recipient of the message hears "Pattern" and thinks "Uh Oh, this'll be a bit challenging, I don't really understand them all".
If patterns are to be used we really need to take time to make sure that everyone around us is on the same wavelength, It's no good sitting back and saying stuff like why don't we put in a "Front Controller", and hope that is enough. Most will say "OK" wether they understand or not.
The other crime I have been guilty of is going around justifying designs with phrases like "Oh, Its all patterns based, industry standard stuff, you can look it up if you like, most are in the GOF book".
Rather than using intellectual violence to show off how much cool stuff we know, surely communication and colaboration would benefit from a more humble approach. We need to take time to educate and encourage less experienced developers, to join our ranks, not put them off forever.
To build systems that are maintainable, and likly to make our customers happy, both now and long into the future we need to make sure they meet more than todays requirements. They need to survive the years of operation, and the inevitable upgrades that business change demands.
One of our key strategies must be to keep our designs as straightforward and understandable as possible, we might be the best developers in town, but what is the point of building elegant masterfull code, if mere mortals can't understand it?
When building enterprise systems, there is always a tendancy to go way over the top, with Architecture and Technology. My advice is to keep it simple, and you will be remembered for delivering great solutions, that are fit for purpose.
But let's not forget that "Simple" doesn't mean "Dumb", to build simple systems we need to get smart, and think through our designs to make sure they cover all the bases, but look straightforward, Like all experts we need to make a complicated job look simple.
When modelling, continually refactor the design, aim to simplify it, work on introducing good abstractions, then remove all the stuff you don't need, keep it clean and lean. When you are done, and you present it for review, it should look obviously "correct". Expect, even work for, comments like..."Flippin ek, its taken you all that time just to produce that, it looks like you did it on the back of a fag packet last ninght!"
To these folks, you will be their hero.
Do The Simplest Thing That Could Possibly Work...
After test first this is my favorite weapon, it doesn't even have the rider, "probably" of Ockhams famous razor. But this baby is a bouble edged warhammer that will get you into trouble as often as it will get you out of it. Wield with care and precision.
eXtreme Programming works because all the practices are mutually supportive, each one shoring up the inadequacies of the others, DTSTTCPW is the most incecure of the lot. For a start, it is totally dependant on precise communication of what 'Work' means. We are always going to
The worst problem is that 'Simple' is subjective, and in an industry that has huge problems deciding how best to do things, and a massive diversity of experience amongst its practitioners, Simple is a pretty hard concept to nail down.
I am in the middle of building a set of Enterprise Services for a Mortgage company. I have a great metaphor, an on site customer, stories and everything else, including a pretty experienced designer and developer - moi.
Can we get away with sloppy thinking
There comes a time when we all have to make a choice between doing it right or getting it done.
But is that really the dialema, does getting it done mean we can stop thinking, does doing the simplest thing actually mean do the first thing that comes into your head?
I want to take a long hard look at the problem, There are always concequences of our actions
So, how 'right' must it be and how long will it be 'right' for.
