1 |
<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> |