Tuesday 26 October 2010

Cargo Cult MVVM => The death knell of WPF

The MVVM Cargo Cult is certainly a strong and powerful one.  It seems to be worshipped by every two bit WPF/Silverlight developer on the planet. Developer job sites list this as one of the multitude of pointless acronyms you must know, and if you are a non believer then you are a philistine who is not worthy of their time.

Millions of bloggers give thanks to their software gods by offering tips on how to use this magical beast, hoping that these same gods will look kindly upon them and deliver the software they crave. The less clever among them heap scorn on the gods and wait for a mystical MVVM tome that will explain their every confusion and answer all questions on this mystical pattern.

So lets get back to reality...
Over the last 17 years I have developed a truckload of GUI applications using a wide range of languages from assembler and C++ through to Winforms and WPF. I have also created several complicated multi threaded silverlight and WPF Apps using MVVM, I was pragmatic and used it only when it made sense and when it is worthy of my time. I too was tempted by its claims, but not any more.

It is my considered opinion that if MVVM could be erased from space and time we would all be producing better applications and in general be a lot happier.

The MVVM pattern was designed to try and accommodate the flawed XAML concept which was naively put forward by Microsoft all those years ago. They had big plans to replace HTML with this stuff, big plans which are now a distant memory.

WPF is dead!
Its been hanging on for grim death for years but MVVM has ripped open its chest and let the world see the true horror that is hidden within. It has laid bare the evil black magic that must be carved into XAML to make MVVM work. This pattern is the final dagger in WPF's barely beating heart.

MVVM asks you to create untyped XML files that contain free text view model names, property links, black magic bindings, mystical triggers, obscure commands, baffling templates and untraceable style overrides.
Then in the 'real' code you create notification properties with untyped string names, cross your fingers observable collections, even more magical routed events and commands and then pray to the gods you can make it all link together.

As I write this blasphemy I can hear the impassioned cries of  'Testability!' and 'Separation of concerns!'. Wondrous tails of a soon to be future where designers and developers live in a perfect world of magical collaboration and mutual respect. Its within our grasp they cry!

Sorry guys, you have all been led down the garden path on this one.
MVVM and WPF basically produces unmaintainable code as soon as the application gets even slightly complex. XAML is the problem, all these binding features MVVM forces you to use are at best an Alpha in WPF, and because WPF is such a sprawling mess of legacy 'features' it wont be fixed ever.

Trying to fix bugs in someone else's MVVM screen is nigh on impossible because its so hard to decipher the flow of control. When you make changes most of the time you only get runtime errors instead of compile time. Debugging these runtime errors is painful as they are generally hidden in the black magic of bindings or triggers or some other crazy abstraction in XAML.

MVVM testability claims are dubious at best. If you breakdown your frontend code correctly you can test it pretty well anyway, you dont need MVVM for that.

Also the mantra that  XAML lets designers design and developers code is flawed. It sounds great but in practice any slightly complicated screen basically needs a developer to make such complicated XAML that its sticky taped together just to work, and as soon as a designer tries to load it into blend or edit manually. Kaboom!  

Finally, MVVM produces terrible performance. It is nearly impossible to see where the bottle necks are as all rendering is done via black magic bindings and triggers. Trying to get any WPF application running smoothly is a struggle but using MVVM  makes it even worse. As have I often said during WPF development, 'My old C64 scrolled smoother than this and it only had 38k of available memory'

If you insist on still using this pattern remember this.
MVVM is a sharp tool, be very careful or you will cut yourself.


GCS Wiz




Monday 18 October 2010

JobTitle<T> - Software development is not a real profession

Lets jump straight to it. Software development is a not a real profession. I should know, I have worked in it for nearly 17 years. I have seen technology continually change over those years but no where near as much as my job title. Lets see how this professional identity crisis unfolded:

I'm a new dude..
- Graduate programmer
- Junior programmer

programmer is so 1980 lets get a new word..

- Developer
- Senior Developer

hangon where now for developers??? We build stuff sort of...

- Software engineer
- Senior Software Engineer

hmm software engineer sounds a bit like an engineer...thats not what i do. but i'm better than the other guys

- team leader
- team manager
- senior consultant?

but im still developing, i come up with designs, I'm not a pen pusher??

- Architect
- senior Architect
- CTO
- IT manager

Hmm I may need to wear a suit...

- Just call me God

Lets clear the air, there is a small percentage of people in the software industry that are great at what they do. I would say I am one of them, and all I do really is play a game of fancy pattern matching, the more challenging the better, and on top of this I also get paid loads of money for the privilege.

I have completed many projects working with small to medium teams using too many technologies to name. From a junior greenhorn right through to the dude calling all the shots. I have been part of startups that have been bought, I have worked on big failures and big successes and now I am a highly paid contractor working in the city. All the while being part of this world we call the 'software industry'.

After 17 years I can sum up the feeling of the whole industry in two words:  'Identity Crisis'

The above made up hierarchy of names is a simple attempt by 'real' business people to understand developers and to try and make the development process work like a factory. A fair enough goal.

Unfortunately I've got some news for them, it ain't going to work and the sooner we all realise this the better.

I've also got some news for the developer guys as well, just because you stick 'Architect' at the bottom of your email doesn't make you a great developer. In fact in my experience most Architects just use that title so they can over engineer everything and feel clever.  More often than not they are missing the point on why we are all doing this stuff in the first place. Its all about making money and paying wages.

Take this example for the factory idea:
Imagine a universe where the 1980's C64 computer was where hardware development stopped. We all are still using C64 hardware in 2010.

Some weird virus infected all the computer engineers and they left the industry and became accountants.
No new hardware has been made, nothing, they just keep making C64 by the millions in pre existing factories

Software development techniques would move forward and I'm certain that by now (25 years later) we would have a factory type methodology for writing software on this hardware.

Clever people would no longer be needed for anything other than coming up with the idea in the first place. You just get a whole bunch of grunts to write the code following a tried and tested series of steps. Grunt factory workers in an assembly line pressing out code templates simply by pressing a big red button. Any project can be designed, estimated and built as long as it passes the 'laws of C64' and these laws are well known, just like the laws of physics when building a bridge. What is and is not possible is what you teach at college. All of a sudden its easy to make money using cheap labour. Business is happy.

Unfortunately in the universe i work in the 'laws of C64' where quickly discarded and a new set of laws invoked. Hmm they thought,  we need a new factory for this, and some new work methodologies quick, shit we better get the clever people back in too sort it out.

Wind forward 25 years and this new 'laws of the universe' cycle continues to happen every 6 months, new tools, new frameworks, new hardware, new bright ideas, new techniques. This has the effect of the factory being burnt to the ground every time and barely a new brick relaid before it is demolished again.

The only constant in all this is the top people can always make it work because they don't need a factory.

Until the computers can write the software themselves forget the factory idea. Just let it go.
Forget the bullshit job titles that we give ourselves and have a good hard look in the mirror.
Clever people make it all happen and the rest just get in the way. I don't class people like Scott Gu and co as the clever people, they are just marketing men. They all need to have a look in the mirror and ask 'What is the point of software development?'

When I look in the mirror I think to myself, "My degree says I'm a computer scientist".
I think i will go back to using that...


GCS Wiz