Using KISS with Demos

I recently prototyped a simple application to see how the simplest form of posting and receiving messages using MSMQ worked. The prototype was a simple WinForms application with two buttons - one for post and one for receive - and a rich textbox to log the activity. All of the logic for the process was in the event handlers for the two buttons. There was no MVP, no separation of layers, no unit testing. The whole form file was no longer than maybe 80 lines of code.

I showed the demo to one of my colleagues and he shook his head in disappointment. Being that we have recently paying attention to the craftsmanship movement on DDD, BDD and the like he asked "Where is the MVP? Where are the unit tests?". I proceeded to explain to him that it was all a simple test that I wanted to perform and I didn't want to clutter my code with unnecessary complexity. Besides, the code was very straight forward and did nothing useful other than demonstrate how to post and receive trivial messages using MSMQ. I also pointed out that fact that this code should not be further enhanced or modified to prove something else or worst, morphed into a real application.

My point is: when creating proofs of concept, keep things as simple as required for the goal at hand, even if it means watering down your code and always remember the K.I.S.S principle - Keep It Simple "Silly".


Derick Bailey said…
Good stuff, Fernando. I'm in 100% agreement. when doing prototypes and other learning activities for code, don't bother with "the right way". Learn first, by getting things done and working. then be willing to throw away that code and re-do it "the right way" in your actual application.

Popular posts from this blog

Simple Example of Using Pipes with C#

Difference Between Adapter and Bridge Design Patterns

IoC Container Vs. Service Locator