Posts Tagged: software development


12
Sep 10

What is fixed? Quality or Time?

Ken Schwaber was contemplating team dynamics: they were taking on too much work in hopes of meeting a time frame. The deadline (time) was fixed and the features (scope) were fixed, and the outcome was that regression testing, performance testing and unit tests, were skipped (quality).

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.


8
Sep 10

On Documentation

George Dinwiddie:

“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.


27
Aug 10

Great Design

Fred Brooks in an interview with Wired:

“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.


12
Jul 10

Beliefs

Beliefs: The framework of things you hold to be true, and of which form the basis for all of your decisions.

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?


29
May 10

Time Bombs

Ran across this quote recently, thought you might enjoy it:

“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]

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