4 ms·

Spot on: "This entire debacle is representative of a problem I think is endemic in the industry these days, the inability or unwillingness to engage in rapid p

Spot on: "This entire debacle is representative of a problem I think is endemic in the industry these days, the inability or unwillingness to engage in rapid prototyping. Every successful project I've ever worked on (and I've worked on some fairly large enterprise-sized projects), we started by designing and coding a quick "throw-away" skeleton of the application, that let us look at how the thing worked, where the unseen warts were, and where the vendors had lied about their APIs, etc." I don't have the perfect solution (yet) but there is a definite difference, a sort of "feeling of entitlement" present in many coders who came along after the microcomputer wars of the 1980's. They expect things to "work as advertised"...and a heartbroken when their project ships late due to unexpected difficulties with the environment/ide/framework/etc.

edw519 17y ago
"Every successful project I've ever worked on (and I've worked on some fairly large enterprise-sized projects), we started by designing and coding a quick "throw-away" skeleton of the application..." Me too. But for another reason... I almost never get real specs. But once a user sees a prototype, they are suddenly no longer bashful. They'll tell you how it really should be.
- omouse 17y ago
  Someone on Slashdot commented and said that they're company has 2 phases for developing software. The initial prototype phase where the hackers get to use whatever tools they need to write the software, just to get something out there. The point is to figure out the specs based on that and then once they do that, once they have the scope of the software determined, then they can just write a spec and feature list out and hand it over to the engineers who turn the prototype into an actual product (with documentation, full-scale test suites, etc.)
- jasongullickson 17y ago
  Absolutely, and I don't think this is bad, just a frame of mind. Let's face it, it's just easier to know what you want once you have something in your hands to play with. I think instead of resisting this we should adopt tools and processes which make it easier. When I've had the ability to facilitate a project in this way, the result has always been of superior Quality compared to other methods.

edw519 17y ago

"Every successful project I've ever worked on (and I've worked on some fairly large enterprise-sized projects), we started by designing and coding a quick "throw-away" skeleton of the application..." Me too. But for another reason... I almost never get real specs. But once a user sees a prototype, they are suddenly no longer bashful. They'll tell you how it really should be.

omouse 17y ago
Someone on Slashdot commented and said that they're company has 2 phases for developing software. The initial prototype phase where the hackers get to use whatever tools they need to write the software, just to get something out there. The point is to figure out the specs based on that and then once they do that, once they have the scope of the software determined, then they can just write a spec and feature list out and hand it over to the engineers who turn the prototype into an actual product (with documentation, full-scale test suites, etc.)
jasongullickson 17y ago
Absolutely, and I don't think this is bad, just a frame of mind. Let's face it, it's just easier to know what you want once you have something in your hands to play with. I think instead of resisting this we should adopt tools and processes which make it easier. When I've had the ability to facilitate a project in this way, the result has always been of superior Quality compared to other methods.