“The problem is that the more big-bang you are, the less likely you will get everything you want. That’s because there’s a ton of work in progress, and that it’s hard to be omniscient about how your architecture will work in practice.”

I think this point gets over-looked far to much. The more stuff you keep up in the air (in progress), the less certain completion will be what you were expecting. Make your iterations shorter and you’ll get to guide your project more to your liking.

“The design process that supports delivering a great design document is not the same process that supports delivering a great product.”

“If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead.”

In Who are your Users? she contemplates the general state of command and control, and how the system is not really set up to offer feedback on various forms of communication (like design documents or requirements documents), and as such it is hard for them to get better.

“Things take the time they take, not the time you hope they will take. Pushing for half-time produces half-baked.”

I absolutely agree! When you push for a project to complete faster, something has to give. And more often than not, it is the quality that suffers because that’s the easiest cutback to hide in the short term.

Jerry is an author of more than 40 books, including “The Psychology of Computer Programming” and “Introduction to General Systems Thinking” and was the Manager of Operating Systems Development in the Project Mercury (1959–1963), which aimed to put a human in orbit around the Earth. (Thank you Wikipedia!)

“Doubt is the best QA.”

When you are doing quality-assurance testing, doubt is what will cause you to check (and recheck) all sorts of things. They may work just fine, but you aren’t sure, so you check. This is a great attribute for anyone who is testing the quality of a thing.

If you look at the corollary, it may become more clear:

“Confidence is the worst QA.”

Do you want your testers to come from a place of confidence (“Of course it works!”) or of doubt (“I’m not so sure it works.”)? I vote for the latter. They will be far more careful and complete in their investigation.

Of course, everyone says quality is the #1 priority, but given the triad of time, scope, and quality – how do people act?

