28 February 2005
Decisions, Decisions
24 February 2005
Funny how He knows...
The Dream of an Endeavor
Be My Escape
23 February 2005
Motivation...desired.
22 February 2005
Just a Reflection
21 February 2005
It's not the works...it's not the works...
19 February 2005
Mortimer Rocked
17 February 2005
Tomorrow's the day...
15 February 2005
Eric's a Stud!
14 February 2005
Snot Rock
While cruising the online airwaves, I came across these guys. The band is a called Frickin' A. They've been gaining quite a bit of notoriety lately, especially in Boston during the Series because of their hit Merry Merry Merry Frickin' Christmas.
They've got a real shallow fun sound that is ideal for those of us who like to sing and flail as we drive. According to VH1 they prefer to call their sound Snot Rock, which you can kind of understand after listening to their music. My personal favorite is track #7, but their cover of Jessie's Girl is a fantastic update to a solid classic.
Hear tell their might be a video with a cameo from Springfield himself...
12 February 2005
10 February 2005
Stupid Beautiful Lies: No Cities Left
Smart People Choke Under Pressure
- Bad management.
- Bad management, again.
- Bad design.
- Lack of test-cases.
This was, in my opinion, a solid breakdown of the fundamental risks associated with any engineering endeavor.
My response in both cases is that from my viewpoint they are both oversimplifying the issue. Engineering, in software terms, is the process of converting information into focused tasks and then executing those tasks. But is this what most non-computer engineers would tell you? For example, social engineers, mechanical engineers, even sanitation engineers? Okay, that last one was a little extreme. But my point is we want to put people in buckets. This is something I will always resist in almost any scenario. I just find it rarely ever is productive, but more negatively it reinforces a behavior of isolationism or elitism. These are two of my sworn enemies, but that's a topic for another post. ;-)
The implication in both posts is that they were focusing primarily on software engineers; people who make computer programs. An evolution that has been underway for most of electronic history is breaking down the walls between the analysts or business savvy types and those who can actually create the solutions required by the analysts or business savvy types. The largest software construction engine on the planet is focused on precisely this task. It started way back even before the days of Visual Basic when they were finally able to let just about anyone draw forms and tables on screen without programming. This same evolution continues today in virtually every business product line released, and in many that aren't just for business. Why else would you consistently see advertisements and spam for DVD-ripping software, or graphics editing programs? Do you really think the average in-duh-vidual grasps even a small percentage of how a DVD system works? With the help of software they don't have to. We have removed the necessity for them to have information while enabling them to be independently productive.
What both posts should have been focusing on, again just MHO; is that the art of creating great software and elegant systems falls into the domain of Architects and Designers. In the structural and mechanical industries we call these the Engineers and even require licenses for them. Those people who follow the rules and instructions and execute the steps to construct the finished product are technicians or laborers. If you want to talk about Engineering, don't confuse it with technical labor. If you have issues with the process of development, you have to seperate the implementation from the plan. Until we solidify a mindset that properly seperates these two distinct functions and abilities, the software industry will continue to fall prey to these generalizations and devaluations.
Of course, being primarily an Architect myself, maybe this is just my own form of hypocritical elitism.