Category Archives: Philosophy

Using Buzz to Take Advantage of Bureaucrats

Carson Holmes made an interesting post <a href=”″ target=”_blank”>Big Consultants Use “Lean” Buzz to Take Advantage of Bureaucrats</a>

My response:

And you can bet that when Big Company and Big Consulting Inc fills out an industry survey about the success of the projects there, it will be all rosy.

Too often I have seen execs roll out large deployments of enterprise-wide systems &mdash; largely I think to get it on their resumes &mdash; with little true ability to actually measure the pre- and post-outcomes. This is just seemingly normal for large, bureaucratic organizations &mdash; even if they are ostensibly capitalist/free-market driven.

I think the problem is that very few organizations (I know of none, but there must be some) truly knows if the IT budget is delivering business value <i>as good as it could be</i> in such large organizations. For example, do you think CIOs from two companies can discuss the output of their IT staff on an absolute basis? Someone from the outside might be able to discern that one organization appears to do twice as much work as the other, with fewer people. But even that is more of a gut feel than a measurement of a consistent unit of measure.

If the output of development were easy to see and measure (e.g., painting walls or laying carpet), it would be easy to examine return on investment. Eventually, competitors that do a better job of efficiently leveraging technology for business advantage will win out in the free marketplace. But it could take years or decades to reveal bad decisions (think Y2K) — by this time the responsible individuals are long gone, or have been promoted up the chain.

(Even in the small, many times an individual developer may not be around long enough to learn the consequences of some decisions/code they made two years ago &mdash; hence not being able to learn and grow from that experience. Instead, more often than not, they see and learn from other people’s mistakes. Yet they are unable to understand the original thought processes that went into that decision, because the author is long gone.)

Until our industry is able to resolve the conundrum of how to compare expenditure versus return on IT, it will be easy for Big Consultants Inc to do Selling By Buzzword, and easy for IT execs to do Management By Magazine.

It gets worse in large bureaucracies, like the government, where there are no market forces to expunge wasteful practices.

We are indeed a nascent industry.

CMM Level 5 Beats Agile? WTH?

Larry Constantine wrote a “Real Data” post wherein he posited a question (summarizing):

What would it mean to the agile community IF CMM level 5 and RUP practices actually worked significantly better than agile ones? Would that mean we should switch horses? Or would it mean we should revise agile to incorporate the best parts of other practice traditions? (And maybe shed some baggage at the same time?) Or doe the agile community have the TRUE answers, regardless of the facts?


without reading the other 20 posts, here’s my gut reaction.

I would surmise that the success or failure of a project being attributed to the methodology is but one aspect to consider.

In a multivariate analysis of variance, just how much impact does the methodology have? Heck, we can’t hardly even say two projects are alike in too many dimensions.

In my opinion, it isn’t the process that matters nearly as much as the people. Ineptitude will never be trumped by CMM 5. Ineptitude may merely take longer to surface in a heavyweight process. Frankly, I have always felt that agile methods fare the best in the hands of really keen teams, and can fail miserably in the hands of rank amateurs who don’t “get it.” Folks that don’t “get it” are protected inside large process.

I would question the results (even without any a priori knowledge of them — since you revealed nothing in your post):

  • The data is anecdotal and unscientific (no double-blind studies)
  • Was the data unwittingly tainted by those who provided it?
    • Did all the successful small agile projects pass on reporting because they don’t keep such minutia?
    • Did all firms that keep such data naturally want to look good?
    • Did all firms that spend LARGE sums of money on heavy processes sugarcoat their results so they can justify this expenditure?
  • Just who keeps the total cost of ownership? really.
  • Who keeps the total cost of maintaining a CMM 5 level shop?
  • What about projects that failed and go under-reported — with either methodology?
  • Exactly how much data do you have on truly longitudinal studies?
    • How many legacy systems that have been in place for 20 years were in the study?
    • How many 10 year-long agile projects have their been?
  • Is there pressure on the data analysts to have the results appeal to the paid recipients/members?

