…or at least talk. I’m appearing at the Epicenter conference in Dublin next week. I’ve got two sessions lined up:
Ending the Era of Patronizing Language Design
I linked, indirectly, to this article the other day and, after reading it again, I agree completely. Well, I agree completely with the notion that we should stop accepting “we didn’t put that feature into the language because you’re too stupid to use it” from language designers.
You really should read the comments accompanying the article, some are wise, many are interesting, unsurprisingly many seem to be commenting on a totally different article.
Now, what this doesn’t mean is that every language should have every feature, it just means that presumed incompetence isn’t an acceptable reason for not having it. Languages need to be designed with taste, discrimination and a desire to facilitate developer productivity.
For too long we have been told by programming language designers that we should eat our steak with a spoon because knives are too dangerous.
What sort of features am I thinking of here? Well, Java is a major culprit of the “you’re too stupid” mindset.
Automatic memory management : This isn’t the sort of feature I’m talking about. This is an enabling feature, something added to the language to help developers. Does it have drawbacks? Sure it does, there are times when direct-to-the-metal can be useful. But a decision was made here to facilitate in one area and compromise in another.
Operator overloading : Can it be used for evil? Sure. So can talcum-powder.. that doesn’t mean we should ban it and force our babies to suffer from trench-nappy-region. There are many cases where operator overloading makes sense and its absence in Java is painful. Exhibit 1 ‘BigDecimal’.
Immutable Strings : Another case of “not what I’m talking about”. Mutable Strings can be useful and powerful, but not having them brings advantages too. This was a conscious decision.
No meta-model : Without a meta model programmers dive into byte code manipulation and magical “doesn’t work like anything else in the language” constructs like DynamicProxy. Can meta-programming be hard and weird? Sure, so is physics. Shall we ban that? It isn’t the same, I hear you cry. You’re damn right it isn’t. Those guys created the atom bomb, and we still let/encourage/train/pay people do it. Heck we teach physics to CHILDREN. There are times in this world, when nuclear fission is just plain useful.
The list goes on.
I’ve just finished listening to The Art of Teaching Entrepreneurship and Innovation by Tina Seelig, a podcast from Stanford’s excellent Technology Ventures Program.
One of the key points I took from the podcast came from a story where Tina had given a group of students $5 and challenged them to create as much value as possible in a set period. Those who did best were those who realised that the $5 was a constraint, not an asset and worked around it. Those who limited themselves to the question, “what can I do with $5?” didn’t do as well as the people who asked themselves “how can I generate value”.
My favourite response was the group of students who, instead of using their $5, sold the presentation slot, where they were supposed to present their results to the university, to a local company who came in and did an advertising pitch. This group realised that the assets they had transcended the obvious raw materials in front of them.
To make the point clearer, in future years Tina substituted the $5 for post-it notes or rubber bands. Whilst the results of people trying to generate value with only a handful of rubber bands was more amusing, I personally think the lesson about looking beyond the obvious was more important. But, Tina Seelig is obviously a smart lady, I’ll trust her vision.
I was reading through the principles page on the Agile Manifesto site today and I realised that I’ve never really been very good at one of the items.
The best architectures, requirements, and designs emerge from self-organizing teams.
I’ve managed a lot of teams, and for the most part, I’ve been deemed pretty successful. My management style was always to try to blend in with the team, to be one of them, to get people to move forwards by setting an example or by encouraging them. I never introduce or describe anyone as working for me, I always say I’m working with them or we’re on the same team. Of course, there are management activities that need to be performed (reviews, promotions, demotions, bonus awards etc), and I’m happy doing those things. I’ve never felt that knowing people, or treating them as the equals (which, of course, they are) hampered me in any way. The more closely you work with someone, the more of the real them you see. You get a better idea of their potential, their skills, their interests, ways in which they could contribute more to the organisation.
I’m actually lying when I say I’ve never introduced anyone who worked for me as a subordinate. My friend and mentor, Gerry Martin, who was instrumental in my decision to return to college and retrain in software, eventually came to work for me. Every time I got to introduce him as my minion, I got a kick out of it. But, hey, if you can’t poke fun at your best-friend, who can you poke fun at. (Sorry Gerry, you know I love you.)
My attempt at egalitarian leadership didn’t always work out as I intended. One of the things I didn’t consider, is that because I could ignore differences in organisational authority, it didn’t mean that others felt the same. This led to one incident where I upset someone through an ill-considered joke that left them feeling angry, impotent and embarrassed.
I feel that, for the most part, the people on my teams were given authority and autonomy, everyone was given the opportunity to contribute as much as they wanted or were able to. There was opportunity for decision making, direction setting, personal contribution, group collaboration and individual growth. But, were my teams self-organising? Not really. I was always there trying to guide people in the direction I felt we should be moving. Not by edict, decree or demand, but by persuasion, example and leadership. But, in the end, however gently the boss tries to guide you, you’re still aware that he’s the boss and his opinion carries more weight than merit alone. It wasn’t a democracy or a meritocracy: even if everyone disagreed with me silently or publicly, it wouldn’t have led to my replacement.
Is this a problem? Perhaps. I’m not sure what the alternative is. I firmly believe, that leadership is vital to the success of any organisation. By leadership, I don’t just mean “somebody has to be in charge”, I mean that someone has to accept responsibility and authority in equal measure and then use that authority judiciously, sparingly and only for the good of the organisation and all of its stakeholders.
Is a truly self-organising team possible in a commercial organisation?
I finished off Almost Perfect this morning and I must admit I was a little disappointed by the ending. All the way through the book I’d interpreted Peterson’s actions one way, and then, in the last fifty pages he started to spout his personal philosophy and I realised that I had been interpreting things in a more charitable way than I now feel he deserved.
One of the things that irked me the most was the section where he described how the employees had been asked to work long hours, six days a week for over a year and they’d done it because they were trying to help the company. Then he follows on with complaints about people being unprofessional and visiting the doctors or the dentists during the day. He complains extensively about anyone doing anything not directly work related during business hours - down to being angry at people for showing new baby pictures to colleagues - and then spends long paragraphs describing how productive he was during his afternoon tennis games, or how much he accomplished just by sitting on the beach relaxing and thinking.
“Hi, my name’s Pete. I’m inconsistent and unreasonable.”
I think he must have taken criticism about some of this in the past because the on-line version has a number of the later pages missing. The second-hand copy I got from Amazon was the complete text and the extra light it shone was, as is the nature of light, illuminating.
I’d still recommend the book to anyone who wants to read it. One particular section near the end of the book contained a valuable lesson.
Peterson had described their problems shipping enough copies of a new version of WordPerfect. A few years later, their next major release was due to ship, in the months leading up to their IPO. The launch went off without a hitch and first month sales were at a record level. Then they died off. The next month wasn’t much better. This unexpected, and un-predicted, drop off in sales hit their IPO hard.
During analysis of the slump, they discovered that because their distributors hadn’t been able to get enough product to supply demand after the last major release, they’d over-ordered for the release of the new product. Since they’d over-ordered, they were carrying extra stock and they didn’t need to re-order. This created a month one with unrepeatable sales, making all subsequent months look bad, and months two and three were bad by any standards.
Apart from all the usual lessons about judging sales based on fulfilment of only part of the supply chain rather than completed end-to-end transactions we’re left with a crystal clear example of human behaviour.
People will guess your future performance based on your past performance. It doesn’t matter what you say or do, a man, or a company, is judged by their actions.
Next Friday, the 29th May, Clarke Ching and I are teaching a one day workshop in Edinburgh entitled ‘An Introduction to Agile, Lean and Kanban’.
We’re charging a small fee (£30) to those who’re in full time employment: really, just enough to recoup the costs of renting the room. Entry is free to those who’re currently an ‘under-utilised resource’ (HR speak for unemployed).
If anyone is interested, please contact me at rob@
I’ve been reading W.E. Pete Peterson’s excellent book Almost Perfect (available to read on line here) and he has some interesting things to say about his attempts to add copy protection to WordPerfect. At the time he was running WordPerfect Corporation and was one of only three shareholders, so his perspective isn’t an academic one:
“It was simply not fair to make the honest, paying customers put up with an inconvenience that had been made necessary by the dishonest ones. In the end, what was good for the legal customers was also good for our bottom line.”
The book has been a most entertaining and educational read. It’s great to read the story of an ethical, decent man who built by success without sacrificing his principles. Particularly heartening from a technologists perspective is that he attributes the companies early success to the quality of their engineering staff and their ability to hang on to smart individuals and focussed teams.
Sadly the book has been out of print for a very long time, but second hand copies are available on Amazon, that’s where I picked up my copy.
Everywhere I go, I see the same thing. “The best way to avoid swine flu is to wash your hands after you go to the bathroom.”
So, if this advice were to be believed, the source of swine flu is one’s own genitals. This does not seem likely. I don’t understand why seemingly rational, intelligent people keep stating this again and again as if it made sense.
My penis is not the source of swine flu. If my penis had swine flu, then I’d have swine flu. I cannot catch a disease from myself.
When I say I can’t understand why smart people would relay this same, obviously bad, advice again and again I’m really lying. I can understand it. There’s a whole host of reasons but mostly it is people attempting arithmetic with small numbers and failing.
Washing your hands may be able to help reduce your chances of catching certain ailments. Or it might not. But it has nothing to do with making use of the WC.
Sadly this sort of conflation of ideas happens all the time in the programming world. People take some idea that seems reasonable, toss in a dash of something else reasonable, shake and concoct a third thing of ‘limited utility’.
Looking for an example: well, take much of BDD for a start.
BDD = Penile swine flu.
I’m just going to leave that hanging there for a day or so whilst I write up my thoughts properly.
David Anderson’s InfoQ talk on Kanban and software development is fascinating. In particular I liked the clarity of the numbers he produced to prove the successes of his methods. I also liked the photographs of the tracking boards that different groups were using, David’s analysis of them and the way they changed over time as groups came into contact with each other.
All in all, a thought provoking presentation that backs ideas up with concrete numbers.
After watching Dan Roam’s presentation, I decided to see what else looked good from Mix09. The day 1 keynote from Bill Buxton - available right now on the front page of the site gave me an insight into the mind of a designer that I didn’t have before.
Bill talks extensively about the history of industrial design and its rise during the great depression and that we can take the opportunities of the current financial crisis and use them to make usability design a priority.
I’m not sure if his logic, that crisis periods are inherently periods where design can prosper, is well founded but .. let’s hope it is. When you’re stuck in a financial hole, digging may not help but just sitting there doing nothing certainly won’t work. If innovative design and engineering can give us hope - let’s get to it.
Some of the ideas that Bill pushed strongly on were the notions that design has to be fast, has to be iterative and that only trying one approach to solving a problem leads to sub-optimal solutions. I’ve tried the first two of those ideas in development and they work like a charm. I wonder what it would be like to try to get several different solutions to the same problem in parallel? Perhaps that’s really what’s going on in the Java web framework world, or the .NET DI container world. Perhaps, rather than being frustrated by the problem of trying to learn and decide amongst multiple choices we should rejoice that we have options; we should be pleased that we get to choose the design that we believe in most.
The other big take-away that I got from Bill’s presentation was that in selling something you shouldn’t try to sell the item itself. You should sell the experience of using/owning the item. I can see this as a useful tool when trying to build software and also to make engineering decisions. Build software that will lead to a positive user experience and you’ll be a success. When considering two engineering alternatives, ask people to imagine the experience of living with that decision. Ask the technologist to put on his negative/remember-all-the-times-things-didn’t-work-the-way-they-should hat on and ask him to imagine what life would be like.
I’ve said it before, and I’l say it again. I love watching smart, passionate individuals talking passionately about their passions.
I like the teams I run to use pair programming, because the end product is better. I’ve also heard lots of people say that they don’t want to do it.
I have a theory that pair programming is the brussels sprout of the technology world. Lots of people don’t eat them because, not because they think they’re bad for you, but just because they don’t like them
I have no children. When I do, they’ll eat brussels sprouts. I won’t do it because I want them to be sad, or to make those little sicky faces that children pull when they put something unfamiliar in their mouth. I’ll do it because I want them to be healthy, productive and to live a long time.
I’ve been working on my CV recently and finding it hard to quantify what I do and am. I’ve worked in almost every capacity in technology:
And a whole bunch of other roles that don’t even have good names. I’ve loved every one of these roles, I’m fascinated with every aspect of technology. Beyond that, I like to flatter myself that I’ve acquitted myself well in all of these roles. I love technology, I love managing people. I love guiding and participation of the creation of something out of nothing. Well, nothing more than sweat, tears, inspiration and a compiler.
I’ve always loved the idea of being a polymath, a renaissance man - but sadly my interests have always been restricted to one field. Luckily it is a pretty big field and there are few people that have become masters of it all. I’m not there. Not even close. But I’d like to be.
Everyone needs a goal in life. “Be the best you can be at the thing you love” works for me.
In a post entitled, simply, Software, Rafael de F. Ferreira juxtaposes quotes from James Bach, Erik Meijer and an Alan Kay/Phil Windley amalgam to put together an intriguing argument that quality software doesn’t exist, people no longer care that quality software doesn’t exist, computing is in its infancy and we don’t know much yet, but we’re also not really learning so things aren’t getting better.
I’m not sure I buy it. In fact I’m sure it is bunk. I’ve said for a long time that The Software Crisis doesn’t exist. As an industry we create more, better software cheaper than ever before. WTF is the crisis?
Can we do better? Yes.
So why do people talk about a crisis? Because programming attracts smart, dedicated, attention-to-detail-oriented, meticulous, perfectionists who’re never going to be happy. People who’re always going to want to do better. For many people - including me - software is my art, my hobby, my career, my passion. I want it to be great. I won’t accept second best. I won’t accept shoddy or badly done or half-hearted. I want to build the best .. whatever the hell it is I’m working on.
Equally, I won’t accept people telling me what a bad job the software industry does any more. We don’t do a bad job, we do the best job of writing software that anyone ever has in the history of the world. Possibly the universe.
Can we do better? Yes. Can you beat me with the crisis stick? No, sir, you may not.
My good friend, Clarke Ching, today proposed that we reach out to universities and colleges to help them teach students the things we’d like them to know when they graduate. I’ve done some of this in the past working with universities and colleges in the US and the UK, it was very rewarding. I’d love to do more.
Bob Martin has a presentation he gave at a JAOO conference up on InfoQ. The title of the presentation is Craftsmanship and Ethics, which is somewhat misleading since the presentation is basically on Software Craftsmanship prefixed with “we should be craftsmen, craftsmen should have ethics, it’d be unethical not to”. I was a little disappointed by that - I was interested in his thoughts on ethics and how they relate to the development.
Overall it is an entertaining presentation that will leave the Agile and SC groups nodding and leave those with a different mind-set shaking their heads as normal. I enjoy watching passionate people talking passionately about their passions… so this was fun; but I don’t think it changed any minds or taught anybody anything they didn’t know.
I’m assuming that the crowd at a JAOO event is composed of experienced professionals who care about and investigate their industry. To effect change it isn’t enough to speak passionately. It isn’t enough to tell experienced professionals what you think or feel - they have their own thoughts and feelings and there’s no reason they should supplant their own with yours. People need compelling reasons to change, they need people to provide compelling solutions to immediate problems, they need to believe that by changing they are shedding risk rather than increasing their risk profile. Passion isn’t enough.
Uncle Bob, and the other leading figures in our profession have the opportunity to speak directly to thousands, indeed millions of developers each year, and I don’t think that what they’re doing is working. The Tony Robbins style pitch is enough to get people fired up at the conference, it doesn’t carry enough momentum to provide a solid take-home.
I’m reminded of Geoffrey Moore’s Crossing The Chasm: Agile, Lean, Craftsmanship, all these ideas have been sold to the innovators and perhaps even the early adopters, we need to cross the chasm to get to the next group of technologists - the early majority. Even this isn’t enough, though. We haven’t got the message through to project mangers, business analysts or customers, let alone C*O types. We can present compelling cases when we talk to people one-to-one, but the ideas haven’t taken root in these communities; in Chasm terms we still don’t have a hook in the innovators there.
If we advanced the management and technology communities in parallel we’d have a much better chance of improving the way software development is done.
How do we do it? Well, first off, I think we need to stop talking about quality, top talking about Agile and Lean and Craftsmanship and start talking about value. Value is what everyone wants. Developers want to create value, managers want value created, customers want to buy valuable software.
I firmly believe quality leads to value, but telling people they should want quality leads nowhere. Tell someone they want value and they retort, “Of course I do, how do I get it?”. NOW you can say, “Well, every industry in the world has come to accept that building in quality leads to higher value.” At this point, I’ve never heard anyone say, “Hmm, that sounds hokey. Go build me some shit. I’m sure that my best path to value is by heading through latrine-town.”
When technologists, managers and customers talk about value, they may not all understand it in the same terms. At least not at first. But until they agree on what value is, there’s no way to build successful products or relationships.
The idea that people might not have the same understanding of value is something that many technologists don’t get right off the bat. To explain it, I need to take back something I said a few lines ago. I don’t believe that quality always leads to value. This also brings me back to Uncle Bob’s talk.
I have worked in environments where financial opportunities would arise out of nowhere, last for a few days or a couple of weeks and disappear. In these cases, the opportunity to make millions of dollars a day can exist if you can(in abstract terms) get information in, process it and send it back out within a specified time period. Oh, and the countdown on how long you can do this for has already started. Every moment between now and shipping costs a non-trivial sum of money. In these cases, value comes from shipping. The software might have problems - if it crashes every fifteen minutes night and day, that’s OK .. we’ll run ten copies on ten machines and have ten interns sit and watch them clicking the icon every time it falls over. The software doesn’t have passwords or security, that’s OK we can hire a rent-a-cop with a gun to keep people away from the computers.
Overall, doing this makes money. Sure, over the first few days the team try to improve the quality so that half the interns can go home - but the software is going in the bin in a week .. improvements beyond basic stability are a drain on assets nothing more.
I’ve heard developers shout about this being a terrible, shoddy way to do software and insult the developers who build it. I may even have been one of them. That’s because I wasn’t thinking about generating value with my software, I was only thinking about software for the sake of software.
Now I think about value, I can understand why people build software like that. I can also understand that we can get that software out of the door faster by looking at what we build in each case and trying to pull together some pieces that they can glue together the next time an opportunity arises. Pieces that’ll let us be EVEN faster to market next time. That’s value.
My point, value isn’t a universal truth. Value is relative to the situation. If everyone talks about value at the start, and forms a common understanding we can fit everything else into the framework this gives us.
Uncle Bob, luminaries of the development world, talk about value. Please.
This morning I opened up a copy of Dave Hitz ‘How To Castrate A Bull’ and I’ve been totally blown away. I read it cover-to-cover without standing up. This was unfortunate because I was in the bath. I filled the tub over and over with hot water until I was done because I couldn’t bear to stop to dry myself until I had got to the end.
Dave (someone else I’m on first name terms with by dint of having read his writings) tells of his experiences as a founder of NetApp. The book is filled with amusing stories and side-bars, coupled with sage and hard-won advice, recounting of failures and successes with equal honesty, passing on of lessons learned from others and a thousand tiny observations each a gem in of itself.
I only wish Dave had a second, parallel company at the same time so he’d have a sequel.
Last week I said that I’m using the time I have free to catch up on my reading - getting to all those books I’ve been meaning to get through.
First on my list was Eli Goldratt’s latest book The Choice. It’d been a while since I read his other works, so I decided to re-read them first. In the last few days I’ve re-read The Goal, Necessary But Not Sufficient, Critical Chain and It’s Not Luck. Every time I read these books, I get something new out of them. If you’ve not read Goldratt’s work, I heartily recommend it.
I said that I was re-reading Goldratt’s earlier works in preparation for reading his latest book. I haven’t got to that yet, that’s next on my list. I got distracted when a friend tried to explain something to me by referencing Seth Godin’s Purple Cow theory and, since I haven’t read the book, I didn’t know what he was talking about. So I read ordered a copy from Amazon and read that last-night and this morning.
This is the first book I’ve read that just focusses on the ‘getting the message out’ end of marketing. I’m surprised that I got as much out of it as I did. In retrospect, this is a field I should have spent more time reading about. I need to work to fill in my knowledge here. Anyone with pointers towards the ‘right’ reading material feel free to drop me a line.
Agile development is more culture than process: “Why thinking of agile as culture and not just process explains resistance and difficulty in teaching and learning the approach”
(Via Jeff Patton.)
Jeff Patton presents a well thought out, well articulated article. But one I couldn’t disagree with more.
Jeff presents an argument that Agile isn’t a process, but a culture, and I’d agree that Agile isn’t a process but, despite the many Agile proponents who make it seem that way, Agile isn’t a culture either. Agility is just one quality that an organisation can have. An organisation can have an Agile culture, but that doesn’t mean that that their culture is Agility.
Presenting Agile as a culture is something I’ve seen many times, and it puts more people off. Agile zealots, a club I was a member of a decade ago, try to sell Agile as a culture in a way that reminds me of Mao and his Cultural Revolution; they want to come in to your organisation, declare your culture to be bankrupt and rip it out, replacing it with an idealised regime of their own. (I do not put Jeff Patton in this category, his writing is very sensitive to the existing culture of organisations.) Mao famously said that political change can only come through the barrel of a gun. Mao’s way may have changed china. But it isn’t the way to change organisations in the twenty-first century.
An organisation that wants to undergo an Agile transition is an organisation that wants to acquire a new quality. Adopting this new quality is not easy, that’s why experienced Agile practitioners can be invaluable during this process. Cultural change is not easy, it is painful for organisations and the people that make them up. I think this is why Jeff, and the rest of us who’ve been down this road, have seen push-back and pain when performing transitions.
You must be sensitive to the needs and feelings of an organisation. You must be conscious of the times when existing cultural practices, processes and artifacts are in conflict with the changes you are trying to make. You can’t steam-roll people and tell them that their existing culture is valueless, you have to show them what they have, where they can be and help them make the journey.
After the transition an organisation should have Agile qualities. They shouldn’t be Agile. An organisation that has no quality but Agility can not survive, they have nothing unique to offer the world. As someone performing an agile transition, we should strive to ensure that the organisations we work with should be strong, energetic, diverse, healthy and Agile. They should have their own culture at the end of the process, just as they did at the start. Just a bit better.
Over the last few years, I’ve moved past Agile. Not that I think it is bad, I still embrace it fully, and I still use Agile practices because I believe they work. But Agile isn’t everything, any more. It never was, I just didn’t see all the other things that I and those around me were doing. I think that Agile brought the humanity back to software development, something that had been bleeding out and something that we need to be effective. Agility recognises that it is people who write software and that by remembering that fact, we get the most out of the people.
These days I consider myself to be in favour of Humane Development. Respect people, respect their culture, challenge people to do more, to do better, reward them for successes, help them when they falter, teach them to be the best they can be and expect their best efforts from them in return. Like Agility, organisations need to have Humane as a characteristic if they are to thrive.
If your users can’t find the feature it might as well not exist: “The lesson here is that having a feature isn’t enough, making sure your users can easily find and use the feature is just as important. In addition, sometimes the best thing to do for your product isn’t to add new features but to make sure the existing features are giving users the best experience.”
(Via Dare Obasanjo aka Carnage4Life.)
Dare brings up a good point, if users can’t find a feature .. it might as well not exist. There are a number of related issues here, too. How many features is too many? Is there a critical mass of features, beyond which the utility of an application actually goes down whenever you add a feature?
A lot of people conflate utility and feature set. And they’re definitely not the same thing. A swiss army knife has a lot of features, and some very sharp blades, but they’re difficult to hold because of all the tools so they’re not comfortable to use. Indeed, the more tools you add to them, the harder they are to hold.
Dare also talks about the constant mass of new feature requests the Microsoft Office team get. I’m not a power user of Office by any means, but I don’t remember the last feature that was added that made a difference to me. Are MS sacrificing the utility of Office by adding more and more features? Has the experience of the average user actually gone down over time? I don’t know the answer to any of these questions.
The situation, does remind me of Goldratt’s book Necessary But Not Sufficient, where he describes a company that are swamped with feature requests from users, feature requests that come in faster and faster over time. His suggestion is that people are asking for new features for two reasons:
1. The product is not addressing people’s core problems. The users don’t really understand why they’re not satisfied so they ask for more and more features which seem like they might help .. but never do.
2. The producers of the product don’t work with the users to get them to change, they constantly change the product to suit every individual customer adding more and more ways to do everything until you have such a mass of features that you’ve lost any sense of consistency or cohesion.
I’m not advocating feature minimalism: I still don’t understand why I can’t have a right mouse button or a delete key on my Mac. But I do thing that software engineers consider the benefit of features rather than considering the total cost of ownership of them. When considering the value of a feature, particularly in shrink-wrap software, you need to remember that it’s very hard to take a feature out, so you need to be sure that you want to carry this feature forever.
Features have value. Not having features can have value too. Developers don’t get a buzz out of not implementing a feature though ..
I switched from Safari to Firefox about six months ago. Firefox had a feature that made me want to switch; if you close Firefox with open tabs, it offers to save them for you for next time. At the time I was taking my laptop with me to work each day and shutting it down during transit saved battery power. It was a pain to have to go through all the tabs and figure out what to bookmark and what to discard.
So that seemed like a good idea, and I’ve used that feature every day. I now have over one hundred tabs open, many of which I’ve not looked at in months. In fact, this article Ancient Egyptian Numbers is one I opened when Clarke linked to it in mid-october. I’ve not read it. I still plan to but …
The feature I liked so much, turns out to be an anti-feature; at least in the hands of a someone with a tendency towards procrastination, like me.
Teaching CCPM in an Academic Setting: “I had a kind of slap-in-the-face moment some months ago regarding ‘on time,’ namely the difference between on time as a measurement and on time as an objective. “
(Via Robert C. Newbold’s Billion Dollar Blog.)
I think Mr Newbold has an interesting point here. People find it hard to distinguish between a measurement and an objective. When I first read his comments it took me several seconds to figure out why I would be measuring something if that wasn’t what I wanted.
In the case of software features, I want them completed as soon as possible; but I can’t measure ASAP, so I’ll probably measure what I can - compliance with a plan. It is important for everyone involved, project managers, developers etc. to understand that the plan isn’t what we want. What we want is as much value as possible, delivered soon as possible. In fact the plan is, in real terms, often a listing of the worst case scenario that we can tolerate. Working to the plan in this case is a terrible idea.
I’ve just been reading Neal Forde’s three part series on SOA. An interesting piece in of itself, but one part in particular caught my eye:
Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy): “what is strategic to the business is always tactical to IT. Business people can go into a conference room and change the entire direction of the company in 2 hours. Or, the business may decide to merge with another company that has truly dysfunctional IT, but other business concerns override that. IT can never move as fast as the business, with means that IT always has to respond tactically to the decisions and initiatives brought forth from the business.”
(Via Meme Agora.)
Is it true, that, IT can never move as fast as the business?
As a technologist, it’d be easy to dismiss this claim by pointing to a single example where technology drove forward the business, thus refuting the claim that it never happens. But that isn’t really what the author is talking about and isn’t really what interests me.
Businesses have a historical rate of change, how often they’ve changed their products, offerings, pricing, strategy, structure etc. And, if you look at the historical rate of change of technology it will match it one to one.
But that’s only part of the story. Most businesses that I know, don’t have a constant rate of change. Change is lumpy. Change comes from a stimulus: a new opportunity, a new marketing campaign, market conditions, technology, the economy, science, new staff, new ideas, failure of a competitor, a new competitor on the block etc. A stimulus occurs and a business must change to meet the new demands or opportunities.
When a business wants to change, how does their IT department work with them to support that change? Do they match them stride-for-stride? Are they a drag saying, “oh, no, we can’t do that in less than eighteen months”? Or are they an asset to the company and they find ways to accelerate the change, giving the business options and opportunities they didn’t think they had?
Too often a business can only move at the rate their IT department will let them. In the year 2009, everyone in IT needs to make sure that they are enablers for their business. We need to partner with the business people in our organisations so that we can give them options. We have tools of unparalleled power and flexibility at our disposal, we need to make use of them for the benefit of the organisations we work for. We need to do this to survive, we need to to this so that IT is a profit centre for our organisations not a cost centre. Now more than ever, if you can’t point clearly to the benefits you bring to the bottom line, nobody else will. And if you can’t point to those benefits then there’s never going to be security in your role.
In many organisations there’s a culture of hostility between the business and IT. In my experience, this is often because the business have asked for change in the past and IT have been unable to deliver. This situation will not fix itself.
The answer is partnership. That’s the second time I’ve used that word in this posting .. and it is one of those words that everyone uses when they’re stuck for a more meaningful concept. Everybody agrees we should be partners. Partnership is ‘a good thing’. Nobody is going to stand up and say, “bah, partnership, bloody awful, not doing that”.
What does partnership actually mean in real terms? Sadly, it is one of those “I’ll know it when I see it” things. I can tell you where I start when I want to build a business partnership though. I start with the word but.
“Yes, I can build the thing you’ve described to me but I can do this in half the time. Would that be better?”
“No, I can’t do that by tomorrow night, but I can do this other thing. Would that do in the short term?”
“Hey, I noticed we’re doing this, but we could do this other thing. Would that save you time?”
“Hey, I spend a lot of my time doing this, but if we changed to doing things this other way, I’d have more time to help you with that. Would that be OK?”
Recent Comments