Jimako’s Blog

 

 

There’s something fundamentally broken with the whole software development industry. And no, I am not talking about the process of creating software itself. I am talking about the way we interface with the rest of the business world, the way we are perceived and the crazy expectations that are placed upon us.

If I see one more "design" that has been done by a design house, or a usability consultant, or an interaction designer, I swear I will scream.

Look, people. You can’t design something if you don’t know anything about how it might be implemented. I’ve sat in on meeting after meeting where a design consultant or an interaction designer, with a perfectly straight face, told a client that the designs they produce are "not constrained by the technology" so that they are able to create "the best possible experience" or "have the most impact" or whatever buzz-words are current.

Really?

How great is your design if it can’t actually be implemented? The design is not the end product. It is simply a tool that has just one objective: to move us towards the actual product. I don’t really like analogies (even though I seem to be using a lot of them on this blog), but here’s another one for you. 

If you commissioned a design for a building, would you accept a design that had not done the basic calculations about whether it could actually be built? A disclaimer along the lines of "we don’t consider actual material load capacities as we don’t want our design constrained by the technology" would immediately be recognised as absurd. While that massive open auditorium looks great in the design, the builders will actually need to put lots of pillars at various places to support the roof. And the builder (even in consultation with the building owner) will probably not really be able to optimise the placement of those pillars to optimise the viewing angles, accoustics and seating capacity of the auditorium.

In reality, the design firm did no design at all. They abdicated the hard design decisions and left them for the builders and the owner. What they did do is create an unrealistic expectation about what is possible, and used a whole lot of the time and dollar budget of the project. And because it’s an "artistic" exercise, I will bet you dollars to donuts that it took much longer and cost much more than was originally estimated. After all, you can’t do "design" to a timetable — creativity marches to its own beat.

Recently I’ve been involved in a project where a major usability firm produced what they called a functional specification. What it actually turned out to be was a thin document about how various workshops had been run, a few JPGs showing mocked-up screens obviously created in Powerpoint (their IDE of choice) and a spreadsheet that was to be considered a data dictionary. The client had requested that the design firm provide them with the HTML for the interface so that it could be used as a template for the working system. What the provided was a set of HTML pages that contained exactly one image each — yes, you guessed it, the JPGs already mentioned.

The system was to provide a browser-based UI to a legacy back-end system. The UI was designed to streamline the workflow so that users would be able to use the system without extensive training, even if they only accessed it intermittently and at wide intervals. It was a thing of beauty.

It’s a real pity that the new UI needed data elements and processing logic that the back-end system just doesn’t have — after all, that’s just a technology detail. Or the screen that requires 4 different calls to very slow web services per displayed row and so takes several minutes before it can be rendered — surely "the technology people" can just make it faster.

And the icing on the cake? Even though the "construction" of the software didn’t start until several months after it was scheduled (because, as is so often the case, the design took longer than expected), the delivery date couldn’t slip, because commitments had been made to the powers that be. Couldn’t we just compress the timeframes for this last little bit?

AAARRRGGHHH!!!

Let me be very clear.

Software development is NOT a construction activity. We are REALLY, REALLY efficient in constructing software. It’s called a build, and even with full automated regression testing and QA, it takes minutes to hours to do. That’s it — period. Construction is so cheap and easy that it is essentially free.

Software development is actually a design activity. 

It starts out by doing a high-level design, mapping out the major components and identifying the technology stack and supporting ecosystem of tools and libraries. It then works at different levels of abstraction and granularity, generally from more general and broad to more specific and focused, but often diving deep into the details of particular areas that are considered tricky or high risk. 

The most detailed level of design is done in a programming language, whether a standard language like C#, Java or Ruby, or a Domain Specific Language (or DSL) specifically crafted to support the particular problem domain — I consider Ruby on Rails an example of the latter even though it is technically a Ruby framework and not a separate language.

As all this design is going on, situations are uncovered that likely nobody had considered before. These edge-cases need business input, and sometimes they force quite significant redesign of the entire system. They can be encountered at any time, but in most cases they are only uncovered by the act of writing the code. 

A developer gets to a point where she types "else" and then looks blankly at the screen, totally at a loss as to how to handle that case. It had literally not occurred to anyone that this was a possible combination of the various system states and inputs. It is not that someone had "failed" in the design phase, it’s just that we only now got to a sufficiently detailed level of design that the situation became discernable.

