Why is it so hard to give Apple a little more credit for the iPad?

I’ve quickly skimmed through the latest wave of tablet review here, and a nice review round-up here. The single common trait to many of the reviews I’ve seen is that “Despite some nice features on the device…, H-P and other tablet makers have yet to introduce something that compares to Apple’s tablet.” (MarketWatch quoting Mozberg).

To me, perhaps the pundits should give more credit to Apple, as their achievement seemed to have left just about every one else in the dusts. Repeating myself, a strategy that bases itself on “me too” is often going to stutter if not simply fail. Maybe there’s just too much of that going on, more so than say acknowledge how hard it can be to deliver a solid tablet (mobile?) experience.

On an entirely different register, I can’t wait to see the reviews on Google+. It’s all nearly too predictable.

Information Systems Architects should write solid code. Part 1, Why?

I believe that, in Information Systems environments, an architect should be first and foremost a very good programmer. The architect should write code on occasions, it would be better if writing code is actually a habit. When this is the case, the Architect is able to bring a positive influence to the organisation. When this is not the case, the Architect would most probably be less efficient and will find himself/herself regularly stuck in unproductive discussions. Unfortunately, a non-negligible amount of inefficiencies stem from the Architect’s lack of awareness of the application platforms and code and the engineering activities surrounding them.

This can be proven ab absurdo, but I will provide a simple case to illustrate the point.

In this and subsequent postings, I plan a multi-part posting, I will be using the term Architect to refer to anyone who has responsibility in capturing user requirements and translating them into instructions for programmers. This broad definition includes business analysts and application designers. Though infrastructure architects and designers play a key role in shaping up the IT environment, I will classify them as programmers in this discussion because they are often at the receiving end of something specified by someone else.

Those who have needs and ask for something to be done with the IS/IT systems are users.
Those who translate user needs into work instructions are architects.
Those who actually execute the tasks of creating or modifying IS/IT systems are programmers.
The expression write solid code designate the act of creating an artefact that can be unambiguously understood as machine code, when used in a modelling context these are formal model artefacts, when used in a programming context these are program source code.

I know there might be a million other definitions out there. I think, at this point, someone could take offence and quit reading. That would be too bad. I am not interested in definitions and titles, I want to make a point and I need these specific working definitions. They work fine in this context, take my word for it.

Let’s give a simple persona to our IS/IT Architect,  Kermit. Kermit is a man in his mid-thirties, he works for a company called Trotters Fresh Dairy Products  Ltd (known as Trotters).

Say that Kermit does not write code, whatever the reason. This means that Kermit is not familiar with coding issues because he doesn’t deal with them regularly (so Kermit actually knows a programming language? good for him, but he is not involved in coding at Trotters and that that’s the point here). Kermit only talks in concepts, not related to code.

Kermit communicates his concepts to the programmers Robert and Marie-Louise using diagrams and explanatory notes. Kermit also communicates with business stakeholders using diagrams and explanatory notes.

As software is written, there will inevitably be mismatches between the application release(s) and user expectations – malfunctions are particular kinds of mismatches, changes in user expectation are also forms of mismatches. Resolving any such issues involves representatives of users, programmers and architects. At the very least, Trotters IS/IT will be facing a number of challenges due to the combined effect of the following factors:

  • Kermit made his architecture decisions based on his extensive knowledge of widely used architecture frameworks and standards, papers from industry analysts and discussions in architecture communities, his own perception of what the business is about and what matters most to Trotters business and organisation
  • Kermit’s architecture was interpreted by the business according to their knowledge, their perception of IT and software (often shaped by external influences and people background), and their evolving needs
  • Kermit’s architecture was interpreted by the programmers according to their knowledge, the platform and programming tools they are using and the resources that were available to do the work.
  • Coding was constrained by a number of factors including technology platform, programming tools, resource availability, Robert and Marie-Louise are not aware of everything that might be possible with the tools in their possession. Some of Kermit’s suggested principles were not feasible due to these constraints, choices had to be made on-the-fly.
  • Changes constantly occur in Trotters’ business environment, with them people adjust their perceptions and their expectations, it is very hard to convey all those changes in a usable and timely manner to all stakeholders. So people make assumptions that they feel comfortable with and won’t necessarily validate such assumptions.
  • Business is always pressed for time, competition is fierce in Trotters’ industry, financial constraints are ever present, decision makers are dealing with compromises all the time

