Posts Tagged ‘postaday2011’

Holiday Cheer!

December 25, 2012 Leave a comment

Butt The Schedule

January 14, 2012 1 comment

Did you ever work on a project where you thought (or knew) the schedule was pulled out of someone’s golden butt? Unlucky you, cuz Bulldozer00 never has.

Maintenance Cycles And Teams

January 13, 2012 Leave a comment

The figure below highlights the unglamorous maintenance cycle of a typical “develop-deliver-maintain” software product development process. Depending on the breadth of impact of a discovered defect or product enhancement, one of 4 feedback loops “should” be traversed.

In the simplest defect/enhancement case, the code is the only product artifact that must be updated and tested. In the most complex case, the requirements, architecture, design, and code artifacts all “should” be updated.

Of course, if all you have is code, or code plus bloated, superficial, write-once-read-never documents, then the choice is simple – update only the code. In the first case, since you have no docs, you can’t update them. In the second case, since your docs suck, why waste time and money updating them?

After the super-glorious business acquisition phase and during the mini-glorious “initial development” phase, the team is usually (but not always – especially in DYSCOs and CLORGs) staffed with the roles of domain analyst(s), architect(s), designer(s), and programmer(s). Once the product transitions into the yukky maintenance phase, the team may be scaled back and roles reassigned to other projects to cut costs. In the best case, all roles are retained at some level of budgeting – even if the total number of people is decreased. In the worst case, only the programmer(s) are kept on board. In the suicidal case, all roles but the programmer(s) are reassigned, but multiple manager type roles are added. (D’oh!)

Note that there does not have to be a one to one correspondence between a role and a person; one person can assume multiple roles. Unfortunately, the staff allocation, employee development, and reward systems in most orgs aren’t “designed” to catalyze and develop the added value of multi-role-capable people. That’s called the “employee-in-a-box” syndrome.

Can’t And May

January 7, 2012 Leave a comment

The Mythical Dual Ladder

January 4, 2012 11 comments

The figure below shows a typical skill development timeline. At “t=0” ignorance reigns and learning begins. After a period of learning/applying/practicing, which varies widely from person to person, the status of “Novice” is achieved. After yet another period of learning/applying/practicing, the transition from novice to amateur occurs – and so on up to the level of master and beyond.

The key attribute to focus on in the timeline is the change in length of time required to transition from one level of competence to the next. It doesn’t stay the same or get smaller, it gets longer. Thus, with exceptions of course, the time required to transition from expert to master is greater than the time to transition from amateur to expert.

To remain viable, every product development company requires a critical mass of expertise in the core technologies that comprise the soul of its product portfolio. World class companies actively “nourish and catalyze” the novice-to-expert pipeline via continuous investments in targeted training and conference attendance. Average companies neither nourish or catalyze the pipeline, they “hope for the best” in that their employees will keep up with technology advancements on their own time. In the extreme, CLORGS and DYSCOs unconsciously “toxify and inhibit” the pipeline – if one is even recognized at all. They do this by implicitly encouraging experts to move out of technology and into management via higher compensation and stature for those experts/masters who jump from the mythical technical ladder to the coveted management ladder.

Finish Line

December 31, 2011 Leave a comment

Phew, I think I did it! I think I wrote and published 365 ridiculous blog posts in 2011. I successfully conquered the “post a day 2011” challenge. Woot!

Alas, it wasn’t really that hard; I never shut up, I’m a hopeless ruminator, and I’m so full of crap that the words and dorky pictures seem to flow effortlessly out of nowhere and onto the e-canvas.

So, since I’m sure that I’m the only one who accomplished this great feat of daring, where is my freakin’ ONE……….. MILLION……………….. DOLLARS?

As a note of thanks, I gotta give a huge-uh shout out to the brilliant and caring people at automattic who created and constantly innovate on the wordpress web site platform. It’s a joy to work with your product because it virtually disappears into the background when I’m concocting my dorky posts. I hope the profits are rollin’ in, and keep up the great work!

Categories: miscellaneous Tags: ,

BMs Of The Year

December 30, 2011 2 comments

Since BD00 is a bombastic and boisterous blasphemer of the “B” word, I just HAD to meta-blog about this infoworld blog post after I stumbled upon it: “The tech industry’s biggest bozos of 2011”.

And the winners are…..

Because Netflix is one of the companies on my faves list (and I’m a stockholder!), I’m really bummed about the Hastings-Netflix fiasco. Since I think Mr. Hastings and Netflix will recover from the faux pas, I’m keeping them on the list.

Graphics, Text, And Source Code

December 29, 2011 3 comments

On the left, we have words of wisdom from Grady Booch and friends. On the right, we have sage advice hatched from the “gang of four“. So, who’s right?

Why, both groups are “right“. If all you care about is “recording the design in source code“, then you’re “wrong“…

If you’re a software “anything” (e.g. architect, engineer, lead, manager, developer, programmer, analyst) and you haven’t read these two classics, then either read them or contemplate seeking out a new career.

But wait! All may not be lost. If you think object orientation is obsolete and functional programming is the way of the future, then forget (almost) everything that was presented in this post.

What Would You Do?

December 28, 2011 1 comment

Assume that you’re working on a software system comprised of a set of core and peripheral application components. Also assume that these components rest on top of a layered set of common system libraries.

Next, assume that you remove some functionality from a system library that you thought none of the app components are using. Finally, assume that your change broke multiple peripheral apps, and, after finding out, the apps writer asked you nicely to please restore the functionality.

What would you do?

Capers And Salmon

December 27, 2011 4 comments

I like capers with my salmon. In general, I also like the work of long time software quality guru Capers Jones. In this Dr. Dobb’s article, “Do You Inspect?”, the caped one extols the virtues of formal inspection. He (rightly) states that formal, Fagan type, inspections can catch defects early in the product development process – before they bury and camouflage themselves deep inside the product until they spring forth way downstream in the customer’s hands. (I hate when that happens!)

The pair of figures below (snipped from the article) graphically show what Capers means. Note that the timeline implies a long, sequential, one-shot, waterfall development process (D’oh!).

That’s all well and dandy, but as usual with mechanistic, waterfall-oriented thinking, the human aspects of doing formal inspections “wrong” aren’t addressed. Because formal inspections are labor-intensive (read as costly), doing artifact and code inspections “wrong” causes internal team strife, late delivery, and unnecessary budget drain. (I hate when that happens!)

An agile-oriented alternative to boring and morale busting “Fagan-inspections-done-wrong” is shown below. The short, incremental delivery time frames get the product into the hands of internal and external non-developers early and often. As the system grows in functionality and value, users and independent testers can bang on the system, acquire knowledge/experience/insight, and expose bugs before they intertwine themselves deep into the organs of the product. Working hands-on with a product is more exhilarating and motivating than paging through documents and power points in zombie or contentious meetings, no?

Of course, it doesn’t have to be all or nothing. A hybrid approach can be embraced: “targeted, lightweight inspections plus incremental deliveries with hands-on usage”.

%d bloggers like this: