Hacker News Reader

Comment by rednab | Hacker News Reader

The article author, Robert Glass, took these from his book, "Facts and Fallacies of Software Engineering" (ISBN 978-0321117427), which is definitely worth picking up, or in the very least worth skimming the table of contents¹ of.

¹ For example, here: http://blog.codinghorror.com/revisiting-the-facts-and-fallac...

View on HN

> One of the two most common causes of runaway projects is unstable requirements. Requirements errors are the most expensive to fix during production. Missing requirements are the hardest requirements errors to correct.

Hmm, doesn't this conflict with the idea of "rapid prototyping", where new requirements are thrown in whenever necessary?

The way I've understood it: Prototyping maybe be an effort to develop Requirements. It should not be used to develop a Product.

How can I explain this to my boss? :)

Instead of explaining it, there can be steps taken to ensure a transition between prototype and product, such as prototyping in a language or for a stack that your company does not use in production.

Alternatively, if the company still forces you to push the prototype to production, this can be a great way of sneaking in the technology stack that you wanted to use in the first place.

Make it look like a prototype? I've taken to plastering big warning on non-production systems. Otherwise someone looks at a fragile dev environment, doesn't see it breaking outright, then goes and sells live customers into it and uses the prototype/demo system to setup real accounts. No amount of verbal or email warnings will change this. Hurray, now the one-off demo system is a production environment! As a bonus, you get to write data migration programs to move these customers to the entirely-unrelated final product!

But instead, if there are big red Xs and so on in the UI, then it becomes clear "oh this is a prototype/demo/".

> It should not be used to develop a Product.

I disagree with that conclusion. Prototypes help in both clarifying requirements as well as eliciting requirements. However, for the latter, a prototype may be necessary but not sufficient.

Rapid prototyping isn't a silver bullet (there is no silver bullet). Some approaches can help you better stay on top of unstable requirements than others, but if your requirements are missing or unstable, your project is unstable and poorly defined, period.

Consider prototypes a way of quickly getting the user to confirm: no, that's not right :-)

Only a half joke, too: it's easier to critique and improve something concrete, even if it's objectively rubbish, than to go from 0 to 100% from just abstract discussion.

The only problem is that quick prototypes and temporary solutions have a habit of becoming permanent, especially if you are understaffed.

In my experience, "rapid prototyping" is an euphemism for "hacking some shit together". Once a product is perceived to be complete, management will insist to keep adding to it incrementally instead of discard any part of it.

They will also avoid allocating time/resources to fix modules that are known to carry significant technical debt. Only until said technical debt begins to cause severe problems any official attempt to address the issue will be done.

In the mean time, savvy senior engineers will fight a guerrilla war to keep technical debt at bay. They will require, incremental improvements to be carried out in parallel with bug fixes and new feature development, typically whenever you touch a file/function known to be in a bad shape. This is more or less OK, but can result in an irrational fear in the team to change stuff for any non-essential reason, eventually defeating its own purpose.

At the end, I always assume that whatever code, no matter how crappy, I get to commit into the source control system, will eventually find its way to our customer's machines. No matter what claims of temporarility are made by people, if it gets out of your localhost, it will be promoted to officialdom in no time.

At one point I had been so burned by this that any time I was asked to do a POC for something, my POC would output all of its data to console and nowhere else. I proved I could sort things in some weird way or read an impossibly large file, but there was no way in hell they could ship my prototype.

Then we had a calm discussion about how long it would take to productize it (usually weeks or a couple of months). It might not seem like that big of a coup but attempting to ship 2x as much as you actually can is a sure way to be absolutely miserable by version 2.1 or 2.2 of the product.

Cool, I like your approach. In many environments, CLI is very clearly (though probably incorrectly) perceived to be "not done yet".

Maybe it is possible to marshal user expectations by carefully controlling how much of the GUI is produced. Not make any pages/windows until the underlying business logic is production ready... it's a wild guess, but might work

Your proposed approach is very much in line with Joel Spolsky prescribed in his iceberg essay.

http://www.joelonsoftware.com/articles/fog0000000356.html

I do mostly web development, so this would be tricky, but I'd love to see a Balsamiq-like Bootstrap theme, so that you can present a "working wireframe" with the same connotations.

In cases where you perform A/B testing it may require a slick interface, whilst still being a POC. In this case I have looked for ways to reduce complexity and ideally any services which require hosting should be clearly hacked together - such that anyone seeing it can give a clear indication that this will not go into production. Choosing to ignore thread-safety and use local in-memory datastores (e.g. non-persistent) will help to not only ship the POC quickly, but also make its temporary nature rapidly apparent.

In addition to what brianmcc said: Given that the requirements are going to change, what are you going to do about it? The ability to change rapidly gives you a chance (not certainty) to respond successfully to a requirements change.

What certainly helps:

* Having small, self-contained, loosely-coupled modules.

* Having an extensive test suite for each module.

* Having small (or zero) amount of technical debt.

* Talking to your customers constantly, preferably before you commit a lot of resources into a new development.

Easier said than done, but definitely not impossible.

Correct. I guess I was thinking more agile rather than rapid prototyping.

I'd add obviousness here. Make the design and code as obvious as possible. Simple and easy to understand.

Does this book contain references for the facts he cites? I would like to use several of his arguments in my own work but it's hard without proper references.

Yes, each of the facts listed in the book has a Sources paragraph and bibliographical references supporting the fact.

From the Coding Horror article, number 30 is:

"COBOL is a very bad language, but all the others are so much worse."

Reply on news.ycombinator.com