Archive
Functional Allocation III
The figure below shows the movement from the abstract to the concrete through a nested “allocation” process designed for big and complex products (thus, hackers and duct-tapers need not apply). “Shalls” are allocated to features, which are allocated to functions, which are allocated to subsystems, which are allocated to hardware and software modules. Since allocation is labor intensive, which takes time, which takes money, are all four levels of allocation required? Can’t we just skip all the of the intermediate levels, allocate “shalls” to HW/SW modules, and start iteratively building the system pronto? Hmmm. The answer is subjective and, in addition to product size/complexity, it depends on many corpo-specific socio-technical factors. There is no pat answer.
The figure below shows three variations derived from the hypothetical six-level allocation reference template. In the left-most process, two or more product subsystems that will (hopefully) satisfy a pre-existing set of “shalls” are conceived. At the end of the allocation process, the specification artifacts are released to teams of people “allocated” to each subsystem and the design/construction process continues. In the middle process, each SW module, along with the set of shalls and functions that it is required to implement is allocated to a SW developer. In the right process, which, in addition to custom software requires the creation of custom HW, the specification artifacts are allocated to various SW and HW engineers. (Since multiple individuals are involved in the development of the product, the definition of all entity-to-entity interfaces is at least as crucial as the identification and definition of the entities themselves, but that is a subject for another future post.)
Which process variation, if any, is “best”? Again, the number of unquantifiable socio-technical factors involved can make the decision daunting. The sad part is, in order to avoid thinking and making a conscious decision, most corpo orgs ram the full 6 level process down their people’s throats no matter what. To pour salt on the wound, management, which is always on the outside and looking-in toward the development teams, piles on all kinds of non-value-added byzantine approval procedures while simultaneously pounding the team(s) with schedule pressure to compplete. If you’re on the inside and directly creating or indirectly contributing to value creation, it’s not pretty. Bummer.
Archeosclerosis
Archeosclerosis is sclerosis of the software architecture. It is a common malady that afflicts organizations that don’t properly maintain and take care of their software products throughout the lifecycle.
The time lapsed figure below shows the devastation caused by the failure to diligently keep entropy growth in check over the lifetime of a product. On the left, we have a four process application program that satisfies a customer need. On the right, we have a snapshot of the same program after archeosclerosis has set in.
Usually, but not always, the initial effort to develop the software yields a clean design that’s easy to maintain and upgrade. Over time, as new people come on board and the original developers move on to other assignments, the structure starts turning brittle. Bug fixes and new feature additions become swashbuckling adventures into the unknown and lessons in futility.
Fueled by schedule pressure and the failure of management to allocate time for periodic refactoring, developers shoehorn in new interfaces and modules. Pre-existing components get modified and lengthened. The original program structure fragments and the whole shebang morphs into a jagged quagmire.
Of course, the program’s design blueprints and testing infrastructure suffer from neglect too. Since they don’t directly generate revenue, money, time, and people aren’t allocated to keep them in sync with the growing software hairball. Besides, since all resources are needed to keep the house of cards from collapsing, no resources can be allocated to these or any other peripheral activities.
As long as the developer org has a virtual monopoly in their market, and the barriers to entry for new competitors are high, the company can stay in business, even though they are constantly skirting the edge of disaster.
Arrogant And Self-Righteous
I’m currently working on a really difficult assignment that’s starting to put me into an arrogant and self-righteous mood. My task is to add a customer-demanded feature to our flagship product that requires pervasive change throughout 400,000 lines of legacy embedded C++ code. Our flagship product is a software-intensive, distributed real-time sensor system that’s used to provide safety-critical surveillance information to our customers.
This is actually the third try at getting this task done. The first two attempts by other people fizzled out with nary a whimper. They were in way over their heads and thus, the work that they left behind is useless to me. So here I am, reverse-engineering 100s of thousands of lines of algorithmically deep code to:
- try and figure out what the current code base does
- try and understand why the code does what it does
- determine what changes need to be made to which code sections in order to implement the feature
This task is hard, really hard, but I’m up to it. The work requires long periods of sustained immersion in the code base and the mental absorption and retention of many fragile and diverse associations. Way more than Miller’s famous 7 plus or minus 2 limit of individual human capacity. I’m not getting any deep help and I’ve got two (yes two) managers taking “status” and watching the schedule . Other well-meaning product team members do help out when I ask them, but they just provide tidbits of help here and there. Help from the managers? Fuggedaboud it. It’s not their “job”, and they don’t have the expertise to help out even if they wanted to (which they don’t). Don’t get me wrong. They’re both good people and I like them very much, but they just can’t help, period.
Alas, I feel that I’m virtually all alone on this effort and it’s making me arrogant, self-righteous, and mad. Why’s it making me mad? Because I don’t feel appreciated and I feel that no one, save for one other person, has any idea of the inherent difficulty baked into the project. I look at what I’m doing, compare it with what others around me are doing, and then I ask myself “why did I willingly sign up for this type of work – again“? When the job gets finished, I’ll in all likelihood just get an “atta boy” and the same average raise as everyone else – just as has happened several times in the past. Thank God that I’m internally motivated to grow and learn.
Boo hoo, poor me!
Sassy!
The SAS Institute has been one of my favorite software companies to watch over the years. They were like Google before Google. The reason that I’m mentioning SAS is because while I was browsing through my notes, I stumbled upon this quote from a SAS manager:
Nothing corrodes respect between a boss and an employee more quickly than the sense that the boss has no idea what the employee is doing. Managers who understand the work that they oversee can make sure that details don’t slide. At SAS, groups agree on deadlines, and managers understand what their groups do — so unrealistically optimistic promises about time-tables and completion dates are relatively rare.
The quote came from this 2004 article in Fast Company magazine: Sanity Inc. The quote struck a chord with me back then, and it still does now. In my case, I don’t necessarily disrespect a manager that doesn’t know what I’m doing. I disrespect managers who:
- Are apathetic and show no interest in what I’m doing, regardless of whether they know the subject matter or not.
- Don’t ask me how I’m doing, and how they can help me do my job better, regardless of whether they know the subject matter or not.
- Just stop by only when they need to collect status, without wanting to hear about any bureaucratic procedural roadblocks that are, or specific people who are, hindering my progress.
- Pretend to know what I’m doing and make suggestions on what to do next, even though we both know (or, at least I know) that the manager has no clue.
How about you? What causes you to lose respect for your manager(s)?
Upstream Bullies
In the aerospace and defense industry, a system engineer is the equivalent of a business analyst. They’re supposed to specify and record clear and unambiguous software requirements for the software development team, and then help the team get the requirements right.
In my experience, excellent system engineers are very hard to come by. The vast majority of them drop open-ended one line bombshells like “The system shall detect targets with a probability of detection of 95%” on the development team. Then these “shallocators” disconnect and distance themselves from the programming team and morph into glorified project managers, but without the responsibility. I call these types of system engineers upstream bullies because they’re always looking over your shoulder and telling you how to do your job even though they’ve never written anything bigger than “Hello World!”. Upstream bullies also demand that programmers dot the I’s and cross the T’s even though their own work, which is the input to the software team’s work, is a useless POS.
Ever wonder why you frequently read about large software-intensive government projects that are massively late and over budget? Besides poor leadership, another big reason is that upstream bullies are at work. If you’re a software developer and you have a choice, stay away from upstream bully shall-meisters.
How And What
“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” – George S. Patton
One of my pet peeves is when a bozo manager dictates the how, but has no clue of the what – which he/she is supposed to define:
“Here’s how you’re gonna create the what (whatever the what ends up being): You will coordinate Fagan inspections of your code, write code using Test First Design, comply with the corpo coding standards, use the corpo UML tool, run the code through a static analyzer, write design and implementation documents using the corpo templates, yada-yada-yada. I don’t know or care what the software is supposed to do, what type of software it is, or how big it will end up being, but you shall do all these things by this XXX date because, uh, because uh, be-be-because that’s the way we always do it. We’re not burger king, so you can’t have it your way.”
Focusing on the means regardless of what the ends are envisioned to be is like setting a million monkeys up with typewriters and hoping they will produce a Shakespear-ian masterpiece. It’s a failure of leadership. On the other hand, allowing the ends to be pursued without some constraints on the means can lead to unethical behavior. In both cases, means-first or ends-first, a crappy outcome may result.
On the projects where I was lucky to be anointed the software lead in spite of not measuring up to the standard cookie cutter corpo leadership profile, I leaned heavily toward the ends-first strategy, but I tried to loosely constrain the means so as not to suffocate my team: “eliminate all compiler warnings, code against the IDD, be consistent with your coding style, do some kind of demonstrable unit and integration testing and take notes on how you did it.”
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 