The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Cheap conflicts with almost everything...

"The only goal that usually doesn't conflict is the requirement that whatever you design be really, really cheap."

This is exactly the opposite of the truth. "Make it cheap" is in conflict with *all* the other goals. As a trivial example, it costs nothing to do nothing.

Take the trashcan example - you can have a can that's heavy _and_ light, open _and_ closed, and possibly even big _and_ small, if you were willing to pay for the extra cost (detachable base?, automatic motorized hatch connected to image recognition for incoming trash? modular internal structure?). Even if ignoring contradictory requirements, "cheap" is still a problem - large cans cost more to make... You might need more of small cans... and so on.

Take the second example - the Motorola RAZR button. You can solve it by using a faster computer, or having a separate built-in "turning on" animation that would automatically play while the computer boots, or whatever. But doing so would cost more - a more expensive computer, more RAM, more ROM, etc.
Oren Ben-Kiki Send private email
Friday, January 27, 2006
 the constrainsts have to been used as constraints.  We can not used them as part of the solution, but that all of them create a notebook of loads.  ej: 

- it does not movements by the wind.
- The trash operator must move trash can easy and without risks.

 This is obtained placing a subjection base on which we will place an anchorage for the trash can.

That's the real value of constraints: not to do.

Best regards

Jon Herrero
Jon Herrero Send private email
Friday, January 27, 2006
Actually, cheap frequently doesn't conflict with simple, and in some cases cheap and simple aid reliable.
Friday, January 27, 2006
Cheap also tends to conflict with "time".  If I want a trashcan that's $5, I could wait 10 years until a new material has been invented that works well but is cheaper than existing materials (steel/aluminum/etc).  In the meantime, I sell nothing. Or, I could make it out of existing materials and sell it just cheaply enough that people are willing to buy it and then <a href="">Churn Baby Churn</a> on a newer version as cost pressure mounts.
Joel Sumner Send private email
Friday, January 27, 2006
There's a very old saying:

Cheap, fast, or high quality: you can pick any two of the three.
Bored Bystander Send private email
Saturday, January 28, 2006
+1 for "sometimes cheap results in simple (easy to use and easy to maintain))"

I remember reading, years ago, (probably in Code Complete) that to meet a short deadline, you must reduce features. Seems so obvious now, but it had never occurred to me.
Mr. Analogy {Shrinkwrap µISV} Send private email
Sunday, January 29, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz