| 1 |
dashley |
23 |
<html> |
| 2 |
|
|
|
| 3 |
|
|
<head> |
| 4 |
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> |
| 5 |
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> |
| 6 |
|
|
<meta name="ProgId" content="FrontPage.Editor.Document"> |
| 7 |
|
|
<title>Dave's Observations And Thoughts About Bad Management In Embedded |
| 8 |
|
|
Software Development</title> |
| 9 |
|
|
<base target="main"> |
| 10 |
|
|
<bgsound src="../../../gensounds/austin_powers/beat_drevil.wav" loop="0"> |
| 11 |
|
|
</head> |
| 12 |
|
|
|
| 13 |
|
|
<body background="../../../bkgnds/bk10.gif"> |
| 14 |
|
|
|
| 15 |
|
|
<p align="center"><b><font size="5">Dave's Observations And Thoughts About Bad |
| 16 |
|
|
Management In Embedded Software Development</font></b></p> |
| 17 |
|
|
<hr> |
| 18 |
|
|
<p><b><u>Bookmarks</u></b></p> |
| 19 |
|
|
|
| 20 |
|
|
<ul> |
| 21 |
|
|
<li><a href="#intro" target="_self">Introduction</a></li> |
| 22 |
|
|
<li><a href="#what_achieve" target="_self">What Is One Trying To Achieve In A Software |
| 23 |
|
|
Development?</a></li> |
| 24 |
|
|
<li><a href="#perfdil_immat_man" target="_self">Performance Dilution By Technically Immature |
| 25 |
|
|
Management</a></li> |
| 26 |
|
|
<li><a href="#coevolution" target="_self">Co-Evolution</a></li> |
| 27 |
|
|
<li><a href="#light_bulb_analogy" target="_self">The Light Bulb Analogy</a></li> |
| 28 |
|
|
<li><a href="#emotional_manipulation" target="_self">Emotional Manipulation Of Employees</a></li> |
| 29 |
|
|
<li><a href="#recognize_but_resist" target="_self">Recognizing Problems But Resisting |
| 30 |
|
|
Solutions</a></li> |
| 31 |
|
|
</ul> |
| 32 |
|
|
<hr> |
| 33 |
|
|
<p><b><u><a name="intro"></a>Introduction</u></b></p> |
| 34 |
|
|
|
| 35 |
|
|
<p>I (Dave Ashley) have become really cautious about which recruiters I deal |
| 36 |
|
|
with, which employment interviews I consent to, and which job offers I accept. |
| 37 |
|
|
Understandably, my caution comes from experience.</p> |
| 38 |
|
|
|
| 39 |
|
|
<p>Generally speaking, the management in the auto industry involved with the |
| 40 |
|
|
development of small embedded systems is the <i>worst</i> |
| 41 |
|
|
management I've seen anywhere. The general components of the poor |
| 42 |
|
|
management performance and low-quality work environments are discussed at some length in |
| 43 |
|
|
the following sections.</p> |
| 44 |
|
|
|
| 45 |
|
|
<p>Some might claim I have a <i>bad attitude</i>. Nothing could be further |
| 46 |
|
|
from the truth. In most cases the key issue is an elusive quality that |
| 47 |
|
|
I'll call <i>technical maturity</i>. Some people (specifically, the bad |
| 48 |
|
|
supervisors and managers I've had the dishonor of working with) go their entire careers and never grasp |
| 49 |
|
|
the essential nature of the technical and management problems they confront on a |
| 50 |
|
|
daily basis. That <i>failure to technically mature</i> does not make these |
| 51 |
|
|
individuals <i>morally</i> defective--it just makes them <i> technically</i> |
| 52 |
|
|
defective. My desire to distance myself from such individuals doesn't come |
| 53 |
|
|
from anti-social tendencies; but rather from the self-preservation |
| 54 |
|
|
instinct.</p> |
| 55 |
|
|
|
| 56 |
|
|
<p>I'm very much reminded of a quote from one of the Superman movies where Lex |
| 57 |
|
|
Luthor (Gene Hackman) <font size="6">(</font><img border="0" src="lex_luthor.jpg" align="absmiddle" hspace="5" vspace="5" width="53" height="73"><font size="6">)</font> |
| 58 |
|
|
delivers a line something like, "<i>Otis, why is it that some people can |
| 59 |
|
|
read the list of ingredients on a chewing gum wrapper and unlock the secrets of |
| 60 |
|
|
the universe while others can read `War and Peace' and come away thinking it is |
| 61 |
|
|
a simple adventure novel?</i>". How true, Lex, how true! Some |
| 62 |
|
|
people don't get it and won't <i> ever</i> get it.</p> |
| 63 |
|
|
|
| 64 |
|
|
<p>Much of the remainder of this page is devoted to observations about |
| 65 |
|
|
management that has failed to technically mature.</p> |
| 66 |
|
|
|
| 67 |
|
|
<hr> |
| 68 |
|
|
<p><b><u><a name="what_achieve"></a>What Is One Trying To Achieve In Software |
| 69 |
|
|
Development?</u></b></p> |
| 70 |
|
|
<p>Before slamming bad management for failing to <i>get it</i>, one should state |
| 71 |
|
|
what it is that needs to be gotten. What is one trying to achieve in |
| 72 |
|
|
software development?</p> |
| 73 |
|
|
|
| 74 |
|
|
<p>On the administrative side, the bare minimum that one is trying to achieve is |
| 75 |
|
|
<i><b>administrative neatness</b></i>. In modern software development, neatness |
| 76 |
|
|
is <i>not</i> neatly-labeled file folders and <i>Microsoft Word</i>® |
| 77 |
|
|
documents with attractive cover pages and attractive headers and |
| 78 |
|
|
footers. <i>Neatness</i> is a <b> comprehensive information management plan</b> |
| 79 |
|
|
that:</p> |
| 80 |
|
|
|
| 81 |
|
|
<ul> |
| 82 |
|
|
<li><b>Minimizes reliance on paper.</b> Treeware <i>is</i> necessary |
| 83 |
|
|
sometimes. Personally, I've found that when I'm reviewing something |
| 84 |
|
|
complex I <i>must</i> have it on paper. However, web-based databases |
| 85 |
|
|
and paperless technologies are now the norm.</li> |
| 86 |
|
|
<li><b>Addresses the needs and usage scenarios of everyone who participates in |
| 87 |
|
|
the software development.</b> Everyone who participates in software |
| 88 |
|
|
development or testing needs electronic resources to store their work |
| 89 |
|
|
products.</li> |
| 90 |
|
|
<li><b>Minimizes redundancy of information.</b> Although it is |
| 91 |
|
|
impossible to eliminate information redundancy entirely, one must make a |
| 92 |
|
|
best attempt. The <i>first</i> level of attempt is to have a <i>policy</i> |
| 93 |
|
|
for where all product development information is stored: this prevents |
| 94 |
|
|
unnecessary redundancy because all employees know where each type of |
| 95 |
|
|
information should be stored. The <i>second</i> level of attempt is to |
| 96 |
|
|
complement any policy weaknesses with tools that maintain information |
| 97 |
|
|
consistency automatically. Unfortunately, most software development |
| 98 |
|
|
organizations do not even make it to the first level of attempt.</li> |
| 99 |
|
|
</ul> |
| 100 |
|
|
|
| 101 |
|
|
<p>On the human resources side, the bare minimum one is trying to achieve |
| 102 |
|
|
is to <i><b>create the most rewarding experience for the top 10% of technical |
| 103 |
|
|
contributors</b></i>. Not all engineers or employees contribute |
| 104 |
|
|
equally. The 10% of engineers/employees that contribute the most |
| 105 |
|
|
technically to product development tend to have unstable personalities (these |
| 106 |
|
|
are the people you want to keep away from customers, for example). These |
| 107 |
|
|
individuals tend to strive for technical excellence, and don't tolerate |
| 108 |
|
|
environments that dilute their productivity. So, it makes sense for an |
| 109 |
|
|
employer to try to create an environment free of performance obstacles so as to |
| 110 |
|
|
be able to retain these individuals.</p> |
| 111 |
|
|
<p>I'm not claiming that an employer needs to <i>identify</i> the top 10% of |
| 112 |
|
|
technical contributors in order to be effective at retaining these |
| 113 |
|
|
people. All that is necessary is to create an environment where those |
| 114 |
|
|
who wish to perform can do so.</p> |
| 115 |
|
|
<p>It may be difficult to for the reader to envision a scenario that creates a |
| 116 |
|
|
low-quality experience for a solid technical contributor. A concrete |
| 117 |
|
|
example is that "coding standards" example, which I present next in |
| 118 |
|
|
the section <a href="#perfdil_immat_man" target="_self">Performance Dilution By Technically |
| 119 |
|
|
Immature Management</a>.</p> |
| 120 |
|
|
<hr> |
| 121 |
|
|
<p><b><u><a name="perfdil_immat_man"></a>Performance Dilution By Technically |
| 122 |
|
|
Immature Management</u></b></p> |
| 123 |
|
|
<p>One phenomenon that drives away gifted engineers is <i>performance dilution |
| 124 |
|
|
by technically immature management</i>. The nature of the phenomenon is |
| 125 |
|
|
that management often doesn't understand the work or the nature of the work well |
| 126 |
|
|
enough to make sound decisions; and some of the decisions (or failures to make |
| 127 |
|
|
decisions) invariably lower the quality of life for engineers. The most |
| 128 |
|
|
gifted engineers tend to have the strongest desire to contribute to the |
| 129 |
|
|
company's productivity, and so these decisions tend to frustrate the most gifted |
| 130 |
|
|
engineers into leaving the company. The net effect is to place an upper |
| 131 |
|
|
limit on the caliber of employees the company can retain.</p> |
| 132 |
|
|
<p>The phenomenon of differentially frustrating employees is also mentioned by |
| 133 |
|
|
Colin Powell in his awesome presentation, <i>A Leadership Primer</i> (available <a href="powellonleadership.zip">here</a> |
| 134 |
|
|
as a .ZIP'd PowerPoint presentation). The bottom line is that the most |
| 135 |
|
|
productive employees are most sensitive to obstacles to their |
| 136 |
|
|
productivity. The graphic below is from Powell's presentation.</p> |
| 137 |
|
|
<p align="center"><img border="0" src="powell_01.gif" width="720" height="540"></p> |
| 138 |
|
|
<p>One example from my own career is the issue of <i>coding standards</i>. |
| 139 |
|
|
At one point in my career with a large company, I was given responsibility for |
| 140 |
|
|
products that were politely called <i>legacy products</i>. <i>Legacy |
| 141 |
|
|
products</i> was a euphemism for products that had been poorly-designed and |
| 142 |
|
|
modified too many times.</p> |
| 143 |
|
|
<p>Each file that I opened in these legacy products contained inconsistent |
| 144 |
|
|
indentation and a mixture of space and tab characters (something that is |
| 145 |
|
|
prohibited by most coding standards). Because 'C' functions in embedded |
| 146 |
|
|
work can be quite lengthy, the net result is that I had to replace all tabs |
| 147 |
|
|
with spaces and then manually indent about 10,000 lines of code. It was an |
| 148 |
|
|
unpleasant experience.</p> |
| 149 |
|
|
<p>During the experience, I discussed with my boss the need for coding standards |
| 150 |
|
|
that prohibit tab characters in source files. He was unenthusiastic about |
| 151 |
|
|
coding standards in general, and nothing ever got done. The net result was |
| 152 |
|
|
sure to be that more source files with inconsistent indentation were coming my |
| 153 |
|
|
way.</p> |
| 154 |
|
|
<p>The general trend with bad management is:</p> |
| 155 |
|
|
<ul> |
| 156 |
|
|
<li>Engineers will suggest process, technical, or administrative improvements |
| 157 |
|
|
to management. (Often, these suggestions come directly from situations |
| 158 |
|
|
in the work place that are lowering the quality of life for engineers.)</li> |
| 159 |
|
|
<li>The management will not be technically mature enough to understand the |
| 160 |
|
|
merit of the suggestions and/or will be insensitive to the way in which the |
| 161 |
|
|
current situation lowers the quality of work life for engineers.</li> |
| 162 |
|
|
<li>The suggestions will not be implemented at all, or in a best case some of |
| 163 |
|
|
the suggestions will be implemented (but always the suggestions--usually the |
| 164 |
|
|
least strategically important ones--that are consistent with the technical |
| 165 |
|
|
maturity of the management).</li> |
| 166 |
|
|
<li>The most gifted engineers (who are usually more sensitive to the |
| 167 |
|
|
frustration) leave the company.</li> |
| 168 |
|
|
</ul> |
| 169 |
|
|
|
| 170 |
|
|
<hr> |
| 171 |
|
|
<p><b><u><a name="coevolution"></a>Co-Evolution</u></b></p> |
| 172 |
|
|
<p>One question I often ask myself is "<i>How did things get so bad in |
| 173 |
|
|
small embedded work?</i>".</p> |
| 174 |
|
|
<p>I'm convinced that the answer lies in evolution and co-evolution. From |
| 175 |
|
|
time to time, one may watch a nature special where in some dark cave with a |
| 176 |
|
|
closed ecosystem, a species of blind fish has evolved. Blind fish can |
| 177 |
|
|
exist in such an environment because they do not need to see.</p> |
| 178 |
|
|
<p>Similarly, I'm convinced that the poor management skills abundant in small |
| 179 |
|
|
embedded work come from the environment. Every project is small enough |
| 180 |
|
|
that one can just keep throwing people at it and somehow the work will get done, |
| 181 |
|
|
even without a design. Skill <i>is not</i> necessary. A large pool |
| 182 |
|
|
of young energetic engineers who are easily deceived and manipulated <i>is</i> |
| 183 |
|
|
necessary.</p> |
| 184 |
|
|
<p>In projects of higher complexity, the same approach would fail miserably.</p> |
| 185 |
|
|
<p><b>Q:</b> Why are the supervisors and managers of small embedded |
| 186 |
|
|
software products so bad?</p> |
| 187 |
|
|
<p><b>A:</b> Because they <i>can</i> be (the complexity of the product |
| 188 |
|
|
allows it). </p> |
| 189 |
|
|
<hr> |
| 190 |
|
|
<p><b><u><a name="light_bulb_analogy"></a>The Light Bulb Analogy</u></b></p> |
| 191 |
|
|
<p> </p> |
| 192 |
|
|
<p> </p> |
| 193 |
|
|
<hr> |
| 194 |
|
|
<p><b><u><a name="emotional_manipulation"></a>Emotional Manipulation Of |
| 195 |
|
|
Employees</u></b></p> |
| 196 |
|
|
<p> </p> |
| 197 |
|
|
<hr> |
| 198 |
|
|
<p><b><u><a name="recognize_but_resist"></a>Recognizing Problems But Resisting |
| 199 |
|
|
Solutions</u></b></p> |
| 200 |
|
|
<p> </p> |
| 201 |
|
|
|
| 202 |
|
|
<hr> |
| 203 |
|
|
<p align="center" style="margin-top: -2; margin-bottom: -1"><font size="1">Sound |
| 204 |
|
|
credit: The <i>Austin Powers</i> series of films starring Mike Meyers.<br> |
| 205 |
|
|
This |
| 206 |
|
|
web page is maintained by <a href="mailto:dtashley@users.sourceforge.net">David |
| 207 |
|
|
T. Ashley</a>.<br>$Header: /cvsroot/esrg/sfesrg/esrgweba/htdocs/authindiv/dtashley/bad_management/index.html,v 1.7 2003/05/10 00:28:43 dtashley Exp $</font></p> |
| 208 |
|
|
<hr noshade size="5"> |
| 209 |
|
|
|
| 210 |
|
|
</body> |
| 211 |
|
|
|
| 212 |
|
|
</html> |
Parent Directory
| 
Revision Log