...People respond with heroic behavior. And when they act heroically, they stop improving. They just act heroically again, again, and again, and they stop learning.

David Anderson in interview for Software Engineering Radio.

Net Objectives conducts a series of webinars on Business Driven Software Development:

This series provides an introduction on how to achieve Business Agility. Business Agility enables an organization to respond quickly to external forces (such as new market opportunities and competitive forces) as well as to respond quickly to new insights attained internally. While many organizations have achieved the local optimizations of more effective teams, few have achieved agility at the organizational level. Even when team agility has been achieved, if improvements to how the business is selecting their product enhancements isn’t done, overall return on investment of software development may not have significantly improved.

First event is tomorrow at 9 AM PST. Register at the event page to attend the webinar.

Have you ever worked with, maintained, explored a system which looked and felt really great in one area, but was really awkward and clumsy in another one? That was an instance of an elephant on the crutches.

This often happens, when design specification was not consistent in the level of detail for different parts of the system. And here is how this may happen.

When you design a system, it is never going to be plain and the same wherever you look at. If you have a database and a user interface - those two parts are already different enough. Such diversity naturally leads to the fact that there are some parts that you enjoy working on more than others (after all we never like doing everything that we do).

What happens next is that you spend much more time thinking about parts you like (because there you use new fancy technology, or neat engineering approach, or who knows why). Therefore you add more details to design of those subsystems that you really like. The outcome of all of this typically would be a specification that is an elephant with crutches instead of hind legs, because elephant's butt was never you favorite part of the system and design of this "subsystem" never was detailed enough to make sure it is consistent with the front.

Ideally, your design should be like Google Maps: you should be able to zoom in and zoom out on any part you need. It does not make sense to have a map, which shows each and every tree in your neighborhood, but gives you only a vague idea about how to get to grocery store 5 miles away.

When developing and documenting design you should gradually and consistently increase level of detail in your specification. Ideally, difference in granularity of descriptions of different parts between any two parts of the system should never be more than one level. One possible way of zooming in would be to describe

• System + external interfaces, then
• Services and components, then
• Add their interfaces, then
• Add interaction (Sequence diagrams) and edge classes, then
• Components' structure and internal interactions, then
• Class-level specification for key requirements (functional and non-functional)

This is not the only possible way to zoom. However, when you have class diagram with methods and their parameters, but do not have stored procedures defined for your database, you are doing something wrong (or, hopefully, your design specification is not complete yet).

Design specification is only useful when it can help you answer questions you get during development. This essentially means that you should be able to navigate it and find things - which is zooming in and out and seeing enough to make the right turn.

Now when my commute went from 10-20 mins to 30-40 mins in each direction I quickly burned the backlog of podcasts. I gave a try to some new and so far I like what I hear. Here they are:

• Manager Tools Podcast
• Software Engineering Radio
• 37signals Podcast

What are some of your favorite podcasts?

Toy Story 3. Release date: June 18, 2010. 323 days from now. Does not that amaze you? No? Most likely you are not a Project Manager. And certainly not a software Project Manager.

In software world we know how hard estimation is. And to date I have not met a Project Manager, who would commit to a delivery date a year from today. Well. one can commit, but what about keeping this commitment. Recently Boeing postponed first flight test for its Boeing 787 Dreamliner till early fall. This might not sound bad, but what if originally this aircraft was scheduled to take off in 2007?

Surprisingly, in entertainment industry they know how to give promises and keep commitments (at the very least with release dates). How do they do that? I do not know for sure, but my take is that the "secret sauce" should be in very effective scope management. And, of course, expectations management.

When film is announced not more than title, broad story topic, and, probably, some of cast is told out. More details are given out to feed public's interest, but I bet they never tell us about something that can not be done by release date with high degree of confidence.

There is certainly something to learn from this approach.

Last weekend we kind of explored the field of software estimation, so it is about time to see, why it is not an easy task. Complexity is what makes estimating hard.

Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the project

-- Jerry Weinberg, Quality Software Management Vol 1, Chapter 9

And here are some more links to explore the topic:

• The Rising Costs of Software Complexity 2001 Dr.Dobb's article.

What's the most important problem in computer science? Languages, tools, programmers? Well, according to a growing number of researchers and computer users, it's software complexity.

• No Silver Bullet: Essence and Accidents of Software Engineering by Fred Brooks.

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).