And the answer is not more high-level design up front. At the end of the day, you need to get to the absolutely most fine-grained level of detail to fully flesh out a design, and that’s what coding is all about. When a developer is working at a high level, she is coding using a handful of basic constructs (like sequence, selection and iteration) to control a bunch of what are often as-yet unwritten code blobs (whether these blobs are objects or procedures is irrelevant). When she is working at the detail level, she is focusing on writing specific data to the database, handling specific input values from the screen, performing an actual calculation or transformation on some data items. And throughout a typical work day, she will switch between these two extremes and countless intermediate levels many times.

This is the type of design that is required to deliver a functioning system. Design is code and code is design. "Design" using a design tool is simply using a different notation to do the same thing, except that notation can’t express the most detailed levels of design in a clear and unambiguous manner. I say that confidently because if it COULD do those things, then by definition it would be a programming language, the ultimate design tool.

So, how does a smart company manage a software development project? Here’s how I would do it.

First, don’t commit to a delivery date yet. How can any date you put forward make any sense at all? Wait until you have more data. Get approval for a high-level design project only.

Now, don’t spend your budget on a consultant who is not going to be part of the final delivery. If I don’t have to worry about delivery, I can put anything into a Word document. Instead, find a technology partner that you can trust, and get that partner to gather all the required skills for you.

You see, I am not discounting the value of interaction or interface design — in fact, I think that good design of these aspects is often the difference between a barely usable application and an outstanding success. It’s just that I think that they need to report to both the business and the team charged with implementation, so that the designs meet the business requirements and can in fact be built.

So, how do you find a technology partner you can trust? It’s actually a lot simpler than you think, but it is not easy to do in most large enterprises. The way you do it is the way you would select any craftsman. By all means look at what they have done (in the guise of references and recommendations); after all, you need to ensure that they have some record of success. But the number one factor you need to consider is this: do they understand what you are trying to do and are you confident that they will work with you to make it happen? Talk to the people you will be working with. Insist on this — talking to the sales guy is worse than useless: it is dangerous as you’ll be told what you would like to hear rather than the truth.

Also, I would not lock in a long-term contract. Instead, I would engage them on a month-to-month basis so that I could terminate our arrangement if it wasn’t working out, if they tried to slip in a bunch of juniors, or simply stopped paying me attention. The flip side is that they could also fire me if I was becoming unreasonable. It’s amazing how focused both sides become when they need to work at preserving the relationship.

Then, as the initial design starts to firm up (including the interaction and interface design), I would be seeking from the technology partner and indication of the expected time to implement. Don’t impose a level of precision on them at this stage — it doesn’t work like that. If you’ve just managed to pin down the scope of the project and have a bunch of wireframes to look at, asking for a +/- 10% estimate is totally unrealistic. 

Yes, you would like that level of precision but no, you can’t actually have it. In reality, at that stage, the highest possible level of precision is one close order of magnitude (that is, one power of 2, or +100%/-50%). And that’s the best possible case. It’s not until much later in the project, typically when the majority of the coding is done and the users are getting a chance to play with it that we are able to have a precision as high as 10%.

For budget purposes, get approval for some of the work, and use an iterative development process (typically, some form of agile methodology) to deliver some of the highest-value functionality.

Lather – Rinse – Repeat.

As time goes on, both the business and the technology partner get a feel for the complexities or otherwise of the various parts of the solution, and the quantum of functionality that can be delivered for a given time and dollar investment.

And if you find that your technology partner is dropping the ball, then change them! Changing is not free — there will be some down time, and the replacement will need some time to come up to speed, but at least you have the option to do so. Just make sure that all the build artifacts are yours — the source code repository, the build system, the testing infrastructure, the "stories" or equivalent documentation.

Of course, this actually is almost impossible to do in a large enterprise. Management wants firm and precise estimates for budgeting purposes, and can’t understand why they can’t get them. The perception is that software development folks are just refusing to play by the rules, that they just don’t want to make a commitment. 

I just don’t know how to get the message across. Asking a software development team (or for that matter an individual) to provide estimates based on the broad and often internally contradictory wish-list of functionality that is titled a Request For Tender is a bit like going to a builder and asking for a quote for "a building that will have between 20 and 200 stories and will be built on a location as yet to be determined". It just doesn’t work that way in the real world, and software development is orders of magnitude more complex than constructing a building, even if it is less physically demanding.