The cynic in me also says — IT DOESN’T MATTER. You can’t legislate responsible behavior, and you can’t dictate a foolproof software development process.

The agile concepts are about as irrefutable as Newton’s Laws, so if you told me CMM 5 was the Holy Grail, I wouldn’t change one sentence on the agile manifesto. Agile is all about doing the best thing that works in your current situation. CMM5 certainly does not apply to 100% of the software projects… whereas the agile mindset does.

The best we can do is share experiences and loudly proclaim “caveat emptor” and “YMMV.”

I wonder… is it a bit like free market forces/capitalism — where you can have “sky’s the limit” wealth and abject poverty (agile); versus socialism where the range from best to worst is much narrower (heavyweight, prescriptive)?

I think we could use the Super/Freakonomics guys to help tease out interesting causal relationships between the findings and reality.

Certificates Are Just That

Uncle Bob writes a great post tackling Scott Ambler’s poke at Scrum Certification.

While I understand the concern regarding getting a certificate for attending a two-day course. And I understand that the Scrum Alliance is now instituting an exam… I wouldn’t dream of being an outsider questioning Ken’s intentions behind the ideas. Instead, I assume he and the Scrum Alliance have nothing but the best intentions for the industry.

The world will sort this out… Welcome to free enterprise. If HR folks decide to use a piece of paper as a measure of something important to them, and it doesn’t yield the desired results, they will adapt.

If folks hire people based solely on a piece of paper, they’ll likely get inconsistent results, and be free to change their ways. Or not. If people think that doing software or managing a software project is learnable in a two-day course, they are free to act on that hypothesis. Learning is a daily privilege.

A 2-day course to get a certificate or four years at a college to get a certificate… neither truly represent the ability of an individual to perform in a certain capacity at a certain organization on a specific project.

IMHO, there isn’t much to get in a huff about… move along, nothing to see.

BTW: I am UML Certified, so hire me! (I’ll just keep it a secret that I didn’t have to take a course (just helped James Odell beta test the exam)! The certification does not test *if* you can model, but only that you know the syntax of the modeling elements. BFD.)

Is your right-brain active?

Check this out…

Right Brain Test.

Until I stepped back from work, came at it with a clear head, I could not see the image…

It is a good reminder that we in IT are often so very much focused on linear thinking, that it is hard to allow the right brain to get much air time.

Yet the right brain is where all of our creativity lies!

Large-scale Separation of Concerns

Found this draft post from: “Last edited on April 20, 2009 at 4:10 pm” … Wonder where I was headed? Hah, I’ll add a 2011 conclusion.

While we have enjoyed employing Separation of Concerns at many levels:

  • Design Patterns
  • Layered architecture

I wonder if it can go farther to assist us in developing robust applications.

I have been preaching a “Dual Architecture” for eons…

  • Application architecture (features)
  • Technical architecture (code, framework)

However, I think this could be taken a bit further.

We use source code, classes, tables to be an abstraction of the underlying true system being run. The source gets converted… the classes get converted, database tables get converted… to something that the machine knows how to deal with.

User gets the functionality expected, the system does the grunt work.

The user is not too worried about the “how” it works, but rather more so that it simply works.

With software, it would be nice to be able to work at a similar higher level of intention, or functional need, with less regard to the nitty gritty detail.

After all, with most business applications, the fastest moving component is technology continually changing.

A major, large-scale SoC is to separate the Functional needs from the Technology.

Users care little if the app is built on Java, .NET, Ruby, COBOL…

2011 Addition:

Of all the languages and frameworks that I have used over the past 30 years, I would say Ruby and Rails (and it’s community) with MongoDB/MongoMapper has come the closest to allowing a greater portion of development time and thought to be spent on solving the customers needs and less time on the infrastructure nuts and bolts.And it is more than the language (Ruby) and the framework (Rails). It is the entire culture and constellation of tools and gems and community that makes a difference.

