comment

New Dog, Old Tricks

Peter Cripps comment , ,

I can’t believe this but today I have observed no less than three people using the latest wonder-gadget from Apple (the iPad) to play solitaire, Tetris and some other game which seemed to involve nothing more than poking the screen at moving shapes! Having just bought my own iPad and being convinced it conforms to Aurthur C. Clarke’s third law (any sufficiently advanced technology is indistinguishable from magic) I am aghast that such a technological wonder is being used for such mind numbing activities; just dust off your ZX Spectrums guys!

It’s Easy to Spot a Purist…

Peter Cripps comment , ,

…they’re the ones with no skin in the game. I came across this whilst reading about Hugh MacLeod’s new book on his blog. It set me thinking about how true this can sometimes be from an architecture perspective. Steve Jobs famously said “real artists ship”. Whilst there is a point to building good architectural models, defining principles that should be followed and road maps that describe the directions architects will be travelling in there comes a point that we must say “enough is enough, it’s time to ship”. The fact of the matter is that software development is, and always will be, a complicated activity and there is often no clearly defined answer to the wicked problems we need our systems to address. In fact, two of the attributes of a wicked problem namely, wicked problems have no stopping rule (instead the problem solving process ends when you run out of resources rather than when some ‘correct’ solution emerges) and solutions to wicked problems are not right or wrong (they are simply better, worse, good enough or not good enough) would seem to encourage the kind of purist behaviour where nothing ever ships. The danger with architecture (especially Enterprise Architecture) is that the artefacts being created are intangible things like models, road maps and principles and these by themselves do not make working systems. The people that produce such artefacts could often be accused of having “no skin in the game”. So how should you ensure that the architects in your organisation do indeed have skin in the game and knows that shipping is actually all that matters? Here is my SKIN (Specify Kill Integrate Negate) rule of thumb for ensuring delivery takes protracted (and unnecessary) analysis.

  • Specify to the right level of abstraction and detail, no more no less. The models, road maps, architectural principles that are defined by architects should be understood and usable by as many stakeholders as possible. This may mean having different views (levels of abstraction) of the same model but ensure if this is the case, those views are consistent. Think who your stakeholder is meant to be before building the artefacts and don’t build it if you can’t explain it clearly to that stakeholder.
  • Kill unwanted artefacts. Sometimes with the best will in the world you will build an artefact that does not have a purpose, is not read by anyone or has expired. Kill it, don’t let it linger on causing confusion and giving you an unnecessary maintenance overhead. Look at something like TOGAF for a good set of useful artefacts.
  • Integrate the work of the architect(s) with real downstream activities. Don’t let them work in ivory towers which have no grounding in reality. When planning a project and considering what artefacts need to be planned it is useful to think of what the inputs are to the task that is to create the artefact. If you cannot see any of the artefacts that are output from architecture tasks being used than maybe it’s time to consider killing off those artefacts (see above).
  • Negate unnecessary activities and tasks. Every task should have an output. This is usually in the form of a work product (a model, a piece of code, a plan or whatever). If you find you have some architecture tasks or activities (groups of relates tasks) that are not producing useful artefacts then its probably time stop performing those tasks.

Gapology

Peter Cripps comment ,

gap·ol·o·gy n. The systematic study of, and the method used to identify and close, gaps within and between organisational units (individuals, teams, departments) or social structures (gender gaps, race gaps). Becoming an expert in using gapology or studying gapology are the behaviors of a gapologist.

Okay, this is a definition I made up to make a point and create a reason for this post! You’ll find a couple more definitions here. My observation is that many of the problems we face in systems development are due to the presence of gaps of various sorts. Until we fill such gaps we will not be able to build systems that are as effective or efficient as they might be. Here are some of the worst.

  • The Knowing-Doing Gap. An article in Fast Company discusses this book which asks: Why is it that, at the end of so many books and seminars, leaders report being enlightened and wiser, but not much happens in their organizations?
  • The Business-IT Gap. The best known gap in IT. This is the inability IT have in understanding what business people really want (or the inability the business have in saying what it is they want depending on which side of the gap you are sitting).
  • The IT-IT Gap. This is the gap between what IT develops and what operations/maintenance think they are getting and need to run/maintain.
  • The Gender Gap. As I’ve discussed here there is still unfortunately a real problem getting women into IT which I think is detrimental to the systems we build.

Many of these gaps occur because of the lack of effective stakeholder management that takes place when building systems. A report published back in 2004 (The Challenges of Complex IT Projects) by The Royal Academy of Engineering and and The British Computer Society identified the lack of effective stakeholder management as one of the key reasons for project failure. The key learning point I believe is to understand who your stakeholders are, engage with them early and often and make sure you have good communication plans in place that keep them well informed.

Should We Ask Can We Fix It or State We Can?

Peter Cripps comment ,

In a recent Sunday Telegraph column author Dan Pink draws on recent scientific research which suggests that contrary to popular belief  “declarative” self-talk (I will fix it!) may not be as effective as “interrogative” self-talk (Can I fix it?) when it comes to solving problems. He also draws inspiration from that legendary management guru Bob the Builder.

Lisa Gansky (a serial entrepreneur) says that business leaders in general, and entrepreneurs in particular face an occupational hazard that she calls “breathing your own exhaust”. Gansky goes on to say:

“When you create something, you can fall in love with it and aren’t able to see or hear anything contrary. Whatever comes out of your mouth is all you’re inhaling. But when you ask a question – Will I? – you’re creating an opening. You’re inviting a conversation – whether it’s self-conversation or a conversation with others.”

So what’s this got to do with software architecture I hear you ask? The need for solving problems, especially wicked ones where there is no definitive formulation and maybe even no immediate or ultimate test of a solution, needs an approach which is different from the “all guns blazing” we can fix anything usual style of management consultants. Some problems are so hard they may never have a fully compete solution, just a series of compromises which hopefully result in you being in a better place than you were at the start. Maybe a little humility at the beginning will help in the setting of expectations therefore and reduce the distance you have to fall if you don’t deliver to those expectations.

In the meantime here are some videos to provide you with some inspiration around the fixing it theme:
Can We Fix It – Bob the Builder
Yes We Can – Barak Obama
Fix You – Coldplay (just in case it’s you that needs fixing)

Art, Creativity and the Tyranny of the Timesheet

Peter Cripps comment , , , ,

Apparently lawyers are some of the glummest groups of professionals out there! One of the reasons for this is the very nature of their profession; it’s usually a “zero-sum” game, if somebody wins someone else loses (and in extreme cases loses their life). Another theory, put forward by Dan Pink in his book Drive – The Surprising Truth About What Motivates Us, is that lawyers have to deal with one of the most “autonomy crushing mechanisms imaginable – the billable hour”. Lawyers have to keep careful track of every hour they spend, sometime to the level of granularity of six minute time chunks, so they can bill their time to the correct client. As a result their focus inevitably shifts to from the quality of the work they do (their output) to how they measure that work (its input). Essentially a lawyers reward comes from time, the more hours they bill, the higher their (or their legal practices) income. In today’s world it is hard to think of a worse way to ensure people do high quality and creative work than making them fill in a timesheet detailing everything they do.

Unfortunately the concept of the billable hour is now firmly embedded into other professions, including the one I work in, IT consulting. As IT companies have moved from selling hardware to software that runs on that hardware and then to providing consulting services to build systems made up of hardware and software they have had to look for different ways of charging for what they do. Unfortunately they have taken the easy option of the billable hour, something that the company accountants can easily measure and penalise people for if they don’t achieve their billable hours every week, month or year.

The problem with this of course is that innovation and creativity does not come in six minute chunks. Imagine if the inventors of some of the most innovative software architecture (Tim Berners-Lee’s world-wide web or Mark Zuckerberg’s Facebook) had to bill their time. When such people wake up in the middle of the night with a great idea that would solve their clients business problem what’s the first thing they reach for: a notebook to record the idea before its gone or a spreadsheet to record their time so they can bill it to the client!

