This morning I re-learned a lesson about software development because of an electrician.
An electrician at my office handled an edge case (“don’t flip the switch right now”) with a very simple, and cheap, mechanism – tape.
Simple and cheap, in this case, turns out to be a very effective way to control the behavior of a random and seemingly uncontrollable population, including himself.
The danger ranges from
ahhhh! Bright lights!
to
ZZZch* zzchczzchghhh*!!
depending on the switch we are talking about.
Now, in the software world, stakeholders all too often see their edge cases like this:
There is a time when I don’t want my uncontrollable population to flip this switch / see that data / take that action.
and they react by demanding something like this:
Create a rule that runs on certain conditions for certain people that only allows that switch to be flipped / data to be viewed / action to be taken IF and ONLY IF the possible negative effects will occur.
And…the negative possibilities usually don’t include
ZZZch* zzchczzchghhh*!!
Not even counting how difficult it is to cleanly code and test
* certain conditions
* certain people
* and future negative effects
Generally speaking the most difficult thing is for those same persons to clearly define those self-same parameters.
My point ISN’T to discount those needs – sometimes “certain conditions” is the case, but more frequently than we like to believe, the most effective answer in terms of cost, speed, and capability is still tape.
Stop, think, and consider tape.
blief 
You may want to post/ publish this do somewhere less private. Well said, well presented:) great for a large audience. 2 cents. On fb I would “like” mucho;)
LikeLike
Good point. I can tell by your prose you are working too hard, yearning for a new blog about the wind in your hair :), mermaids or heck, I’d even listen to more about sugar.
Your mother.
LikeLike
“ … the most difficult thing is for those same persons to clearly define … ”
Again, you have captured the essence of the difficulty of much if not all in the life of the innovator/software developer. Generally (almost always!??!!) the “Specifier” is a frustrated “Designer” (who isn’t really capable of designing, but doesn’t know it) who can only think in terms of “how to program” rather than “what is the program supposed to do”.
I believe that a really good designer/software developer might be the best one to write the specifications if he can only squeeze out from the “Boss(es)” what it is that the proposed design/software is supposed to do.
LikeLike