I’ve joined Google fairly recently after spending nearly a decade at MSFT, and I’m having to unlearn a ton of things I’ve learned at MSFT.

First, I had to unlearn that my opinion doesn’t mean shit. Engineers do, in fact, run Google, and I’m an engineer. A LOT depends on engineers here. Barely anything depends on the management or PMs. The comfortable, asphyxating bureaucracy of Microsoft simply does not exist. It is up to you to define the direction, and execute on it. If you’re good, you will also get other people to execute on it, by means of which you will establish yourself as a leader.

Second, I had to unlearn that my teammates are plotting something behind my back. As far as I can tell a few months in, they aren’t. Or they’re so skilled at it that I don’t see the plot (which after 10 years at MSFT is unlikely). They’re just building a product.

Third, there’s no “jihad” against anyone. Not even Microsoft. People are discouraged from thinking in those terms. No one is trying to “kill the fucking Microsoft”. No one is throwing chairs or calling Ballmer a pussy. People just build their products and services the best they can.

Fourth, there are very few people who can say “no” without motivating their answer with data. The first answer you will hear from anyone (including Legal!) is “yes”. It’s not blind acceptance or anarchy either, it is expected that you will motivate your changes, with data, if necessary. Want to change the way Google runs ads? If your change makes sense and you can demonstrate it, it will be accepted. Search? The same. This one is particularly hard to unlearn – after burying so many great (or at least I thought they were great) ideas because they weren’t _politically_ feasible, sometimes within the same extended team.

And so on and so forth. I wasn’t a bad performer at MS by any means (left the company 5 levels up from where I joined), and as a matter of fact I admire bits and pieces of Microsoft to this day, but Google made me realize just how miserable I was there. I don’t yet feel Google is the ideal place for me either, but one thing is clear – it’s much easier to breathe here, if you know what I mean.

When I wrote The Art of ‘Ware back in 1994, I came away from it with a greater appreciation of why Microsoft had achieved the success that it had. It appears that Microsoft has lost its way. ..bruce..

What is interesting about Holmgren’s hire is that it is modeled after Bill Parcells role at Miami – The Football Czar.  He’s not the head coach and he’s not the GM (who usually handles personnel).  Instead, he is something else.  It is a role that leverages his expertise as a position coach, a head coach and a GM.  One that sees the bigger picture and is able to evaluate players AND coaches from a fresh and more independent perspective.  It is a position created to drive the “rebuilding” of a program – something Miami and Cleveland badly need.  In Parcells’ case, he took an 1-15 team and got it into the playoffs the next year with an 11-5 record.  Part of the Parcells formula is to bring in a core of coaches and players that he trusts and who know his systems, both offensively and defensively.

Be sure to read Curran’s entire post, plus the robust debate in the comments that follow it.

Of course, Ruby and I also used the football analogy a few years ago in suggesting a radically different approach to IT organization and leadership. As we wrote:

The bad news is that, unlike in football, the business and IT sides of a firm don’t always agree on what constitutes a ‘victory’ (even though both sides can usually agree on what a ‘loss’ is, at least in cases of total or significant project failure). Indeed, sometimes they cannot fully agree on what the game is.

Curran’s IT Czar role could in theory solve that; I like his proposals and approach, and, of course, I like the sports team analogy.

The problem is, it’s hard to see how upper management would treat or perceive it as being any different from the current CIO role. Both as a consultant and as an expert witness, I’ve had lots of opportunity to see just how  constrained the CIO slot can be in large organizations. A lot of the blame for that rests squarely upon the CEO and other CxO leaders, both in terms of whom they select for the CIO job and how they define/constrain that job. CIOs tend to be selected from business-types with some technical background, as opposed to technical types with some business background. Curran’s analogy (e.g., Bill Parcells) suggests that the czar be someone who has been down in the trenches (e.g., position and head coach) and knows what day-to-day IT development requires, but that’s not who usually gets picked.