In addition, it feels like I can code more to the intention of what I need the software to do, and less about the details of the language getting in my way.


Should some apps be more highly engineered?

Part of the challenge for mission critical software is that very little of it is engineered and built to last for its intended lifetime.

This is not at all well thought out, just a “blip” that flitted through my head the other day… But at the risk of suppressing the idea, I’ll toss it out into the public domain for ridicule or conversation.

Some observations…

In an engineering world, requirements lead to rough sketches which lead to engineering designs (CAD), and then factor in production engineering to indicate efficient ways to build it, and then spend time in creating reusable and malleable designs with which to exercise the prototype and make further refinements to the design based on feedback (like Boeing 777 being designed entirely on CAD), and then finally produce the item.

By contrast, software engineering is largely an oxymoron in most places. Many in the software world have a good time honing people processes and doing a better job at being pragmatic with our resources (myself included). As a whole, we have a few pre-made hammers and nails and springs, we have some off-the-shelf components here and there, but largely we bang out unique snowflakes left and right. And we try to do it as efficiently as possible. (The promise of standard components has long gone unfulfilled — as if each window, bathroom, kitchen cupboard in your house has to be mildly unique.)

In some case, this is a fine approach. Relatively cheap. If system needs to be redone, just build another one with a different team a few years later. But in other cases where a system is supposed to serve major business functions and is supposed to be around for 10, 20, or 30 years… Which is the better approach?

  1. Build, grow, and maintain single system over time (which ends up being a legacy system on old hardware and using old software, etc., building up excessive technical debt)
  2. Be vigilant and rebuild the entire system every few years to take advantage of the latest in technology and new found domain knowledge, avoiding technical debt
  3. Spend time building a system or tools that can help stamp out the features and even allow you to re-tool to use new technologies. Something like an aircraft design CAD system that allows 3D simulation.

And yes, I realize the seeming cost of trying things out in “hard”-ware is possibly more expensive, so that the tooling has evolved to compensate. And yes, software is so easy to change, why bother working that hard to engineer it… If it works, great! If not, just keep hammering away at it until it does work. No material wasted! And yes, I know we have come a long way I suppose (although why are freaking dates so darn hard for database vendors to get right?)

Of course, it took engineering a long time to get there… And it requires a different skill set mix than just a preponderance of software “production line” workers:

  • “Requirements” Modelers
  • Design Engineers to package things up into a balanced whole that hits the sweet spot of functionality, cost, and performance (et al)
  • Technologists for the various disciplines (from UX to DB, and Java to .NET or COBOL)
  • Fabricators
  • Testers (who help early in the design stages to flesh out the design alternatives)

So, do we need to consider better ways to create major, long-lived systems? Do we need to be more CAD like? Maybe Model Driven Architecture (gasp)? Or Domain Specific Languages (yowza)? Or Language Workbenches (eek)?

As I said, not well fleshed out at all… just some extemporaneous/loose thoughts flinging around my (all too empty?) head.

Technical Stimulus

So there I was at HIMSS where I met two friends…

While one vendor was explaining their products, they referenced how you could take advantage of the Stimulus Package — each doctor can get $44,000 by signing up for and using the electronic health record system they were selling.

As a selling point for their wonderful products, they had a real, live user — CIO of a 260-bed hospital — describe his experience. By automating the paper forms, they gained better use of their data and less storage needs, etc. The savings from reducing their staff of 150 people down to a mere 50 people was “$4M in FTE alone!”

I wonder if anyone else sees the irony in this… Or is it just me?

Zealotry — ain’t all bad!

Uncle Bob wrote a nice piece on why being passionate and enthusiastic about what one does (and yes, maybe a bit fanatical), is a good thing!

When you feel in your gut that something is right, don’t let others deride your efforts and ridicule your passion.

At the same time, be pragmatic and avoid dogma. Know why you do what you do. Be open to other ideas. Constantly try to grow and improve.