I would like to think that we are getting better at developing software. I actually think that we are. What we are failing at abysmally is getting our customers to understand the reality of what we do and work with us in their best interests. They’ve been burnt too many times by the smooth-talking consulting organisations who promise the world and will agree to the most rediculous engagement terms just to get in with a client, relying on lock-in to keep them there.

And you know what? At the end of the day, these consulting firms get away with this behaviour because the clients let them. I’ve lost lots of work when I gave a client an honest estimate of the work, saying that I estimated it at between 9 and 15 team months when a competitor agreed to the client’s "estimate" of 3 months. Two full years later, the project is still not completed and the client has spent far more than was originally planned. The winner here? The competitor has been paid for a team of developers for the whole two years. I won’t name the competitor, but it is a big name, multi-national consulting organisation that you have definitely heard of. Whose fault is it? I would suggest that the client got what they deserved.

If someone is telling you what you exactly want to hear, maybe you should tread with caution.

 

No comments

Just a few minutes ago, while I was out at lunch, someone left the following comment on the last post. I was about to delete it but thought better of that action. I did not approve it (as it really does not relate to the post at all) but let me copy and paste it here in all its glory:

Author : Ioustinianos (IP: 85.195.123.22 , 85.195.123.22)
E-mail : yourdeath2007@gmail.com
Comment:
You bloated GREEDY sATAN worshiping slothful PIG !
Is that all you can think about you disgusting blemish in the sight of Christ Yashua ?!

You filthy slimy sleazy scumbag , you are a member of that sATANIC jEW club for your own material gain.

Money money money ! You sick sick man , do you know what you are getting yourself into ?

OK. Extremely insightful comment, that. I assume the commenter is referring to my membership in a Masonic Lodge, something that I not only do not hide but of which I am very proud — indeed a quick look at even the front page of my web site brings up that information.

So, what exactly is this person criticising? What is he (or I guess possibly she, although I doubt it) actually complaining about?

Do me a favour, read the previous post first. You will see that I pose the question: if you want to develop some software that can be provided as a service, what would that be? So this person fires back with:

You bloated GREEDY sATAN worshiping slothful PIG !

Ummm. OK. Let’s leave the “sATAN” worshiping part out of it for the moment. Bloated? Greedy? Slothful? Pig? What is this based on? I work hard — have done so all my adult life. I have not been handed anything on a plate; my parents were poor immigrants who worked for minimum wage so that they could afford to support my sister and me through school. I am married with 3 kids, all in school, and so I of necessity need to work to support them and myself. Greedy? I live in an average suburb. I drive a 15-year-old car. Slothful? I work well over 50 hours each week (while on a salary, so no overtime) and I do at least 10 hours of community and charity work each week too.

Is that all you can think about you disgusting blemish in the sight of Christ Yashua ?!

No that is NOT all that I can think about — if it was I would be rich.

Look, anyone can be rich if that is truly the top priority in his life. I don’t want to be rich badly enough to do what it takes. There are other aspects to my life that are far more important to me than mere money or material possessions: my family’s welfare and health, their happiness and well-being, the effect I have on my community and my world. All these things are truly important to me.

I need to be able to be satisfied with an honest answer to this question each and every night before I go to bed: Is every person I came into contact with today better, or at least happier, as a result? If the answer is no, then I have failed to live up to the yardstick that I have set for myself.

Making money is not how I measure my worth or my success. Of course, I do need to make enough so that I can offer my family a reasonable level of comfort and security, but beyond that it just doesn’t matter enough. What the previous blog post was referring to was a feeling that it is time to build a recurring income stream that can free up some time to enable me to become involved in some major, long-term projects that will actually cost me money but which I think will benefit many of the most needy people in my community. I can’t tackle them without sufficient time and funds. That is what this is about, not some desire to be rich. Heck, I am rich in so many ways: I have my health, a loving family, a roof over our heads and enough to eat and stay warm. I don’t need anything more. I don’t want anything more. So this comment:

Money money money ! You sick sick man , do you know what you are getting yourself into ?

well, I’ll just leave that alone.

Now, let’s get back to Freemasonry. The writer uses these terms:

… sATAN worshiping slothful PIG !

… you disgusting blemish in the sight of Christ Yashua

… member of that sATANIC jEW club

… for your own material gain

… do you know what you are getting yourself into ?

