4 ms·

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 ke

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.

hinkley 12y ago
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.
- crpatino 12y ago
  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
  - sopooneo 12y ago
    Your proposed approach is very much in line with Joel Spolsky prescribed in his iceberg essay. http://www.joelonsoftware.com/articles/fog0000000356.html http://www.joelonsoftware.com/articles/fog0000000356.html
- pjungwir 12y ago
  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.
  - penguat 12y ago
    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.

hinkley 12y ago

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.

crpatino 12y ago
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
- sopooneo 12y ago
  Your proposed approach is very much in line with Joel Spolsky prescribed in his iceberg essay. http://www.joelonsoftware.com/articles/fog0000000356.html http://www.joelonsoftware.com/articles/fog0000000356.html
pjungwir 12y ago
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.
- penguat 12y ago
  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.