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.

A friend of mine commented that while interesting, this was taking the “Do it right the First Time” out of context. I thought I’d look into it a bit more, and from what I can tell, “Do it right the First Time” is an idea embodied in the First Time Through (FTT) manufacturing metric, which itself is based on the Zero Defects idea of which is part of “Philip Crosby’s 14 Step Quality Improvement Process” (someone please correct me if I am wrong).

While I would agree that it seems reasonable to apply this ideal in a manufacturing setting (a highly consistent and repeatable process), I don’t see it as being a good principle to apply elsewhere (say, software development).

The problem I see, is that the principle is often applied in areas that are inappropriate. Design documents for software would be a great example. If a software enhancement was designed was discovered later to be unbuildable, is it the developers fault for not being smart enough? Or is it the designers fault for not understanding the very technical system constraints? Or maybe it was further downstream, and the customer didn’t know what they wanted till they had something to look at. The process depends on experimentation, and is always uncertain at the start. 9 times out of 10, you end up building something entirely different than what you thought you were going to build at the beginning. The way I see it, highly collaborative, multi-disciplinary processes can’t possibly be done right the first time, because progress is an act of discovery, not an act of manufacturing.

So was it taken out of context? Yea, a little.

But is it a good reminder because the principle is frequently applied out of context? Absolutely.

It doesn’t get more simple than that. If you want to know which one is more important in your own organization, ask this: If a planned release clearly can not be completed on time, do you cut features to make the schedule, or do you push the schedule out? If you cut features, I can promise you, you are also cutting quality and accuracy too.

“There are things you as the owner can see and cannot see and you will likely pay me no matter what. However, I know every piece of wood, every corner, joint, mortise, tendon, and grain direction. I know what the wood was, how it needs to be re-formed and what it should become. I could very easily do just enough to pass your visual inspection, bill you and move on; but I learned a long time ago that what you cannot see is just as important as what you can.”

I have found that the investment in quality is always worth the effort. It may seem that the parts you cannot see don’t matter, but they do become tangible in 1000 different subtle ways. The item will feel sturdier, will last longer, will be more flexible to changing environments, etc. It’s a good strategy for boats, and it’s a good strategy for building software too. I guess I’d put it this way: the person that buys the boat (or software) may not see the value, but all of the people who come in contact with it over its lifetime, will be able to tell you if it was well built or not. That’s quality.

“give me a challenge & I work harder, keep pushing right past that to Totally Unreasonable & watch productivity dive bomb”

Some challenges are OK. And they can be downright fun if you have the time to investigate, learn, and resolve them in an intelligent way.

Given the right environment, people will often rise to the challenge and do great things. But just because a some challenges lead to greater productivity in certain environments doesn’t mean that a) it’s sustainable, or b) that it works in every situation, or c) that its the best way to achieve greater productivity.

Build a collaborative environment that has reasonable goals, a good diversity of projects, supportive co-workers, and managers that mentor more than they measure, and I guarantee you’ll have productive employees.

And don’t even get me started on inane concepts like “stretch” goals.

So often we think that imagination is the limit – that whatever we can imagine, we can create. And it is true – we can create anything (generally speaking, with the appropriate time and money). But I find however, that Jerry is right on with the limit. The limit is always courage. It comes in many forms, and is always far more limiting than imagination. It’s the courage to do something new when the old has not failed, or the courage to cut out a feature and do something simple and less complex, or perhaps to abandon the fringe customers in favor of appeasing the core audience. The courage to abandon what worked well enough and try something that might work much much better.

We all have the ideas, that isn’t the problem. We just don’t have the courage to try them.

“Wide variation in programmer performance has been frequently reported in the literature [1, 2, 3]. In the absence of other explanation, most managers have come to accept that the variation is due to individual characteristics. [ ... however,] we found evidence that characteristics of the workplace and of the organization seemed to explain a significant part of the difference.”

[via Ester Derby]

“The minute when I start justifying my estimate or explaining why I have to change a lot of things, I’ve lost. [...] So I have found that the way out of this situation IS NOT to go technical and start explaining how code works. They’re NEVER going to say gee, now that you gave me a quick tutorial in web application design, and then you explained how you’ll need to rewrite the permissions decorators to use a new state factory, I guess your estimate makes sense.

Instead, this approach works OK for me:

Me: I think it is a great idea and it won’t require a lot of research and development, but it’s going to take a while. So based on that estimate, should we put into the queue or not?”

[via Matt Wilson's blog, via Ester Derby ]

“the fundamental goal of DMAIC is to standardize the output of a process, to reduce variation and make the final result as consistent and as repeatable as possible.  However, software development is not a repeatable process and can never have the same output.  Software development creates a unique product (the output) every single time.  As an analogy, DMAIC aims to create perfectly consistent cakes, but software development aims to create a new recipe each time.”

DMAIC is part of Six Signma, and is a method with the following 5 steps: Define, Measure, Analyze, Improve, and Control.