This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Prototyping is ( should be ) learning
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I'm going to try something new for a change. Up until now I've always put special effort in my posts to make sure that they were worth reading. As such, the time it took to actually get a post out was considerable. So, I'm going to try to speed-post ( speed writing as real authors call it ). Should the quality suffer too much, let me know and I'll go back to the way things were before.
Following up my last post on prototyping, I have recently finished a project for a client - a prototype. No, not a paper prototype. A .Net Winforms prototype, hooked up to a MS SQL Server 2000 database, with stored procs. It was actually more of a full-blown application - but it was still a prototype for a huge military system.
The client is a BDUF software shop - well, actually they're more system integration than just software. But, despite that, the prototype was not developed by their strict methods and just sort of happened. Think "quick & dirty" but dirty is out ( because that doesn't sound good ) and quick didn't really happen. Hmm...
Anyway, my prior post on prototypes came as a result of a discussion on a different blog ( fabrice's I think ). There, comments discussed the value in putting more effort in a prototype in the hope that some of the prototype could be then reused in the actual system. I have issues with this since it takes you out of the proper mindframe required for prototyping. Bottom line: you should not reuse code from prototypes. The most important thing to get from a prototype is to learn. The lessons learned are the value of a prototype.
Anyway, after talking to several people on the team at the client I got the distinct impression that the lessons learned would be only those that were planned. In other words, other than the UI, no element of the prototype was to be studied. The famous statement ( the fact that it is famous makes it all the more prone to misinterpretation ) that you wouldn't drive a clay model of a car ( or live in a cardboard house, or whatever analogy of the moment presents itself ) was used as justification.
The most important lesson I learned from the prototype was the difficulty of getting the layered architecture to sit with the OO design used at cross-functional boundaries ( UI elements - Domain elements for instance ). Later, I redid the design using a SOA and you'd be surprised at how well everything held together.
Since I'm running out of time I'll wrap it up. The moral of the story, don't put on the blinders when it comes time to learn. Don't just learn what you plan to. Be ready to learn totally new things that you didn't expect. Make time for this kind of learning. It is the most valuable there is.
Previous Topic