My experience is that a deadline is set first (time is priority #1), then what can be done in that time is ascertained (scope is priority #2), and then the unit test, regression tests, etc slide (quality is priority #3) to ensure the time & scope are met.

I don’t think this is malicious — it is just that when you’re focused on the short term, a missed deadline is much more visible than a missed quality goal. Technical deficit issues with quality can hide for months or even years without ever being caught – so naturally they get a low priority.

My advice: If you want to think in the long term, set the quality standard first and set the deadline second. Missed scope can be addressed in the next iteration, but missed quality may never get fixed till your whole system crashes.

“Why is documentation so important to us? It’s because we’re used to using documents to carry our thoughts and ideas to other people, other places, other times. Documents are good at the “other places, other times” part. Documents can be good at transporting ideas to “other people,” but it’s really hard work.”

When you are on a team that is co-located, it’s a lot easier to have a simple face-to-face conversation. Time spent creating a document and time spend understanding a document are all to waste if it ultimately falls back on a conversation to clarify the original intent.

My suggestion: start with the conversation. Then, evaluate what is lost in translation. I’m guessing you will find that the conversation is far more accurate in transporting ideas than a document — and it takes a fraction of the time to complete.

“Great design does not come from great processes; it comes from great designers.”

This seems so natural and correct when talking about design. Applied to other professions, you might see:

• Great software does not come from great processes; it comes from great developers.
• Great engineering does not come from great processes; it comes from great engineers.
• Great testing does not come from great processes; it comes from great testers.
• Great management does not come from great processes; it comes from great managers.

Yet time and time again, we lean back on the processes that in the best of situations are mediocre and brittle.

Here are some of mine. Which do you disagree with? Why?

Workarounds are never a good thing. Short term workarounds are never short-term. They should be avoided. Do it right the first time, and if you can’t due to time or budget, delay the project. I hate technical debt.

Plan as you go is more appropriate to life and to projects, and returns better results, than planning everything up front (ie agile vs. waterfall). What we are talking about is predicting the future. Sure, you can be somewhat accurate, some of the time. But it’s just a guess. You’ll be more accurate if you don’t predict too far out. If you’re more accurate, you’ll be happier.

The problems of new are less than the problems of the old. On occasion you will run into a bug by upgrading software to the latest version. But I’ve found that on balance, I have far fewer compatibility & stability problems if I keep up to date. And as a bonus, new features!

Buy the well-built item once instead of the cheap thing multiple times. It’s eco-friendly, and you get to have the quality item to use every day. My wife and I had been wearing out a $10 garlic press once every 12 months or so with basic wear and tear — till we bought the Rösle Garlic Press for (at the time) $30. Five years later, it still looks good as new and works brilliantly.

Price is not correlated to the value. Just because it’s expensive doesn’t mean it’s worth a lot. Conversely, just because it’s cheap doesn’t mean it has no value. Open-Source Software, Wikipedia, a walk with your kids – these all have a lot of value, and they don’t cost you a dime.

Deals are rarely worth it. Everything is “on sale”. Everything is discounted. Of course, there are good deals to be had. It’s just that the effort to find and take advantage of the deal is more costly than any savings I might obtain. There is a reason why rebate forms are difficult to complete: it is in the company’s best interest that you never fill them out.

I believe in Scaling Software over Scaling People. See my blip on Techies and The Business, or the whole article here.

The most important attribute to any employee is their willingness and ability to learn. I’ve written about this one a lot. I think learning is the key to innovation, that through mistakes you get better, that Adapting is the Most Crucial Skill You’ll Ever Learn, and that progress (and who doesn’t want progress?) is an act of discovery.

So!  What are some of your beliefs?

“Don’t call your defects ‘bugs’. Call them ‘time bombs’ instead.”
- Watts S. Humphrey

From Wikipedia: “Watts S. Humphrey (born 1927) is an American software engineer, key thinker in the discipline of software engineering, and is often called the father of software quality.”

He has a recent book out that looks like it could be good, Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself.  Has anyone read it?

[via @jurgenappelo]

—

Do you ever wonder whether you’d be better off walking instead of taking the bus? This app will help you answer that question.

Fine tune your personal walking speed and your city’s bus speed for the most accurate Walk or Bus recommendation.

Measure by kilometers, miles, or by configurable city block sizes Receive helpful feedback: “at a brisk pace you will get there 4 minutes faster than the bus”

Ideation: Chris Mueller & Dana Boyd
Graphics: Trevor Brown
Coding: Peter Edstrom
Contact: walkorbus@edstrom.net
Twitter: @walkorbus

“If I let users steer product decisions, the result would be a massive codebase producing a bloated, cluttered product full of features that hardly anyone used at the expense of everyday usability and polish on the features that matter. Like Microsoft Word. Or Firefox.

By listening too much to outside suggestions, I’d destroy the very reason why I’m receiving them.”

“Checking is something that we do with the motivation of confirming existing beliefs. [...] Testing is something that we do with the motivation of finding new information.”

So when you “test” your software, are you really testing? Or are you just checking?

“I think of functional spec as one of the worst inflictions that has ever happened to the software development world. I think functional specs are a relic of a time when building features was a very, very hard and long process and you had to do all of this upfront planning because once you wrote anything in software, it was pretty much impossible to change it. I don’t think that functional specs is a technique that’s any longer relevant.”

“Let’s stop talking about building products. Let’s start talking about creating great experiences.”

Instead of making great software by tweaking one more screen or adding one more feature, let’s step back and take a look at the whole. Understanding what the user experiences, and making that great, is key. Thanks for the reminder Ed, this is one more bit in my drive for contextual design!

Bob Marshall (@flowchainsensei):
“You really have no clue as to how much your business success depends on software, do you?” #neversaid

Ben Simo (@QualityFrog):
“Compliance with standards makes sense when & where interoperability is more important than innovation & improvement.”

Wil Harris (@wilharris)
“New Apple mouse proves not only does Steve think we are too dumb for two buttons, we can’t even handle one. A mouse with no buttons. Nice.”

Jared M. Spool (@jmspool):
“Remember, if you torture data long enough, you can get it to confess to anything you want.”

Jeff Patton (@jeffpatton)
“Requirements are the boundary between what I get to decide and what you get to decide. It’s a fuzzy discussion, or DMZ”

Esther Derby (@estherderby)
“ppl talk about commitment as if it is an act of will. commitment requires will AND time, resources, skill, authority”

Bob Marshall (@flowchainsensei):
“So you’re all far too busy politicking and CYA-ing to actually bother about delivering stuff to the paying customer?” #neversaid

37signals (@37signals)
“The best way to have a good idea is to have a lot of ideas.” -Linus Pauling

Naresh Jain (@nashjain)
“Consistency is over-rated. Consistency is a big innovation killer. Let diversity & positive deviance help us explore better ways”

I agree that sample time is the major difference between projects that succeed and projects that don’t. However I would also argue that the major difference between Waterfall and Agile is the sample time, and thus is fair to pit the two against each other.

When you get down to it, every practice and method is some variation of PDCA/DMAIC/etc. What differs from them is how quickly you close the loop between each iteration, how the speed impacts the style of communications, what you believe about the appropriateness of certain inter-team communications (can developers impose restrictions on the requirements? can developers talk to the customers?).

Agile likes it fast – you need to work hand-in-hand daily with everyone on the team because there isn’t time to do otherwise. It is believed that developers and business people need to talk together, because the developer may have a restriction that the designers didn’t know about.

Waterfall likes it slow – you write design docs, throw them over the wall to development, and again over the wall to testing, etc. You write a lot and try to be exceptionally clear, because waterfall folks believe that conversation about a project is basically a one-way street, slowly falling down each step of the waterfall till the product emerges at the bottom.

Each belief fits a different situation, and the real argument is: which one fits software development the best?

[via @jurgenappelo]

There are many more stats, and some good stories in the interview, but the question I pose for you is this: has your world and your products changed that radically, that quickly, and with so few resources in the last three years? If not, why not? The tools are there, and freely available, to let you do it.

One more tidbit: The original site was built in less than 6 months using only nights and weekends.

[via O'Reilly Radar]

“If you have to explain how your software works, you’ve failed.”

We could all extol the virtues of simplicity. And an intuitive user interface. And a “well designed” and “engaging” interface. But these are all hard to measure. The number of times people ask how to do <anything> in your software? Well, that’s easy to count, and the goal is a simple one: Zero questions.