As Dan Pink says, the billable hour is, or should be, a relic of the old economy where routine tasks (putting doors on cars, sewing designer jeans or putting widgets into boxes) had tight coupling between how much effort goes in and the work that comes out. In the old economy where a days work equaled a days pay and you were a day laborer you essentially sold out to the highest bidder. Isn’t what we do worth more than that? As Seth Godin points out “the moment you are willing to sell your time for money is the moment you cease to be the artist you’re capable of being”.

But what’s the alternative? Clearly IT consulting firms need to be able to charge clients for their work; they’re not charities after all. Here are my thoughts on alternatives to the tyranny of the timesheet which enable the art and creativity in building IT systems to flourish.

  1. Start with the assumption that most people want to do good work and incentivise them on the work products they create rather than the work inputs (time recorded).
  2. Recognise that creativity does not fit nicely into a 9 – 5 day. It can happen at any time. Scott Adams (creator of Dilbert) has his most creative time between 5am and 9am so is just finishing his work when the rest of us are starting. Creative people need to be allowed to work when they are at their most creative, not when company accountants say they should.
  3. When charging clients for work agree on what will be delivered by when and then build the right team to deliver (a team of shippers not time keepers). Of course this gives company lawyers a nightmare because they get involved in endless tangles with clients about what constitutes a deliverable and when it is complete (or not). Maybe giving lawyers a creative problem to solve will cheer them up though.
  4. Give people time-out to do their own thing and just see what happens. Google famously give their employees 20% time where they are allowed to spend a day working on their own projects. A number of google applications (including gmail) were invented by people doing their own thing.
  5. Allow people to spend time having interactions outside their immediate work groups (and preferably outside their company). Innovative ideas come from many sources and people should be allowed to discover as many new sources as possible. If someone wants to spend half-a-day walking round an art gallery rather than sitting at their desk, why not? Frank Gehry allegedly got his idea for the shape of the Guggenheim Museum in Bilbao from Picasso’s cubist paintings.

In the new economy, the conceptual age where creativity and versatilism is the order of the day the timesheet should be firmly assigned to the shredder and people should be treated as innovaters not just cogs in the big corporate machine.

Working with Zuck

Peter Cripps comment ,

In this article Facebook software engineer Andrew Bosworth describes what its like to work with the founder and architect of Facebook, Mark Zuckerberg (‘Zuck’). The attributes that Bosworth ascribes to Zuckerberg, that by implication are at least partly the reasons for his galactic success, are ones which I believe all architects should aspire to. Here are the four attributes with my spin on how I think they apply to architects in general:

  1. Zuck expects debate. A good architect is not a dictator but should expect, and be happy to participate in, debate. Be open to new ideas and don’t think you have all the answers. At the same time be robust in pushing back on any ideas to test out peoples thinking thoroughly. Be aware of people who play Devil’s Advocate and who argue just to be heard or are negative without proposing viable, alternative solutions.
  2. Zuck isn’t sentimental. It’s sometimes easy to be too wedded to an idea or your favourite technology. Be prepared to scrap these and to throw things away if they no longer meet the requirements or something better has come along. As Bosworth says of Zuckerman he is “fearless about disrupting the status quo and tireless in his pursuit of building the right thing, even in an ever-changing landscape”.
  3. Zuck experiences things contextually. As architects we often talk about ideas very abstractly and prefer to talk in generalities rather than specifics. Bad idea! A good architect (and indeed architecture) should be firmly grounded in reality and be backed up by actual products, prototypes, even working code! The best way of convincing someone of your idea is to build something that you can give them to play with.
  4. Zuck pushes people. People can often do more than they think (sometimes in less time than they think as well). The important thing is to be focussed on the problem and not the distractions that your job (as opposed to your work) may bring.

Wot No Blogging?

Peter Cripps comment

I think I’ve only just realised how much of a commitment keeping a “proper” blog (that is one that doesn’t just regurgitate information discovered elsewhere without adding some additional value or, better still, creating brand new content) takes! I’ve been distracted by other things of late (anyone looking at where I currently work and who is aware of what is happening in the UK economy at present may be able to guess what) however this month I intend to return with, I hope, a vengeance and give myself the target of blogging at least two meaningful, and hopefully of value, entries each month. This one does not count by the way.