Caps-lock-induced dyslexia aside, Satan-worshiping? Satanic Jew Club? Come on now, does anyone still buy into this claptrap? I am not going to go over all this again, not because I can’t but because it has been done so many times before. Look, check out these pages on our own Lodge web site for a starting point, and if you have any sane questions please ask them here (or better yet, phone your nearest lodge and talk to someone — this “secret society” is in the phone book, so they aren’t that secretive!).

For the record, I am a Christian. Many of my brothers are Jewish. Many others are Muslim. A few I know who are Hindu. It doesn’t matter — we are all equal brothers, work together in harmony for the good of our broader community without trying to convert each other. Does this unsettle the commenter? Why? Maybe a little introspection is called for here.

As for my “own material gain”, anyone who knows anything about Freemasonry (or anyone who actually knows a Freemason) will know that being a Freemason costs a man both in terms of time and in money — just ask my wife! There is no other way to put it: if you thought you were going to gain materially from joining Freemasonry, you were very, very wrong. Many times throughout the joining process, each potential and recent member is forcibly reminded of that fact and admonished that seeking personal advantage from membership is not only frowned upon but can lead to discipline, punishment and even expulsion.

So why am I a member of a Freemasons’ Lodge?

Simple: because I was a Freemason in my soul first. Whether by nature or nurture, I fundamentally believe that there is an absolute concept of good and evil, and men know in their innermost being how to recognise it. I believe that good men are good regardless of their religious persuasion. I believe that tolerance, open communication and cooperation are a good and proper way to interact with others. I believe that I have an obligation to render myself of service to the world around me, and that in doing so I am acting in accord with the will of the Divine (whatever name each individual wants to use).

I believe — no, I know — that what I have become by being a member of a Lodge, and the continuing process of personal development and growth, makes me a better father, a better husband, a better employee, a better workmate, a better friend, a better citizen… a better man.

If I didn’t know that, if I didn’t believe it deep where I live, then I would not still be a member after nearly 25 years.

So, let me turn the last quote on the commenter. When you ask me:

do you know what you are getting yourself into ?

I can answer you with a clear, confident and categorical YES.

Do you know anything about this subject at all?

Hopefully, this post will help, although there is a Greek saying that goes like this:

On a deaf man’s door, you can knock forever!

which I suspect is appropriate here.

2 comments

I’m a big fan of Ruby, the language.

I’m really impressed with the potential of the Rails framework (although to be honest there seems to be a lot of voodoo going on behind the scenes, which is probably just an indication that I have not yet done enough with this framework to be comfortable with it).

But there is no denying the reality that, for most of us, adopting Ruby and RoR is not a simple decision, because we already have code that has been developed atop a Java web stack.

If we are looking at a new project, and there is some ability to absorb the risk of going with a new technology stack, I would be the first to suggest that RoR be given serious consideration. On the other hand, if we are involved in the on-going development of a Java web application that has been going on for several years, does it make sense to try to integrate a new stack into the mix?

Let me set some parameters. You have a successful product that is continually being improved. Using “best practices” (I’ll come back to that term in another post), the application has been developed using an MVC framework — let’s say Struts, JSP and Hibernate as a concrete and all-too-common example.

Now, we want to make some changes as a result of customer feedback. Typically, these changes are either new features or modules, or else changes to the existing functionality.

Changes to the existing functionality are hard to do in any other technology. Sure, if the changes are broad enough, it might make sense to redevelop one or more modules from scratch; in that case, of course, we can treat it the same way we would treat the development of a new feature.

So, for a new feature, what alternatives do we have?

We can certainly continue on with our existing technology stack. In many ways, this is the low-risk option, because we know the technology. We know the tool-sets, we have knowledge within our development team, and we have historical data about how quickly we can do things using that technology. And let’s not forget that the stack itself is well-proven, because we (and countless others) have deployed applications on that stack and we know how the stack scales, how it deploys, how it responds to machine and network resource allocations. There is a lot of value to maturity.

But is it really a low-risk option? What if the development velocity is not fast enough? Sure, we have good predictability, but if our predictions are that we can’t do it as quickly as we need to in order to satisfy the customer, or prevent the work being assigned off-shore, then surely persisting with that technology is in reality the high risk option.

And here’s the real issue. Java web development using the classic development stack is just not fast enough. I’ve heard the arguments — you need to do all the fancy plumbing and documentation / annotation so that the app scales and is flexible and maintainable when it gets hit by millions of users per minute. The reality, however, is that most applications never need that scalability, especially if they are not finished because application development is too slow.

