I often used a reference to legos when explaining my career to someone who is not in software development. Everyone knows what Legos are, and Geek Moment: Apollo 11 Lego is due shortly and I am looking forward to this kit.

When I first picked up a software development tool (::cough:cough::vb2) I used Legos as how I saw these objects, visible or not. It was easy to manage the idea that each specific lego part could have specific abilities and ways to affect those abilities. So add in a specification from the client on what they want it to do, and why (WhyWhyWHY! Ask the WHY qusetions, saves so much time) and your building software.

It is a massive over-simplification of the process and needs as well as the abilities of current technologies. But the base concept gets across to the non-tech.

This is also where I disconnect from so many who had a structured learning path. That is a great method, but one that does not work for me. This is even kind of the point of this post, to state that if you're interested in hiring me and you want somene who has memorized, or can memorize a sdk, then I will not be the right person for the job. I have worked with many components in dozens of different use cases and knowing what type of questions to ask the users, so I then know what components I need to purchase to build their solution.*

The real value in IT and Software Development is everyone understand the needs and abilities and time, then purchasing those lego pieces and wiring them together. It's not that difficult, but it does take some work.

*I had a friend, a fellow developer who spent a month, on contract in the late 1990s, writing a reporting engine in Visual Basic 5. That was simply a waste of time and money, for a fraction of the cost of this developer's time Crystal Reports could be purchased and actual reports could have been created. It was not only a waste of time/money, but the speed of a VB5 application compared to a C++ is going to be much slower, so yet another detriment to the value.