• Recent NASA Study on Flight Software Complexity (via Glen Alleman).
• Code's worst enemy by Steve Yegge. A practical view on software size as main contributor to complexity.
• The Fourth Law of Software Design: Complexity vs. Ease of Maintenance. Another practical report, which discusses how "an average-sized computer program is so complex that no human being could comprehend it all at once in their mind" and what effect it has on software engineering practice.

Here are some links to interesting stuff on software estimation and projects planning for weekend reading and watching.

• Your Will Suffer From Power Laws. There are some things, which are the way the are, and you can not change them, even if you want. You can not spit upwind (at least, not with desirable result); you can not make an apple fall up, when you release it. So with our projects there are some things, which we simply have to learn to live with.
• 10 Deadly Sins of Software Estimation webinar by Steve McConnell. Interesting presentation about art and science of software estimation. A lot of references to statistical studies, which give good food for thought.
• Software estimation considered harmful? Alternative point of view on software estimation as presented by Steve McConnell. DeMarco and Lister refer to study, which suggest highest productivity on projects, which were not estimated at all. Does this mean we should not estimate our projects?
• Evidence Based Scheduling. Practical approach to software estimation developed at Fog Creek.
• Agile Management for Software Engineering: Dealing with Uncertainty. A chapter from great book by David Anderson. Something always goes wrong. The problem is that we do not know what and when, yet we have to plan and execute our projects. This chapter of David's book can help you.

Finally, a tip from Leo Babauta of ZenHabits to a project manager, who needs clear mind, when  project is derailed, for finding peace of mind.

I love the definition of solution from old good MSF 3.0:

Solution is the coordinated delivery of the elements needed (such as technologies, documentation, training, and support) to successfully respond to a unique customer’s business problem.

There several things in this definition that appeal to me:

• It clearly separates solution, developed with specific customer in mind, from product targeted at market, as also outlined in MSF Process Model.
• Customer's business is in the center of attention. And if the best way to address this problem is not development  of new software, so be it - it can be as simple as re-engineering existing system and providing adequate documentation or training; or instead of throwing development effort at scaling problem, one can just add more hardware capacity. Again, in case this is the best approach.
• There is no place for technology bells and whistles. If a mere VBScript can solve the issue, why waste precious time and resources on ultra-modern super-cool JavaFX (no offense here) development, if it does not add anything valuable for business?
• At last, technology is not a sole focus of solution development: delivery, documentation, training, etc. are equally as important.

Be sure to deliver your customers solutions and not just software pieces. "Software installed" is not a goal here, "problem solved" is.

There is a very interesting passage by Jurgen Appelo of NOOP.NL, which is almost completely unrelated to the idea of the post about book reading hack:

I don't want to read chapter 20, which is about platform interoperability, which I find completely uninteresting. (Let's face it: wanting to be platform-independent so that you can easily switch platforms, is just as useful as wanting to be bisexual, because it easily enables you to switch genders. Not many people think that's very important.)

While I agree with such a bright comparison of platform independence, platform interoperability is another beast. While you can kill yourself trying to have one product working equally good on different platforms, you not only may need to, but in our fast moving world have to, interoperate with other applications. And sometimes only God knows, which platform they run on.

All of that started with Twitter... I created an account on Twitter. My way to Twitter was quite long and there were, I guess, 3 major factors that made me do that: changes in my professional life, Bob Walsh's comments about Twitter and Hanselminutes episode about WPF Twitter client blu. In my 2 or 3 days Twitter "career" I've already seen famous "Something is technically wrong" so I can see myself as an experienced Twitter user.

But there are 2 other things that prompted me to think about software quality.

After listening to Scott Hanselman's podcast I installed blu. The second thing I noticed after slick UI was inability to work through proxy. I live and die by personal proxy which allows me to easily migrate between different networks during my day. So, what can I say? Nice piece of software, but almost completely unusable in my setting, which as I would guess is not uncommon.

Another sad experience is twitbacks. As a newbie I given in to temptation of working on form rather than the meaning first. I've spent quite a time with this tool, but was not able to produce any sufficiently good looking background. Main issue for me was strange resizing which made text blurry and also lead to incorrect alignment with functional elements of the Twitter page. Again, nice idea, but not usable.

Both of these cases look to me as an obvious shortcuts taken by the development teams on requirements definition or testing stage. Quality of the system output is determined by weakest link in the system. Determined to the extent that piece of software may be rendered unusable in certain common scenarios.

Network client solution cannot omit widely spread variances in Internet connectivity settings.

Image generation software can not afford generating funky images.

Check that you have not fallen into the same trap or start fixing that immediately.