Behind Closed Doors: Secrets of Great Management (Book Review)

I just read "Behind Closed Doors: Secrets to Great Management" in 1 day, cover-to-cover (~160 pages). Great read, reminded me of a contemporary, dialogue version of "Peopleware". Other notable differences: focused more on people dynamics rather than workplace things, like "furniture police".

So, now to the book:

The book is written in two distinct parts: the first half (pp. 1 - 123) a narrated dialogue of a newly hired manager's (Sam Morgan) experiences with subordinate and superior managers, and the second half was a references/reminder section on all the tips presented by the book. Seven (7) weeks of experiences by Sam Morgan were explored while trying to acclimate to his new team and address existing team issues, all the while pleasing his new boss despite the release schedule being moved from 5-months to 3-months.

"Great management is about leading and developing people and managing tasks." -- from "Behind Closed Doors"

The book goes on to elaborate on the importance of the management focusing on what brings value to the company, and that this should be the focus of all levels of management. In my relatively short career, I've seen managers diligently try all the techniques in this book, but often forgetting the "value to the company" part.

Why do managers seem to lose sight of "value to the company"?

Management is overhead. Granted, it's a necessary overhead once a team grows beyond 10+, or grows into multiple teams. But in some companies, the management overhead grows so large that it begins to serve purposes other than maximizing company value and productivity of people. Once management grows beyond the bare minimum required, then wasteful and potentially destructive politics and protectionism occurs.

In software development companies, today's managers were yesterday's technical leaders. You can NOT be a manager and technical leader at the same time. They are completely different roles, but they do have overlap so people think they can be done the same person. The distinction is hard to make, because both managers and technical leads manage their subordinates.

Managers should focus primarily on the company goals and strategy, and then work on potential tactical solutions with their technical leads. In our software industry, we already know how to find technical leaders for our teams. They can successfully lead a team of software developers. The hardest and most useful thing to do is get the communication and relationship right between the managers and technical leaders. Managers and technical leaders should have a very overlapping role when it comes time to plan, prioritize, and schedule work. Managers have their charge of "providing value to the company using IT resources", while technical leads have their charge of "providing advice, assisting planning, implementing, and supporting software solutions".

Cairngorm is so ridiculous

Cairngorm is an MVC open source framework currently supported by Adobe. This framework is basically a dead project. Last release: 2.2.1 on May 30th, 2007, and only pre-talk about the need and features of an unlikely v3.0. I've used Cairngorm before and immediately didn't like it, but I decided to take an in-depth look at it because it seems development teams are still using it, and I might need to know it.

What's its benefit?

Well, Cairngorm restricts how a developer can interact with data, business layer, and view objects. And the restriction isn't even from the framework: it's just the honor system. But this agreed upon way to get services and execute a sequence of operations ("commands") would help get a mid-to-large inexperienced development team more organized. This pattern would help limit developers exploring new and different ways of doing the same thing.

Drawbacks?

Many. Whoever wrote this really wanted to use as many patterns as possible. One that really bothered me was the use of marker interfaces, namely IModelLocator and IValueObject, to add metadata to classes, yet nothing in the framework uses that metadata! This framework can serve as a crutch to those that don't want to dive into what Flex allows you to do, and this can lead to a popular anti-pattern "the golden hammer": when you only know how to use a hammer everything looks like a nail.

Flex is an event-driven programming environment with tremendous possibilities, and I'm not a fan of Cairngorm trying to limit it so people don't end up writing unmaintainable code.

As I expected, I wasn't the first to have this reaction to Cairngorm. So here is a great post I found after writing my post.

http://blog.iconara.net/2008/04/13/architectural-atrocities-part-x-cairngorms-model-locator-pattern/

Code Mash 2009: Best value conference

I've been to a few conferences in my career: JavaOne, Dr. Dobbs, No Fluff Just Stuff, and some others. And it seems like pretty much the same guys are there presenting the same stuff. I'm thankful that smaller conferences are starting up, and targeting a regional audience. When I go to a conference, I want to interact with real practitioners of these technologies, and not just walking/talking commercials. I don't think these presenters intend to be walking commercials, but it just happens when you're on the speaking circuit for so long.

Most conferences are for companies.

Conferences like JavaOne, SpringSource, RailsConf, RubyConf, Dr. Dobbs, are a single event in one place per year. This means, that unless you live in the same city as a particular conference, you'll need to travel to get there. Traveling to conferences is generally expensive (air+hotel+car+time off work); conferences know this, and that's why they choose expensive venues in expensive locations and when you get to the registration fee of >$1K USD it doesn't seem so bad compared to all the other expenses. Usually, these conferences are during the work week. :( These conferences are a way for companies to reward valued developers.

Some conferences try to be better

No Fluff Just Stuff, as its name explicitly claims is all about technology stuff. Unlike other conferences, this conference is on a weekend, and also is held in various cities each year. I'm a big fan of NFJS, but there needs to be more conferences like this.

So along comes Code Mash v2.0.0.9, which is filled with great presenters, and targets regional developers. For the very reasonable early-bird price of $135, you get a 2-day conference on a Thurs/Friday in Sandusky, OH. With a great hotel nightly rate of $88/night at the Kalahari Resort (largest indoor waterpark in the USA), it's a fantastic deal.

Code Mash 2009 is the only software conference that I've EVER paid for from personal funds.

What's Agile trying to tell me?

I've read books on Agile, and I've received Immersion Training from Object Mentor Inc., and some of that training directly from Uncle Bob Martin himself. And I see one core idea behind Agile that exists in all aspects of Agile development, and I thought I'd write about it here.

Most companies/developers/people seem to have a tough time adopting Agile as the way to go. Or some adopt parts of 'Agile' and morph it into a bastardized version of their existing software development process. I won't go into the details of Agile, but instead look at it holistically.

So what is Agile trying to tell me?

It wants everyone to work together to reach the goal. The problem with most projects is they treat software development as a "service". Clients that need some software built for them think "i know what i want. now if i could only find someone to build it for me." Then they express their wants/needs in some way that they provide to the developers.

Ummm ... but then what?

Clients seem to be able to just wipe their hands, and wait for the development machine to produce what they asked for on the other side. And I can understand this. Services work that way: you ask for something, and then the service provides the promised result.

Software development is NOT a service!

It's a constant brainstorming session between a client and the builder. If the client didn't need a solution for a very specific problem, then they'd probably just buy a software product as a solution. But instead, they need someone to tailor a solution to fit their needs. Agile stresses the importance of runnable/demonstrable software over documents and agreements. Documents and words can be misinterpreted, but functional software can be 'seen' by both the client and the builder. At this point, they are in sync. The client can ask for something and the builder can build it. And after each iteration, the builder and the client can both come together toward a common vision of the solution. Similar to tailoring a very expensive suit: you wouldn't just take some measurements and send it off to be altered. You'd want to be there with the tailor, making sure every adjustment was just right for you.

Final Thought: There shouldn't be clients requesting work from builders, but instead the clients requesting to work with builders. This is how I hope to work someday. Working closely with clients so that I can understand what they want and need. So that I can help them understand what they want. So that I can tailor the solutions and products that they need.

Whoohooo, first midnight blog post.