Arguably there is more to say about the factors that influence complexity in the organisation, the above seem sufficient to make the point here. Let’s analyse the impact of Kermit’s lack of awareness of the code:

  • Industry architecture best practices, analyst white papers, none of this make sense until they are cast into the reality of a specific organisation. This cannot be done efficiently without intimate knowledge of the platform and the way the application is being (or supposed to be) coded. With Kermit, Trotters organisation will be learning this reality casting process the hard way
  • Even if perfectly drafted, the architecture can quickly become stale because the business reality would have moved after Kermit issued his blueprints but before the applications could be fully built and released.
  • Kermit couldn’t coach Robert and Marie-Louise efficiently, because he wasn’t involved in the coding. Even if Kermit would work closely with the programmers, since Kermit can’t write solid code, then a significant amount of the programmers’ time would go into educating Kermit on coding issues and practices
  • The numerous micro-decisions made during the software construction contribute to a non-negligible change in the initial promises of the architecture, such changes will not surface until an application release is available to the users.
  • Kermit misses the chance of bringing any lessons learned back into his architecture vision, because the feedback loop is not present or is poorly executed. Conversely, Kermit has little or no way to ensure, thus guarantee, that his vision is actually been executed upon. If the vision wasn’t correct, that fact is not properly reflected everywhere. If the vision was correct but was poorly executed, there was nothing to prevent that from happening
  • Vendor platforms evolve, so any knowledge built on a particular set of vendor solutions is likely to become obsolete and require refreshing before it is put to use after a certain amount of time. This constant knowledge renewal typically doesn’t happen, sometimes because it cannot be afforded, but also partly because people tend to get stuck in their routines and fail to notice that their knowledge is becoming obsolete. There is nothing in place to validate that knowledge at Trotters’ is adequate and aligned between the architecture practice and the programming practice
  • Kermit probably know some technology platforms very well, but there is no telling that he knows the particular platform that is part of the solution at Trotters, or perhaps the platform has evolved since the last time that Kermit did any hands-on work on it.
  • Kermit cannot assess the experience of Robert and Marie-Louise on the platform either. Conversely, Robert and Marie-Louise have no effective way to find out about each other’s strengths and ensure they are complementary. Trotters’ organisation has to trust that things would work out somehow
  • Sometimes people do notice that their knowledge might no longer be sufficient, some could then become defensive and would fight to keep any blind-spots from the open. This is human, it can be fought but it should mostly be managed. Users, architects and programmers at Trotters are facing the same dilemmas, they might not even be aware that this could be motivating some of their actions.

We can go on and on about the factors that could be causing mismatches between user expectation and application releases, but the above is sufficient to derive a pattern and draw some preliminary conclusions.

When there is any significant distance between the architects and the actual solution building and delivery, inefficiency tends to creep in very quickly and organisations don’t get the most of their assets. It does not help when those who specify what needs to be done and outline how it should be done, are removed from the actual construction of the solution. When the architect has no idea what code was (or is being) written, he could be talking about concepts that only exist on his slides and documents but actually never materialised. What would be the point of that? The above is the rationale behind my statement that An IT Architect should write solid code.

In next settlements I will elaborate on how an architect could be writing solid code, increase his effectiveness in the organisation and ensure that his vision of the solution is as close as possible to the actual solution. I will call this Say it in Code.


I am an IS/IT Architect, I could be subject to the same shortcomings described above. This is one of the lessons that I have learned over time. I’ve always felt this to be an issue in my job, I try to minimise any gaps between the vision and the realisation that was made of it by staying close to the code.

