Friday, 19 November 2010

Cargo Cult Control -> The Microsoft Marketing Machine

As I have been blessed with a microsoft tagged comment to my previous post ( I feel I should respond to Pete Browns carefully worded critique. I welcome opinions other than mine and would like to encourage anyone who feels moved enough to leave a comment on these pages to do so. (Just make sure you read the bi-line of my blog first so you know what to expect)

Pete Brown - Microsoft Community PM WPF/Silverlight wrote...
"The title of this is a bit misleading. As a reader, I thought this would be about MVVM with perhaps some good alternatives presented, but really your issue is XAML and WPF itself."

This seems to be a common theme throughout the industry. It is expected that if you write about development topics you must present it akin to a research paper. You need examples, facts, figures and a clearly presented alternatives. 

It irks me that this is the case and is simply another example of cargo cult behaviour. Readers eager to jump to a new 'improved' tech religion at the press of a key. All along hoping they can achieve a higher level of enlightenment and wow their peers and perhaps one day reach to the skies themselves.

The alternatives I present are not in the words I write, but instead in the freedom they aspire too. The industry needs to open its mind to the possibility that maybe they are all caught up in an endless spiral of hype and company positioning. 

Ask yourself this question:

"What is the point of software development?"      
(before you answer - Try and word it as if you are talking to an isolated tribe in the south pacific) 

Pete continues...
"FTR, I really do like the XAML model. That's why I joined Microsoft.
In WPF and Silverlight development, you should use *some* architectural pattern. I don't personally care what it is, but IMHO it should leverage binding. Many of the features in the platforms are easier to use with binding."

Pete obviously likes his XAML, and points out I seem more unhappy with WPF and XAML than MVVM. The simple reason for this is MVVM is the bastard son of XAML, without XAML it wouldn't even exist. So I am just going to the source of the problem.

As for the statement "you should use *some* architectural pattern". 
There is an alternative anti pattern I use in all my apps:

 "The Common Sense Anti Pattern" or TCSAP as it is commonly known.

Pete tells it like it is...
"MVVM happens to be a leading pattern. However, many people throw a lot of extra complexity into the definition of MVVM, burdening it with things that really are optional and confusing the community in the process.
Pete Brown
Microsoft Community PM WPF/Silverlight"

So why is MVVM a leading pattern if it confuses the community? Its not because it just happened to be in the bar one day when the talent scouts popped in for a beer and decided to give MVVM it's big break. 

Its all down to the WPF marketing machine needing a hook to feed the fanboy culture. This hook then drives the cargo cult in the direction Microsoft  requires. A purely invented reason to get these fan boys excited and start talking about WPF again. 

Any negative press that is hurting the brand (such as this blog) must be "managed" or the sky will fall in.
In the end Its a business, so winning is simply about getting more people to use this set of tools over another set, the goal of delivering better software is a minor concern. 
Market share is king.

Despite all this, they all know good developers will always deliver good software no matter what tools, patterns or methodologies try to get in the way. This is because good developers use anti patterns like TCSAP extensively.

Finally for those who are waiting for the answer to my question above:

"It's to make money, plain and simple."


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.


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
- 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...