So what do we do? Is there some way to incorporate some of the really rapid web application development techniques into an existing Java web application?

I think that we are at a difficult time in Java web development. We have a lot of systems that have been developed over a long time (“long” being relative to the rate of change of software development, of course). While these systems are often still in active enhancement, they are also in a very real sense legacy systems, built using tool sets, frameworks and architectures that, well, seemed like a good idea at the time. Looking back at what we have done, and also looking at all the shining new toys all the new kids are playing with that show just how much faster web application development can be, we can’t help but feel frustrated and itchy to do something, well, different.

At the same time, we have some interesting things “just around the corner” in the Java space. But we need something we can use right now.

I see JRuby is coming along in leaps and bounds. This is an implementation of the Ruby language for the Java Virtual Machine. It is almost at the point that it can run Rails applications. However, I don’t see a clean way to do new-feature development for an existing web application using Rails, even if it is on the JVM. Another very nice dynamic language, Python, has a JVM implementation in Jython, but this is languishing and seems to have been largely orphaned when its initial developer switched focus to IronPython, which is an implementation for the .NET platform.

Groovy is coming along nicely, but slowly. It is likely to be an “official” scripting language as a result of having a JSR. Also, it has a Java-like syntax, which means that there is a shorter pick-up time required for Java developers.

If I thought that language is the limiting factor, then I would look at Groovy because it has a lot of the syntactical conveniences of the popular scripting languages with full access to existing objects that have been coded in Java (including the Java libraries).

However, while I think Java can be too wordy, requiring lots of boilerplate code in some circumstances, I am not at all convinced that this is the major reason that web development in Java is too slow.

In reality, I think that the real reason web development in Java is too slow is that we are making it too complicated. The real reason that frameworks like RoR are so incredibly productive, in my opinion, are more related to the use of very simple ORM designs like ActiveRecord, and the Convention over Configuration philosophy.

Sure, Hibernate is REALLY powerful. But it is not ideal for all sorts of database access, at least not when used naively. Sometimes, a simple SQL query, processed as JBOF (Just a Bunch Of Fields, and yes, I did just make that up) is totally appropriate.

Consider for example presenting a user with a filtered, paged list of widgets. In the prehistoric era of web development (that is, about 8 years ago, and using VB6 COM behind IIS/ASP) I designed a relatively simple, generic technique. I created an SQL statement by putting together the WHERE clause dynamically. I then did a SELECT statement, retrieving only the IDs that matched the criteria. IDs were just 32 bits each, so even a million of the suckers was just 4M — most lists were a few hundred to a (very) few thousand rows. I just stuck them in an array and stuffed them into the session. Then, paging was simple: just calculate the array indexes that correspond to the desired page, create an SQL statement that retrieves only the ID and the columns required for the list display (using an SQL WHERE ID IN … statement) and displayed the list. All this is totally generic, it scales REALLY well, and has not let us down after years of very heavy use in the field.

More recently, and in the Java world, we end up retrieving lists of objects. We rely on Hibernate or the ORM de jour to do magic, multi-level caching and lazy object instantiation and hope that it all works. And then we dump the list into some magic JSP taglib that does sorting in memory. And when the list gets to a few hundred items, the list takes MINUTES to display, and customers are unhappy, and developers say “you didn’t specify performance criteria”, and analysts say “but of course it has to handle more than a dozen items in a list”, and you need to divert resources to do major investigation and refactoring or redevelopment, and you start to think that things are not meant to be this hard.

In business application development, the needs of the application for data access are not complex. We need to get filtered lists of items, then we need to get complete individual items. That’s pretty much it, and that’s what DATABASE servers do — we should let them do their job and not try to replicate that in the application. Updating is only a little more complex.

The other lesson that we can learn from RoR is that we seriously need to tame the configuration frenzy that Struts brings. I need more time to think about this, but I think that a good way to begin simplifying this in an existing product is to add a single Struts action that further parses the request URI and uses some convention to identify the class and method that should handle it. That class could be written in Java, or any of the new, JVM-hosted scripting languages. Do it well, and write a suitable class loader, and you could even hot-deploy a URI request handler class or JAR file.

The reason that I am considering this is not because I don’t want to use an existing framework like Ruby on Rails (or for that matter Grails, Turbogears or Django). It’s that I need to be able to integrate whatever framework we use into the application as it exists so far, and everything I see (and my gut instinct) tells me that these frameworks are good for new projects but are likely to be a bitch to configure and integrate with a Java/Struts/JSP stack.

