Posts Tagged: software development


17
Nov 10

Avoid the Big Bang

Johanna on Incremental Progress Not Big Bang:

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


30
Oct 10

Deliver Product, not Process

Jeff Patton has a good reminder:

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


28
Oct 10

Communication as a Deliverable

One more post from Liz:

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


16
Oct 10

Things take the time they take

In an interview with Jerry Weinberg:

“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!)


14
Oct 10

Doubt

@rands had an interesting tweet:

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