The closest model to an IT Czar that I’ve seen that has worked were the various corporate Y2K ‘czars’ who were appointed 10+ years ago to save the officers and directors from any Y2K liability, and thus were given lots of power and pretty free rein. (A joke from those times — Q: What’s the difference between a terrorist and a corporate Y2K director? A: You can negotiate with the terrorist.) An IT czar appointed to ‘turn around’ an organization’s IT efforts would have to be given that same power and freedom. That is not likely to happen unless, as with Y2K, the corporate officers and directors see themselves at risk — professionally, legally, financially and/or personally. Otherwise, as noted above, the “IT Czar” would be just another CIO.  ..bruce..

Each technology is on its own product lifecycle, which may or may not match with your organization’s business and development lifecycles. In particular, there are certain cycle mismatch patterns that commonly occur in organizations looking to adopt new technologies. I’ve labeled four such mismatch patterns: firefly, underdone, conveyer belt, and landfill. Each is worth examining.

Go read the whole thing.  ..bruce..

Now, and again courtesy of Rand Simberg, comes this brilliant video, made recently by frustrated workers within NASA to show how efforts to innovate and improve a troubled project (can you say “Ares”, boys and girls?)  get blocked by middle managers:

Simberg actually pointed to a post by Wayne Hale, a long-time NASA manager, on an official NASA website blog. Hale felt that many of these problems had already been addressed and was surprised (or Simberg put it, “shocked, shocked”) to find them still pervasive at NASA:

Recently I had a couple of events which affected my thinking on this.  I have been out of the Shuttle Program manager job for almost a year now and a trusted coworker just a week ago told me that people in his organization had been prevented from giving me important alternative choices for some program choices that occurred a couple of years ago.  This was staggering. It was happening right in front of me and I was totally unaware that people – who I trusted, who I hoped would trust me – kept their lips sealed because somebody in their middle management made it clear to them that speaking up would not be good.

Astounding.

About two weeks ago an activity that Mike Coats started at JSC had an all day report out period.  The Inclusion and Innovation Council was to propose ways to improve innovation at NASA.  Various teams reported out, including one team of young employees who has the task to talk about the barriers to innovation at NASA — specifically at JSC.

The video attached was their result.  I found it extraordinarily funny and not at all funny.  These young people have obviously found themselves in situations RECENTLY in which managers at various levels applied sociological and psychological pressures to keep them from bringing ideas forward.

I am convinced that if we asked the managers who were the models for this little morality play whether they stifled dissent or welcomed alternate opinions, they would respond that they were welcoming and encouraging.  Probably because they have that self image.

But actual behavior, not inaccurate self perception, is what we really need.

Watch the video, read Hale’s post, and then ask yourself: how many of these problems affect innovation and product development in both organizational and commercial IT development groups? ..bruce..

Here are what I see as being some of the core classic problems with a system such as this.

The “No Room for the Infrastructure” problem. While the elevated tracks are vastly cheaper and easier to construct than, say, corresponding subway tunnels, they still require above-ground space and a regular footprint at ground level. Most existing urban and even suburban areas simply don’t have the room available, either in the air or above the ground. The political and economic costs of purchasing such room (via eminent domain and other takings) would be prohibitive in most urban/suburban settings.  And while everything in the video looks clean, light, and airy, you simply need to spend a little time around most mass-transit stations to see how they act as magnets for vandalism, graffiti, and litter.

The Last Mile problem. Because of the room problem above, the ULTra network would not likely achieve much network density except in limited and constrained locations (such as an airport or a newly-constructed office park). In actual urban/suburban settings, ULTra would likely end up having a sparse network feeding into existing mass transit systems (subway, buses) or leaving you to walk the rest of the way. As such, it is unlikely to reduce car usage.

The Pay As You Go problem. Mass-transit systems are notorious money pits, heavily subsidized via unrelated taxes and federal subsidies (but I repeat myself), since actual rider fees are not enough to pay for the system’s on-going operations, much less the original cost of construction. My wife and I lived in the DC area for a total of nearly 8 years (six of which were in the District itself), and I was a great fan (and heavy user) of the DC Metro subways. But WMATA is always struggling financially, and that’s true of most mass transit systems. Here in Colorado, where we’ve lived for the last 3 1/2 years, the Denver Light Rail system found itself looking at cutting back services this year — due to reduced sales tax collections and higher fuel costs — even as rider volume was going up as gas prices passed $4/gallon.

The Hidden Costs problem. Somehow, much of the public discourse over (electric) mass transit assumes or implies that electricity is free, or at least carbon neutral. It’s neither. Most electrical generation in the United States comes from burning hydrocarbon-based fuels: coal, natural gas, and a bit of oil. And even if the electricity comes from wind, water, geothermal, solar or (my favorite) nuclear, it still costs money and it still has a carbon footprint.

The Scalability problem. Paul Raven, who blogged about ULTra over at Futurismic, raised this issue himself. The ULTra system shown in the video relies on relatively small cars — four seats each, with some standing/storage room between them — that are spaced apart by the controlling software. Assuming a spacing of 3 seconds between cars, that sets an upper limit of moving 4800 people/hour. This is better than, say, busses on a given route, but it’s less clear how competitive it is over existing train, light rail and subways systems, and it doesn’t begin to approach what the automotive infrastructure can carry.

The Coordination problem. One of the long-standing complaints about the automotive system is its high inefficiency, that is, you have millions of cars on the road, the overwhelming majority of which are carrying one or maybe two individuals. ULTra, by being demand-based, sets itself up for the same problem. If I read the video and website correctly, I can walk up and select an unused ULTra car, punching in my desired stop, and go straight there. By so doing, I may tie up an ULTra car all by myself, going from Point A to Point B. This reduces the overall capacity and efficiency of the system; to overcome that, I must then choose to announce my destination, interact with others (“Who else in going to [Destination X]?”), and decide who else I want getting into that rather small car with me. This leads to…

The Safety problem. Personal safety on mass transit is usually provided by the presence of other people; that is, you are less likely to be mugged or assaulted on a crowded subway car or bus due to the presence of all the other people around you. (Hence the classic drama/horror trope of being on a subway car with just one other, sinister-looking person on it.) Should I let another person into my ULTra car, presumably because that person is going to the same destination, I am then trapped alone with that person in that car all the way to that destination. I suspect there will be a “let me off at the next possible stop” button in the car, but that may not be enough. Likewise, there will likely be an inboard camera, but a second or two of spray paint will take car of that. On a less dramatic note, vandalism of the interior of the cars themselves will likely be increased  for that same reason of isolation (no one around to see what you do to the car).

OK, that’s what I came up with on the top of my head. Can you think of others, or do you have counter-arguments to what I’ve listed above?

Again, I’m a great fan of usable mass transit systems. When I lived in Washington DC, I regularly went to New York City on business without once climbing into a car or a plane; I’d walk down to the nearest Metro stop (Cleveland Park, Red Line), take the subway to Union Station, take an Amtrak train to Penn Station in NYC, then walk crosstown to my hotel or business destination. I’d then reverse the whole process to go home again. But I was also quite aware all that time of the financial struggles and subsidies of both WMATA and Amtrak.

Likewise, ULTra will only succeed in small, constrained settings, such as airports and office parks. The video itself references those two settings, but the ULTra website references grander uses. I just don’t think they’ll happen, at least not without massive government spending, and even then they won’t make a real impact in automotive use.

As always, your mileage may vary.  ..bruce..

The first column, “Second Class Software Quality for Major IT Projects”, talks about the curious fact that organizations are willing to spend millions, tens of millions, even hundred of millions of dollars on major IT project and yet still nickle-and-dime their software quality assurance (SQA) effort. It doesn’t help that SQA personnel are pretty much on the bottom of the tech status totem pole, either.

The second column, “Do Not Defer The Difficult in IT Projects”, describes the all-too-human tendency in IT development to put off dealing with the toughest problems until last — at which point, you may not be able to solve them all. It also explains why so many IT projects get 80-90% “done” and then suddenly slip for weeks or months without making much progress.