I have not yet clarified my own thinking about all this, but I wanted to post it to get some feedback. What do others think? Am I alone in thinking that we are making Java web development harder than it needs to be?

No comments

… then it’s the map that is wrong.

Last week, my son went for an interview for entry into one of the top academic high schools in this state, and I needed to kill a couple of hours. I therefore went into a local Borders bookshop, grabbed a book almost at random and sat down with it in the embedded Gloria Jean’s with a cup of coffee. I don’t even remember the name of the book; it was something like "30 Things You Need To Know Right Now". What has stuck in my mind is the first of these "things".

If the ground doesn’t correspond to the map, then it’s the map that is wrong.

Sounds simple, doesn’t it?

I must admit that I didn’t read much past that opening chapter heading, because I had one of those "Aha" moments (or more like one of thise "D’oh" moments, I guess).

Everyone today seems to have a preferred point of view about how the world works. Based on that view, plans are drawn out that attempt to map out what we will do and the outcomes that we expect. I admit to having a particular issue in mind here — the issue of "professional managers" that I have blogged about before, and I will use this issue as an example — but the observations that I am making are more generally applicable.

Let me go through a concrete example here. As I have already documented, I believe that a technical activity like software development cannot be managed by a generalist manager. But my view is not universally subscribed to — shocking, I know, but not everyone agrees with my every view, at least not yet, although I continue to work on it.

So in a particular workplace that I am familiar with, despite my view, there has been a definite move over the past several months away from using managers with a technical background and towards employing generalist managers, people who are in fact actively TRYING to remain non-technical, and believe that major software development projects should be managed in the abstract using general project management techniques.

For a while, I have been trying to argue against this policy, and several others have voiced concerns as well. But this single statement hit me like a cricket bat over the head.

If the ground doesn’t correspond to the map, then it’s the map that is wrong.

I don’t need to argue the view on a "first principles" or "logical" basis. I simply need to look at what is happening in the real world.

In other words, I need to stop focusing on the map and look at the ground.

You see, there are a few very clear indicators about the health of a software development project, and they can be measured reasonably easily. Those indicators are not universal, as every human endeavour is a trade-off between competing requirements. But for any given project, there is a specific range of settings on the various axes that we are aiming for, and we can usually gauge how we are tracking.

So if we are aiming for high quality, then we can look at defect rates. If speed of delivery is our focus, then we can look at function points delivered per release. If we are looking at long term project sustainability, then developer satisfaction and retention rates (or, inversely, dissatisfaction and staff turnover) can be examined. If we are concerned with customer satisfaction, we can ask the customer for subjective or objective feedback.

If we look at what data we have "before" (that is, with technical managers) and "after" (with generalist managers), we can see which set of conditions moves us closer to our desired outcomes. And if one of them is significantly closer to the way we want to be, then all the arguments and logic about which management strategy is best become irrelevant. It’s like arguing about which map is more correct without looking at the ground. The correct answer can be determined quite unambiguously by comparing the maps to the ground.

Similarly, if we look at the health of the project, using whatever parameters we want to define health, under the two management styles, we should be able to discern which of the styles is better in this context.

Now, let me be the first to admit that this metric will only look at the relative performance of the particular individuals involved, and on the project under examination, and a single set of observations like this cannot be extrapolated safely to the broader project management landscape. However, I am really interested in just this one particular set of variables, so that’s perfectly OK.

I would be interested, however, in collating more information from a number of different projects that have tried both management types to see if there is any commonality. With enough separate data points, we might well be able to draw some generally applicable conclusions.

Feel free to leave any anecdotal data in the comments.

No comments

Why do some people just find it hard to admit they’ve made a mistake? We all do it — heaven knows I have, on many occasions and in many contexts. Yet for some reason, there are those amongst us who feel that any suggestion that they made an error needs to be shouted down forcefully lest they be stigmatised as failures.

A mistake is not a failure. A mistake is an opportunity to learn, to grow, to re-focus, to improve. It reminds us that we are not infallible, and injects a little humility into our souls.

The failure is in not heeding the message that the mistake is trying to convey. Cosmic karma is at work here. The universe starts with a gentle tap on the shoulder trying to get your attention. If that doesn’t work, then a rap across the knuckles comes along, followed by a clip behind the ear. Pay attention to what you are being told, because if you ignore all of these, then the speeding truck is on its way.