Failure with Enterprise Systems: why we don’t learn, and what we can do about it

Tim Bray wrote a great article with the title: Doing It Wrong, in which he is sharing his insights on the perennial IT failures and how other’s manage to succeed despite ignoring the enterprise mantra. Tim made a lot of good points, the reactions to it where mostly great reading of their own. I thought my reaction warranted a blog post of my own, since otherwise it’d be a long comment lost in the jungle.

I won’t paraphrase Tim Bray here, his original posting is well worth reading: http://www.tbray.org/ongoing/When/201x/2010/01/02/Doing-It-Wrong

At this point, I must warn the reader that most of my parabolas are best understood when situated in the context of mathematical set theory, and loosely, in probabilistic terms: the chances of, and the lack thereof. Thinking in terms of sets, matrices, stochastic and probability, provide a great foundation for abstracting and considering IT complexity.

My take-away from the examples of successful web sites is that they have one great attribute: solving one problem at a time. The trick is that, as they solve one problem, they learn and discover new unanticipated solutions and they can leverage that immediately in the resolution of the next problem. The result is that these endeavours end up achieving success in lots of areas that they never imagined when they started, that is the second great attribute. There are certainly more great attributes, and no doubt plenty of shortcomings, but I live in “glass half full” land.

Examples?: Google started with search, Facebook was about college students, Twitter wanted people to catch up (in their breaks) on what their friends where doing. On a micro level, the examples are innumerable and would make this posting longer than necessary.

In my view, the attitude of, solving one problem at a time, is applied to all aspects of the endeavour, not just technical.

The combined effect of the solving one problem at a time attitude, and the two great attributes cited earlier, embody the following tacit admissions:

  1. nobody is perfect,
  2. an organisation, just like a person, will never be perfect,
  3. it is wasteful to attempt to control everything from the get go, change occurs at a faster pace than our inventory and learning process
  4. we know what we want, but we never know where the events might lead to.

This type of discovery and progressive enhancement is not witnessed in enterprise systems environments, simply because it’s being preempted by stubborn short-sightedness and often times by analysis-paralysis.

With enterprise systems we insist in having a complete oversight before building things, but without knowing it we keep missing important pieces all the way and all the time, from start to finish.

There’s a paradox here: in the frantic attempt to achieve complete and total oversight, we become short-sighted and fail to notice numerous key signals. The signals take an inordinate amount of forms and they are well grounded in the context: business context, organisational complexity (human nature, entrenched interests, etc), technical complexity (how we fail to design and code what we are really thinking/imagining, how we fail to grasp the technology for what it really is), our span of control, our span of attention, the target solution lifespan, the limits of collective wisdom, etc, the list is endless. In my interpretation, a huge array of overlooked problems stem from human organisation shortcomings, by far the most insidious and  difficult to master: things like feeling, fear and uncertainty about one’s position or career, attention deficit, unexposed incompetence and mediocrity in the ranks, etc.

If we learned anything about architecture, we should know that it’s impossible to make an exhaustive list of every single factor that could become a part of the problem or the solution. If we can’t identify all potential problems and potential solutions, how can we possibly build something that caters for everything (which is what Enterprise System is supposed to be, a system that addresses all)?

We might be able to make a very good list at the start, things change as we list them. Say we overcome that hurdle, we usually don’t have sufficient control over everything in that list to be successful. If we manage to get sufficiently extensive control, there is still the hurdle of exerting such immense control for the length of time that it takes to build everything that is necessary. Say that miracles exist and that we manage to cross that last hurdle also successfully, then unless every stakeholder (internal and external) could be robotically piloted to perfection some things will go amiss.

At this point you might think I’m exaggerating the challenges, I probably am for many cases for sure. But if I were to underplay the hurdles, that also would not be the honest true because any one of the cited area of challenge can take a life of its own unbeknownst to or beyond the control of IT management. When such devastating change occurs, we enter another phase: denial for the sake of our own survival (the lies that cover the mother of all lies). That is a key aspect I want to point out. Christopher Alexander‘s seminal books provide a good background on the complexity of getting designs right (design in an extremely wide sense of the term).

