Architectural Homeopathy

Sometimes when you are in a meeting someone says something brilliant, I had that experience today when someone said 'We have a sick body, can we please stop pretending everyone is a surgeon'.  Her point was simple, historically in the company they have had challenges of people having opinions and critically of decisions being made without data and whose implementation success isn't tracked.

I talked about 'Thinking is dead' previously and this is a clear manifestation of that and in the world of IT I'd like to give it a name... Architectural Homeopathy in other words people making IT decisions which

1. Are based purely on an individual opinion on what will succeed
2. Are not backed by a case as to why it will succeed
3. Whose implementation success is not measured (beyond 'it went live')

This approach also has another aspect which is related to comments and challenges to recommended practices.  A good architectural challenge is to say that 'X won't work because we don't work in a centralised way, we need to do Y because we are federated and Y has already been proven to work here', the Architectural Homeopathy challenge is 'X won't work, we should do Y'  or more likely just 'X won't work'.  No evidence will be proposed to support this 'feedback' and no constructive change can be based around it, but if any issues occur the Architectural Homeopaths will say 'You should have done as I said'.

Architectural Homeopaths often build whole careers out of this, building approaches based on 'it worked for me' and failing to see the broader elements that drove success or criticising a proven approach based on a perceived technical flaw while missing the real problem (I'd argue that REST for enterprise integration is a great example of that).  These are the folks who propose great views of architecture without actually having delivered it themselves into operation and coached others how to use that approach.

The point here is that Architectural decisions need to be defensible based on data, even if it turns out to be wrong that gives you the ability to learn.  Proven approaches with justifiable approaches that are measurable against a set of criteria are what professionals should strive to do.  'Advisors' who promote approaches and cannot demonstrate their success and more importantly how others have adopted their approach and delivered success should be treated the way a Homeopath is treated by the medical profession.

I have no objection to the phrase that coding is an art not a science, that it is a creative endeavour not simply mechanistic.  That is fine, but unlike art its success is quantifiable, it either works as intended or it does not.  What I object to is people promoting architectural approaches (or indeed business approaches) which are based on a series of powerpoints and opinions with all of the real support evidence of Homeopathy.  These Homeopaths throw in comments based on this ignorance and personal 'belief' and disrupt progress and love to claim that 'it would have been better my way' while not explaining in detail what their way really would have entailed.

Architectural Homeopathy... get into the sack...

The internet was better before...

Over the past few years I've heard lots of complaints about 'the internet was better before everyone used Facebook' and it got me thinking.  That much like the strata in rocks you can determine your geological internet age based on the first thing you remember complaining about.  So moving backwards

Smartazoic - the modern era (2011 to present)
If you haven't yet complained about the new entry into the internet of any groups at all then the odds are that you are part of the latest major influx characterised by a dominance of mobile usage.

Socialem - the social era (2009-2010)
Socialem's are characterised by their complaints that things were much better before everyone started using mobile phones to use Facebook or other social media sites.  These people complain bitterly about instagram.

Broadem - the broadband era (2003-2008)
This is the era of major adoption of broadband and the rise of YouTube these people tend to complain about the rise of Facebook and other social media sites and don't understand why people can't just be happy with Yahoo and BBC News.  They complain that all these new 'social' users are just adding rubbish to the internet rather than the managed content of their day.

AOLem - the dialup era (1998-2002)
This is the era of the mainstream pioneers, the people who used AOL and other elements to get online.  People who remember what lag really is and complained bitterly about the new stupid sites with their insane bandwidth requirements and 'why oh why would anyone want to watch video'.  Their complaint was that the broadem era took away the 'personal' nature of a dial-up modem and also meant that they couldn't use their home connection when they went to their parents or friends house.  The explosion of broadband also meant there were 'too many people' around.

Establishism - the foundations of the WWW (1994-1997)
These are the folks who had access before the dialup era and who complained bitterly as AOLers started coming into Usenet and ruining the internet.  These folks used the WWW in fact many built the WWW but a distain was had for those who hadn't coped with Mosaic.

Jurrassic - Before WWW (1980-1993)
These are the folks who had network connections and lived in FTP, MUDS, telnet and Usenet and bemoaned the sudden lack of technical skills required to 'browse' these new fangled websites.  What was the fun in something that displayed an image in one go rather than requiring a uuencode/decode process?

So which era do you belong to?  Or are there other classifications and strata that should be used?

When to shout, the art of constructive destruction

I've always believed that sometimes teaching is about the stick as well as the carrot but there are very clear rules on when to use the stick and how to use it.

Its not good enough to start with shouting, that marks you down as an idiot and a prat.  If someone has done something that you don't want but have never explained to them then its your fault as the person in authority.

Rule 1: You have to have explained first before you shout

The stick therefore is something that should only be used when someone has deliberately gone against advice or guidance.  If people have followed what you said and it didn't work... its your fault.

Rule 2: It should be obvious to 'the average man on the Clapham Omnibus'

By which I mean that the fault should be obvious to a person of the given level and experience, if its a junior person who has made the mistake then shouting is not appropriate.  If its a self-proclaimed expert who has screwed up then a kicking is in order.

Rule 3: Pick on the leader not the team

If there is a team of people who have screwed up, don't share the blame equally, that person is accountable to you for the team so they have to take the responsibility for the failure.  Their team will know its a joint thing and that the leader has taken the heat for them and this should improve the situation if there are any team dynamic issues.  If you flame the whole team it basically says that you don't accept that they have a leader so you should be managing them all directly yourself.

Rule 4: Be specific, be constructive in your destruction

'You are a moron' is not a constructive statement.  'If you don't explain to me how what you are proposing addresses the two key use cases then I'm going to have to kill you' is constructive destruction.  The point here is not to hide the anger but to make clear that your challenge is very specific and targeted and gives them the opportunity to respond.

Rule 5: Make perfectly clear you are pissed off

You should only be doing this when its got really bad so you have to underline that it really is bad.  This doesn't mean you have to swear or throw chairs about but it does mean everyone should leave the room knowing that they are in your bad books and that if they don't buck their ideas up then chair throwing might be in their futures.

Rule 6: Give specific ways they can get back into favour
Before the team breaks up be specific, give them a short time frame on how they can recover the situation.  These need to be actions you can, and will, track of the next few hours or days on how the team can show you they are getting back on track.

Rule 7: Be honest when you get it wrong, congratulate
If it turns out that you were wrong and in fact the team had been going the right way but you didn't have all the information then apologise and congratulate them.  Shake the hand of the person who stands up and says 'you got it wrong, here is the proof' and deal with it as you should, with humility and possibly donuts.

Rule 8: If things don't change make a sacrifice
If the team keeps working badly and avoiding advice its time to make a public sacrifice, this could be kicking them off the project or even out of their job or it could be as simple as public humiliation.  Putting a small statue on their desk saying 'Crap Architect', check with HR first on what you are allowed to do.  Use your companies formal processes to underline it.  The key is that you want everyone to think 'fuck I don't want that to happen to me'.

Rule 9: Be inconsistently angry
The penultimate rule is to not use anger and shouting as a 'what happens at level 10' thing.  Sometimes use it as an opening gambit, sometimes use it as a final twist, sometimes use it through-out a process.  The point here is to use anger and shouting sparingly with the team.

Rule 10: shouting isn't about volume
'Talk quietly and carry a big stick', shouting for constructive destruction in a project is not about raising your voice, its about the impact that an attitude carries.  Talking more slowly, deliberately and quietly can be significantly more threatening than shouting loudly in many circumstances.  The key here is the effect, occasionally you want people to change their ideas and give them a jolt, don't think volume, think impact.

Lets be clear, I don't think that shouting and constructive destruction is a thing to use all the time, but sometimes the stick is required these rules help me ensure that I don't just shout like Shakespeare said 'Full of sound and fury signifying nothing' but direct that anger and use it to save the situation.

Constructive destruction is about tearing down bad behaviours and providing a way to rebuild them in a positive way.  There are lots of touchy feely ways to do that, but sometimes fear is the right way.

Java SE - could it be more pointless?

Back in 2007 I gave a presentation on Java whose theme was that Java had won.

On slide 12 I put forward a proposal that I'd talked about here before as well in that Java needs to be professional and critically reduce to having a small core on which people can innovate and develop whether that be in smartphones, desktops, servers, virtual machines, smart cards or anything else that people dream up.  Simply put Java SE has no point in today's IT landscape as the 'primary' release on top of which everything else is done.

When I look at how SAP are pumping new life back into ABAP and how other languages are exploding, not because they make things better but because they address specific niche concerns.  High-performance computing still reverts to the assembly languages, in part because Java's bloat means it can't be tuned down to the core that they need.

The question is whether anyone has the guts to make the change or just continue on the road to obscurity.

Java needs a revolution, not another poor attempt at intelligent design.

How to weed out bluffers....

Following up from the concept of thinking being dead I'd like to talk now about one of the biggest challenges in IT.

How do you spot those people who are bluffing?

And here I mean people who don't really think they are bluffing because they are rubbish, or those that are bluffing because they think you are rubbish, its related to the challenge of Terry Pratchett Architects (PArchitects?) where how do you tell someone who distaines technology through knowledge v one who distaines through ignorance? The point is this:

95% of people interviewing senior IT people don't understand enough to weed out bluffers

This means that regularly I come across people who have a senior position based on a level of buzzword knowledge and general ignorance of reality that causes me to step back in amazement at the ability of the person to hold down a job. Normally of course these people are in jobs 12-24 months and often are contractors where such variability is almost seen as a benefit rather than an indication of being found out. So here are the top tips on weeding out the bluffers, and I'm assuming here we are at the Architect level and you can weed out bad developers...:

1. Don't do it in a phase 1 Tech, phase 2 HR interview process - add in a middle phase which is set up by phase 1. 
2. In Phase 1 ask the following 
1. When was the last time you coded into production, what language, what plaform? 
2. When was the last time you created a conceptual and logical data model? What platform for? 
3. What is the difference between Regex, Regular Expressions and Perl in string handling? 

The first two are the real set-up questions... the last one is something that stunned me once when someone I was interviewing kept saying "I did Regex" and then later on said 'On that project we used Regular Expressions', I asked him the difference and he said that Regex was a language, Regular Expressions was... a different language. The point here is that you are after an understanding of the languages and platforms for which this person claims some level of expertise.

Lets be clear here, I'm of the opinion that an architect, whether Solution, Enterprise or Business who claims to sit within the IT domain should still know how the platforms work and especially should remember how their last platform worked. In the second interview you should include real deep developers, get them to ask real deep developer questions. You aren't looking for 'this person is a bitch ass programmer in language X' but 'not brilliant, but seems to know his stuff generally'. What you are looking to avoid is 'I don't think this guy has ever used X in his life' or similar statements.

Similar approaches, but more abstract should be used for PMs and BAs where you should get PMs and BAs who have done similar technical projects to ask the questions. I'm stunned at how many times I meet someone who is a 'Functional' SAP BA and then when you introduce them to someone who really is a functional expert in that area they fall to pieces... sometimes not even knowing the acronyms of the SAP modules they claimed to have used ('We did supplier management, not sure what SAP called it') The point here is that you need a first stage to find out where the bluffer claims to have depth and then a second stage to rip the hole if it exists.

Bluffers florish in a world where thinking doesn't exist.

Thinking is dead

Anne wrote a reasonable blog a while ago on why SOA was and wasn't dead but I'd like to go a bit further today and say that generally the concept of thinking appears to be dead.  The value of 'thought' and thinking in IT has diminished, in a way that mirrors society at large, to the stage where design, planning, architecture and anything else other than just banging away at a keyboard appear to have been relegated behind opinions and statements as fact.

REST was a good example of this.  It was going to be the revolution, it was going to be the way that everything worked.  Two years ago I called bullshit on that revolution and I still say its bullshit and the reason is simple.

IT values technologies over thought

So people genuinely, and stupidly, think that how you shift packets from A to B will have a massive impact in how successful IT projects are at delivering their objectives.  What impact has this had on the massive spend of ERP packages out there?  Nothing at all.  What has impacted that?  Well folks like SFDC because they've shifted the business proposition and in so doing have moved the way business people think about IT systems.

The same goes around with Hadoop and Big Data.  The massive amount of information growth is complemented by an equally large amount of bullshit and a huge absence of critical thinking.  What is the major barrier to things like Hadoop?  "Its lack of real time ability" I hear people cry.  Really?  You don't think its that we have millions of people out there who think in a SQL Relational way and who are really going to struggle thinking in a non relational non-SQL type of way?  You don't think that the major issue is actually in the acquisition and filtering of that information and the construction of the very complex analytics that are required to ensure that people don't go pattern matching in the chaos and find what they are looking for.

We are currently seeing a rush to technology in IT departments that is focused hugely on bells and whistles while the business continues to look at outcomes.  With the business looking at SaaS, BYODand self-service applications the importance of thought and discussion in IT is acute. What I often see however is statements of 'fact' like 'you don't need integration its SaaS' or even worse a statement on a specific piece of API based technology as being important.

Planning, architecture and design are being seen in parts of IT as bad things as a mentality develops around a concept that some how basic fundamentals such as TDD, contract design and doing things that actually proven to work are in some way wrong.  Adoption of unproven technologies is rife as is the surprise when those technologies fail to deliver on the massively over hyped expectation and indeed fail to even come close to delivering at the level of dull old technologies that do the job but don't currently have the twitterati in thrall.

'Experts' in this arena has come to mean 'people who shout loudly' in a similar manner to US politics.  Facts, reason and worst of all experience are considered to be practically a disadvantage when being an expert in this environment.  I was recently in formed that my opinion on a technology was 'tainted' as I'd used multiple other technologies that competed with it and therefore was 'biased against it'.  I'd also used the technology in question and found that it was quite frankly rubbish.  Sure the base coding stuff was ok but when I looked at the tooling, ecosystem and training available from those competitors I just couldn't recommend something that would actually work for the client.  Experience and knowledge are not bias, thinking and being critical of new approaches is not a bad thing, thinking is not dirty.

When I look around IT I see that design is a disappearing skill and that the ability to critically assess technologies is being replaced by a shouty fanaticism that will ensure one thing and one thing only:

IT will no longer be left to IT folks

The focus of shiny technology over business outcomes and the focus of short term coding over long term design will ensure that IT departments get broken up and business folks treat IT as a commodity in an ever growing way.

Thinking, design, planning, architecture and being skeptical on new technologies is the only hope for IT to remain relevant.