I have yet to see a more effective way of dealing with a mistake than simply admitting to it, apologising sincerely to those impacted by it, and thinking about why it happened and what lessons need to be learnt. Not only is this in keeping with the natural operation of the universe, it builds your own moral fibre, and earns you respect from those around you.

Pointing fingers at others, reaching for a scapegoat, making excuses, or just plain claiming you make no more mistakes than others do just doesn’t cut it — not only do you come across to others as someone who lacks integrity, you train your mind to react inappropriately and get further out of sync with the world around.

And that is not where you want to be.

No comments

I just read the latest article by Joel Spolsky over on Joel on Software (a site you really should bookmark). Joel reminisces about the time he had his First BillG Interview where he had to present the spec for what was going to be Visual Basic for Applications to Bill Gates. It’s a good read, and Joel’s writing style is very entertaining. While Joel and I have differing opinions on some things, I certainly respect his experience and knowledge, and I suspect that the things we disagree about are simply related to the fact that he takes some concepts too literally (especially with regards to such Agile concepts and no BDUF, but’s that’s for another post).

Towards the end of the post, Joel makes this observation:

Bill Gates was amazingly technical. He understood Variants, and COM objects, and IDispatch and why Automation is different than vtables and why this might lead to dual interfaces. He worried about date functions. He didn’t meddle in software if he trusted the people who were working on it, but you couldn’t bullshit him for a minute because he was a programmer. A real, actual, programmer.

Watching non-programmers trying to run software companies is like watching someone who doesn’t know how to surf trying to surf.

"It’s ok! I have great advisors standing on the shore telling me what to do!" they say, and then fall off the board, again and again. The standard cry of the MBA who believes that management is a generic function. Is Ballmer going to be another John Sculley, who nearly drove Apple into extinction because the board of directors thought that selling Pepsi was good preparation for running a computer company? The cult of the MBA likes to believe that you can run organizations that do things that you don’t understand.

Hear! Hear!

You know, it’s not that I don’t respect management as a discrete set of skills, a seperate discipline if you will. Managing anything successfully requires a particular mindset and approach that is quite specific to the task of management, and the actions that a manager does (and the skill required to carry them out effectively) are specific and distinct from those needed in other endeavours (like, oh, I don’t know… developing software, for example).

That does not mean, however, that those skills are all that a manager needs in order to be effective.

I guess it is theoretically a possibility that somewhere there is an activity that can be managed by someone who has no understanding about that activity. (I am not saying that there is such an activity, just that there might be.)

But developing software is not it.

It is simply not possible to manage a software development business without a reasonable understanding of software development. I am not going to try to justify that statement here, because quite frankly either you know that this is true, or you can’t possibly be convinced that it is. What I will say, after 28 years in this game, is that whenever I have had to work with a "manager" that does not understand software development, the end result has invariably been sub-optimal. And by "sub-optimal" I mean a disaster, except where this was avoided by those who did understand and who went far beyond what could be expected of them and worked around that manager to get things done.

While it is not necessary (indeed, it may not even be desirable) for a manager in a software business to be the most technically competent developer, it is an absolute requirement that he or she be able to understand if something is easy or hard, if it is high risk or low risk, if it is reasonable or unreasonable, if it is obviously wrong, obviously right, or just plain not known. He or she needs to understand whether an estimate is reasonable, or whether it is too optimistic or too conservative.

If the manager can’t do these things, then how can he or she manage? Can you imagine this scenario? If I were asked to manage a banana farm (an activity I know absolutely nothing about) then here is a conversation with the farm workers:

Me: The buyers want bananas that are more uniform in size. How can we do this?

Workers: You can’t. Bananas have a certain variation in size. Indeed, the particular species we grow is internationally recognised as the most uniform in size.

OK. Now what? Is this true? What do I do next?

Worse still, the previous day, in the meeting with the buyer, the conversation had gone like this:

Buyer: Our consumers are complaining about the variation in the size of the bananas. We need them to be far more uniform.

Me: Oh, I’m sure that is not going to be a problem. After all, we employ world best practice farming techniques. I am sure we can do something about that. So if we add a clause to that effect into the contract, you will sign an order today?

Buyer: Yes, but only if you can assure me you can have a smaller variation in the size.

Me: No problem. Sign here, please.

If this sounds ridiculous to you, welcome to my world…

1 comment