There’s one more paradox: we are all quick to admit that “nobody is perfect”, we also know that an organisation is also a “body” and is a reflection of the humans that comprise it, yet we still think that we can build a “perfect organisation” (be it a project, an IT, a business, a program, a solution, or whatever structure or impersonation we give to our organisations).

The short-sightedness with Enterprise Systems is the result of insufficiently applying learnings, which is unfortunate since we really have plenty of opportunity to learn. Take any industry or knowledge domain that we love to paraphrase in our enterprise system endeavors, they all learn and apply knowledge incrementally. We’re the only ones, the IT industry, who think that we can learn everything and apply it all in one go. Our mistakes start to accrue in the problem and solution scope inventory phase: a lot of unaccounted for biases are introduced as we seek to segregate the invariants from the variable elements of the enterprise systems. From there we just keep compounding blind spots, until someone eventually pulls the plugs or that the project collapse under the sheer weight of the endeavour.

If we can’t get control over everything that matters before building successful enterprise systems, should we give up trying and forego all central control?

I’m not suggesting that we forego control and planning, that would imply that I know the magical answer, which I don’t and won’t ever claim to. I too, like many in my profession, am in my quest for the nirvana and I’m under no illusion that it exist or is achievable. And that last point is a suggested take-away: keep dreaming and reaching for the nirvana, but be aware that you might never achieve it.

At the beginning of this post, I cited one behaviour and two attributes, as expressing my take-away from what makes some web sites successful. With this I will be first to admit my own limitations: I am interpreting things with my own background and influences, someone else could have other equally plausible biases. The reader is entitled to his/her own bias. The important message is that we should learn to read signals and adjust our actions accordingly, achieving total control is rarely feasible or even desirable.

The odd saying goes like this: ” a fool with a tool is still a fool”. I’d fancy a positive version of it, glass half full type, like this: “a smart with a tool is a super smart”. In my experience, aptitude should be matched with an equal measure of attitude, they’re both in limited supply and should be consumed with moderation. Whenever the combination lacks of balance, failure looms. There’s a lot of preaching the good message, there’s far fewer demonstrable examples of doing it successfully. The range of tools and methods are wildly varied and have evolved tremendously over time. What’s remained virtually constant is the involvement of human organisations. Success still remains by and large elusive. Anyone claiming to have all the answers is definitely deluding. Awareness is the starting point, then actively doing something with the learning is the only essential positive ingredient.

I’d appreciate any learning from you, if you care to share.

Doing Things Half Right for Better Results, a little story.

In this post, I intend to share a learning point drawn from my personal experience, as you might recall if you’ve been following my tweets. I would appreciate any comments you might have. If you would share your own experience, that would be wonderful. I have reopened the blog for comments, the threat of spams having been largely contained by recent WordPress updates.

For a start, I should clarify what the title means: this discussion is really about intentionally half-baking solutions with the purpose of encouraging people to take ownership. It is about leaving room for someone else to blossom. To give another analogy, my local supermarket sells half-baked bread, when put in the over at home you get a deliciously fresh bread that gives you the illusion that you made it yourself. This post is not about doing a bad job, it is not about hiding behind excuses or avoiding getting one’s your job properly. This is about a good leadership practice when success depends on people taking onwership of parts or parcel of an initiative or a project. I hope this clears any potential misunderstandings.

Now, I would like to give you a taste for my personal experience, trying my best to keep it anonymous and neutral. I’ve boiled it down to one example, to keep the text focused and prevent any direct link with specific events and people.

