Just Touch Me Once More!!!
I keep finding myself being drawn more and more into circular Twitter debates with self-proclaimed software development gurus, many of whom who write books and give speeches for a living. On the upside, I’m thrilled that Twitter gives me the opportunity to interact in near-real-time with people I never thought I’d have the chance to otherwise communicate with. On the downside, I do not enjoy the increasing amounts of time and energy it takes to steer these oft head-banging conversations toward a graceful closure where neither side feels dissed.
The topic of software development is simply too context-dependent to arrive at a sweeping consensus on almost anything of non-trivial importance. Trying to get someone who develops software in the context of the aerospace & defense industry to fully agree with someone who develops IT web sites or mobile game apps for a living is like trying to get republicans and democrats to agree on… anything.
But alas, I’m such a sucker for instigating and perpetuating incendiary, no-win, arguments. Like this famously hilarious scene in OFOTCN between Taber and Harding, I’m genetically inclined to frequently behave online (and offline) as an obnoxious “poker“:
If you’re a natural born “poker“, deploy your poking skills at work only on peers. My experience has been that the practice of “poking” management, at any level in the hierarchy, never works – ever. It doesn’t matter what your message is. The fact that you’re delivering it with the tip of your poker is the only thing that matters. So, when it comes to management, keep your poker in your pants.
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
You sure can spin a yarn Tony! My poker got iced by management a few times in my life. Hah!
“The topic of software development is simply too context-dependent to arrive at a sweeping consensus on almost anything of non-trivial importance.”
That’s what I use as a moron test…anyone who believes in THE WAY gets tuned out.
There seems to be – at least in the non-defense and space domain – that developers have better ideas than managers of developers and managers of the business of software development. It goes downhill from there.
In A&D that is not the case, since the developers are considered “software engineers” and lumped with other engineers in the org chart. As “engineers” they know that “engineering” the solution to complex, emergent, evolving requirements of mission critical software intensive systems is just that – an engineering discipline.
I suspect as well, that the “Dilbert” style managers are more prevalent outside out A&D domain because of the engineering discipline paradigm.
There is discussion at our local university of separating “programming” paths from “engineering” paths in the CS departments. The local A&D firms are looking for engineers not rogue organized hackers so cherished by startups in the internet and gaming domain.
I agree that there are probably more Dilbert bosses outside of the A&D domain. Between that and the massive uptake of Agile methods, developers seem to have become more arrogant over the years.
I am afraid I am also suffering from poke mentality. I recall recent experience as a test and verification manager for a company in the automotive industry. It was late in the project, and the project was an emissions related project. That means governmental mandated change and a hard deadline. Many of the vehicle systems were under alteration and some under development which was part of the problem (http://www.valuetransform.com/project-scope-strategy-risk/). There were less complicated (less risky) ways of achieving the objective, but I digress.
Late in the project, the VP of Engineering comes to me and wants to know how testing of the system can happen quicker. I told him, we are continuously automating what can be automated, that the system changes are quite extensive meaning a couple thousand test cases. To make matters worse, after testing less than 10% of the total test cases, we find many failures of which a significant portion or very critical. For every system iteration numerous and sever issues were found. So much so, that any attempt at predicting when the quality will sufficient for release was impossible. A good many of these serious failures were found in previous releases, went away in a subsequent release and were witnessed again yet a later release. I suggested he direct his attention toward the development personnel, especially a key subsystem supplier. He informed me that he would not have that discussion with our partner supplier, but instead decided to keep pressuring verification to do the improbable given the defect arrival rate. I told him his problem was not entirely a verification problem but a development issue as well. Then, much like Phillipneumiller, I had my poker iced.
Thanks for the war story Jon. In my experience, that’s typical one dimensional executive behavior. Always wanting stuff faster – with no mention of, or concern for, the risk of quality degradation with an increase in speed.
Even worse for me Tony, was the fact that the delivery from the supplier was a significant source of the problem. Yet, this executive would not even consider some review into why the deliveries were not even under a modicum of control. Recurring problems (build control issues?) and many other systemic type issues. This was not a verification problem – the problem manifest in verification, we only find what is delivered. All of that fell on deaf ears.