Enjoy, vote, and comment!  ..bruce..

The other day, an IT colleague of mine mentioned a conflict at a corporation where he’s working. The corporation has a mission-critical application deployed across a large number of workstations. The set of corporate employees who use this application largely use it and nothing else all day long at dedicated workstations. The application they are using is a customized third-party application; however, the firm has been having chronic problems with this app (let’s call it “QRSApp”), and so is looking at different solutions. The firm could continue to make changes to QRSApp to fix their problems. The firm could switch to a different third-party application; several other vendors market applications of this type within this firm’s industry. Or, as a senior IT manager now wants to do, the firm could develop a completely custom and private application to replace QRSApp, so that the firm has complete control over it.

The question: which solution is best?

Comments are welcome.  ..bruce w…

But sometimes with projects that really shouldn’t succeed—that are attempting too much, too fast, with too many risks—enough things go right, particularly along the critical paths, enough superhuman effort is made by those involved, so that the project does indeed go into production on time and possibly even under budget. Upper management is thrilled; the development team looks great; and all’s right in heaven.

And that’s when the real trouble begins.

Feedback is welcome, there or here.  ..bruce..

Dr. Ashton was an outstanding instructor. I took this class in 1974, and all our programming was done on an IBM 360/65 mainframe in 360/Assembly, on punched cards no less. Yet Dr. Ashton thoroughly inculcated in us the concepts of structured programming, having us (for example) come up with half a dozen different ways of implementing a WHILE loop in assembler.

At the same time, he did his best to teach us the realities of software development and engineering. One of his comments in class seemed so axiomatic that I immediately thought of it as “Ashton’s Law” and have quoted it as such ever since:

Ashton’s Law: Whenever someone tries to do something for you, they usually end up doing it to you.  — Dr. Alan Ashton, 1974

I have long lost track of how many times over the past 34 years I’ve thought of Ashton’s Law or have spoken it out loud to others. Dr. Ashton made the comment in the context of operating systems, software tools, and applications; all we have to do is look at something like the User Account Protection in MS Vista to see that Ashton’s Law is all too much alive and well.

But there is a deeper issue here in software design and implementation, which I’m also sure Dr. Ashton had in mind. When two software components have to interact, there is usually an explicit and documented (by the source code itself, if by no other means) interface for one component (the ‘called’ component, for lack of a better term) that the other (the ‘calling’ component) makes use of.

In designing functions or services of the called component, we often end up as perpetrators of Ashton’s Law. That is, in our desire to do something for those who will invoke these functions or services, we end up doing something to them.  We make decisions about preconditions, calculations, and results that may seem quite reasonable to us, and that we may have the best intentions for; still, our decisions may lead to others cursing our names (or at least our functions).

There are always tradeoffs in software development among such desirable features as reliability, performance, memory footprint, calling/service standards, security, simplicity, and so on. Our priorities — even our requirements — may differ from those who will use our component’s functions and services, and so a certain amount of friction is perhaps unavoidable. What we can do is spell out all our assumptions and restrictions, and the reasons behind them, so that those using our functions and services know what they’re getting (or not getting).

However, there may exist also what is variously termed a deep, hidden or undocumented interface for the called component. This deep interface deals with invisible and often unknown requirements, side effects, and consequences of a given function or service provided by the called component. For example, the function or service may leave some aspect of the software system or the host computer system in a different state (e.g., changes to internal data structures, changes to files or databases, launching or killing of processes, and so on) without making that fact explicitly clear in any documentation or the API itself. You may feel there is a good reason for this, but it may also interfere with the calling component’s on-going functions.

As with much of what I post here, this may seem quite obvious to you, but trust me — obvious or not, it’s incredibly common and quite frustrating for those having to use the offending software. As software engineers creating software components, systems, and applications to be used by others, we need to constantly keep Ashton’s Law in mind and ensure that we are truly developing useful functionality for others instead simply making their lives more difficult.  ..bruce..