In the early days of my carrier, I had the impression that I needed to have anwers to any technical question that came my way. I couldn’t help it. I would feverishly research and prototype technical solutions, work long hours to find answers that I could show to my colleagues (I still research as thoroughly as I can, but I’ve just learned to work better on the communication side of the equation). I thought that was the only sure way to gain respect and recognition amongst my peers, my reportees and my managers alike. I thought it could be damaging to my career if I failed to demonstrate knowledge and proficiency in technical matters This attitude served me well whenever I was directly responsible for designing or programming a solution, I could just show off my abilities quite easily.

At some stage though, as I got more and more project responsibilities, I was often annoyed to see that I sometimes failed to get sufficient support for my ideas even though I had checked everything and thought I had good answers. This was even more puzzling and frustrating when, in a leadership position, i would get the impression that people were simply ignoring me or refusing to see the light. Worse!, I had the impression that some managers were prepared to steal my ideas but seldom prepared to empower me, oh the outrage such feelings gave me!

Then one day, something happened that taught me a lesson: someone (higher up in the pecking order than me), rephrased and presented several ideas of mine, in my presence, without giving me credit (I had presented him my ideas and he rejected them). I was boiling during the whole presentation, but somehow I managed to stay calm and showed no emotions throughout. At the end of it I simply left the room and made no comments to anyone about the subject. The presentation was well received, the person in question did not dwell on it. I was so upset that I had the worse of thoughts for this person and didn’t wish to have anything to do with him again, if I could help it. A couple of weeks later though, as I ran into this person at the coffee machine he simply congratulated me on my contribution and left. It was clear that he knew how I felt, I took it as an indirect apology, but didn’t make much of it as I had moved on. The episode made me ponder a bit however, I realised that I would rather be associated with a success story than staunchly defend some bragging rights. This accidental epiphany would serve me again and again later on, as I stepped into leadership roles and I often worked with bright people. I tried to remember my story and control my instinct for bragging about, something that is generally against nature for technically inclined folks.

I had spotted a learning pattern that I have been trying to nurture ever since: to successfully collaborate with people, particularly in a leadership position, it is good to try and show humility and give others some room to grow. Nobody wants a superman-like figure around, especially when he (or she) is the boss. Appearing to have all the answers (or a lot of it) can easily breed resistance and cause projects to fail, if only because other people could be overshadowed and would have no motivation to take any ownership.

Despite what one might think, it is always beneficial to hear other people’s perspectives on issues. When I got humbled the way I did, it also made me realise that I had always thought people have a lot more potential than they give themselves (or are given) credit for. In my urge to try and grow, I was often loosing sight of my own belief and surely would not be able to lead had I continued on that path. I had learned to change in an accidental shock therapy.

If you manage technically savvy people, one of the things you learn is that unless you gain their respect you can’t effectively lead people. To gain their respect, you often have to have demonstrable superior technical ability. In any case, you have to allow them to express themselves as freely as possible, you have to pay more attention to egos as people take pride in what they do. The matter becomes more complicated if you are a consultant and that you are trying to demonstrate your abilities to your client stakeholder groups, conflicts can easily arise with the technical recipients of your work. When the recipients don’t buy your solution, it won’t add any value and your endeavour kind easily end up in failure.

The lessons I’ve learned:

  • Do not be afraid to see some of your ideas “getting stolen”, at the end of the day it is better to be part of a success than otherwise
  • Even if, as a leader, you can bring about all the answers that are needed, doing that would be a show of poor leadership and a demonstration of a lack of delegation skill
  • In a technical leadership position, it helps to be comfortable in giving others some space to grow. This doesn’t threaten a leader’s position, on the contrary the leader gains more respect from others, others would more easily take ownership

Credit & disclaimer:

This blog post was inspired by an article I read on HBR by Peter Bregman, under the title Why Doing Things Half Right Gives You the Best Results, http://bit.ly/31DI. I wouldn’t be telling this story, had I not read this article.

I tried to keep this discussion as general as possible. Should the reader recognise any event or people or any particular situation in this text, that would be entirely fortuitous and a simple demonstration that nothing is really unique under this sun: it’s all been done before, I’m just one guy talking about something that happens regularly everywhere. So there should be no surprise there.