Clueless Companies Can’t Cope

I’m home sick today, so I’m a natural captive audience for free movies, or so I thought.

I was half-watching a movie on Crackle (Sony) on an iPad, and the “preach to the converted” ads for new RIM products were repeated so many times that, frankly, I lost count and I barely managed to finish the movie. The ads, that were amateurish at best, we’re repeated so many times that it made the product offerings look cheesy and irrelevant.

Continue reading “Clueless Companies Can’t Cope”

Advertisements

Ed Catmull on why innovation and sustained vision matter

If you are in a software leadership position, this is worth your time.

A Conversation with Ed Catmull – ACM Queue.

Key quote:  “When computer graphics became practical, it reintroduced technical change into this field and invigorated it.
Continue reading “Ed Catmull on why innovation and sustained vision matter”

Software architects and strategic decisions: Build, buy, open source, or partner?

I had a conversation today with a former colleague about implementing mission-critical software, and the cost assumptions of Agile methods. He cited “Balancing Agility and Discipline: A Guide for the Perplexed” as an analysis which says Agile assumes as an axiom that the cost of change is constant (in the front end engineering processes, not in remediation, fixes in the field, etc.) Frankly, I suspect that’s because Barry Boehm is a classic “programming in the large” guru, but I haven’t read the book yet. 

This is true (that Agile assumes constant cost of effort) in the sense that it’s held constant in the same sense of any other “assuming all other things are equal, we vary this.”  I see the point, but it seems to me that it’s not true in practice, in my experience, but then, I don’t think many people implement Real True Pure Scrum or Lean or XP or any other agile practices; they typically implement some kind of composite methodology, which merges specifications and design artifacts in the outer feedback loops of (for example) Scrum.

But he did have an excellent…nay, *superb* point: without explicit architecture work as an input to software development, development frequently gets caught in a cycle of relative local improvement, without being able to leap beyond the limitations of the existing or incrementally developed architecture, and sometimes that just won’t get you where you want to go.  I personally believe that these outer feedback cycles, including project kick-off, are the best integration points, and that most people practicing Scrum are working away with the “release and below” of the feedback loops, and neglecting release and multi-release planning entirely.

(I personally like the XP-style feedback loop diagrams on this page…to me, the architectural inputs belong in the outer feedback loop, with tweaking and involvement from the architecture team in the inner loops.)

To me, the point is that as software professionals, we have to be able to make decisions about what we’re going to build, buy, or integrate with, and this meta-decision can easily be a part of the Scrum, XP, or other Agile processes, and we don’t have to model the cost of the estimate purely by (for example) planning poker, especially when there are other costs involved. However, many organizations FAIL to make these decisions, instead always choosing to build, which leads to massive expense overruns, because they are trying to solve the wrong (software architecture) problem.

I’m looking forward to reading the book to see if it provides suitable guidance for practitioners in the field, both that I can use myself, and that I can reference to customers and employers. I generally find (both when working directly for an organization, or as a consultant) that some kind of ‘made to fit’ methodology is what’s really needed…and I haven’t seen that codified. Might have to do it myself, we’ll see.

Comments, insights, or experience are always welcome. More later after I read the book; I’ve always enjoyed Boehm’s work, so I’m looking forward to it.

Thanks,
Dak

Great article on code rot

OK, this is waaay more technical than most of the things that I reference, and I apologize to those of you who are innocently reading along, expecting my usual software engineering from the management perspective entries and links.

…but this is really good. Read the gist of it; if you are involved in software, you really ought to know: code rot is real, challenging, and is all about unmaintained and unreleased code.

http://wordaligned.org/articles/code-rot

Thanks to Bruce Rennie for pointing this out at work.

Dak

Building teams: Developers, not Programmers

If you aren’t in the software development business, this post is not for you.  These aren’t the droids you are looking for.  Move along!

Once upon a time, it was Good Enough to have wicked good coding skills.  Master programmers would hand out assignments to the rest of the team, who would code up the concepts and go their merry way.  However, those times are long gone; not only are coding skills regularly taught in high school (all over the world), but even the higher level skill of programming to specifications, not designs, has become a commodity.

I personally believe that the best answer to the commodification of skills is refactor jobs and skill sets.  With this in mind, I am thoroughly convinced that people who were once content to be “programmers” need to be “developers”– consumate professionals able to solve the “whole problem” and take a design task from concept to production.

The fundamentals of business and career growth remain the same: find a need and fill it.  However, there’s no longer a need for 100% code jockeys.  That’s OK; solving the real problem is more fun, and pays better.  (Anyone who I have worked with over the years will recognize that I’m consistent on this point…and most of them have moved on to bigger and better things.  If you are reading this, do drop me a line or post a comment.)

As always, best regards,

Dak

A brilliant management two-for-one

There are two excellent ideas in this posting on ZDnet, aside from the observation that you can scale Ruby on Rails if you avoid hitting the disk farm for static content:

1) Have a team devoted to rapid scalable prototyping.  (LinkedIn Light Engineering Development)

2) Use free apps for both proof of concept testing and marketing.

Read and enjoy.

Ruby on Rails: scaling to 1 billion page views per month by ZDNet‘s Dennis Howlett — While a lot of attention has been focused on Twitter with questions about whether Ruby on Rails scales, LinkedIn has been quietly running a RoR application on Facebook that is beating down around 1 billion page view per month. Bumpersticker, a relatively trivial Facebook application that allows you to create a cartoon that you can […]

Best,

Dak