There “Shall” Be A Niche

November 23, 2014 6 comments

Someone (famous?) once said that a good strategy to employ to ensure that you get something done is to publicize what you’re going to do for all to see:

Reqs Book Publicity

As you can see, my new found friend, multi-book author Jon M. Quigley (check out his books at Value Transformation LLC), proposed, and I accepted, a collaborative effort to write a book on the topic of product requirements. D’oh!

Why the “D’oh!”? As you might guess, there are a bazillion “requirements” books already out there in the wild. Here is just a sampling of some of those that I have access to via my account:Current Requirements BooksOf course, I haven’t read them all, but I have read both of Mr. Wiegers’s books and the Hatley/Hruschka book – all very well done. I’ve also read two great requirements books (not on the above list) by my favorite software author of all time, Mr. Gerry Weinberg: “Exploring Requirements” and “Are Your Lights On?“.

Jon and I would love to differentiate our book from the current crop – some of which are timeless classics. It’s not that we expect to eclipse the excellence of Mr. Weinberg or Mr. Wiegers, we’re looking for a niche. Perhaps a “Head First” or “Dummies” approach may satisfy our niche “requirement:). Got any ideas?



November 20, 2014 8 comments

Here’s one way of incrementally learning how to generate better estimates:

good estLike most skills, learning to estimate well is simple in theory but difficult in practice. For each project, you track and record the actuals (time, cost, number/experience/skill-types of people) you invest in your project. You then use your historical metrics database to estimate what it should take to execute your next project. You can even supplement/compare your company-specific metrics with industry-wide metrics available from reputable research firms.

It should be obvious, but good estimates are useful for org-wide executive budgeting/allocating of limited capital and human resources. They’re also useful for aiding a slew of other org-wide decisions (do we need to hire/fire, take out a loan, restrict expenses in the short term, etc). Nevertheless, just like any other tool/technique used to develop non-trivial software systems, the process of estimation is fraught with risks of “doing it badly“. It requires discipline and perseverance to continuously track and record project “actuals“. Perhaps hardest of all is the ongoing development and maintenance of a system where historical actuals can be easily categorized and painlessly accessed to compose estimates for important impending projects.

In the worst cases of estimation dysfunction, the actuals aren’t tracked/recorded at all, or they’re hopelessly inaccessible, or both. Foregoing the thoughtful design, installation, and maintenance of a historical database of actuals (rightfully) fuels the radical #noestimates twitter community and leads to the well-known, well-tread, practice of:


Categories: technical Tags: ,


November 17, 2014 Leave a comment

Wanna go on a wildly fun rollercoaster ride? Then watch Erik Meijer’s “One Hacker Way” rant. Right out of the gate, I guesstimate that he alienated at least half of his audience with his opening “if you haven’t checked in code in the last week, what are you doing at a developer’s conference?” question.

I didn’t agree with all of what Erik said (I doubt anyone did), but I give him full credit for sticking his neck out and attacking as many sacred cows as he could: Agile, Scrum, 2 day certification, TDD “waste“, non-hackers, planning poker, the myth of self-organizing teams, etc. Mmmm, sacred cows make the best tasting hamburgers.

Uncle Bob Martin, the self-smug pope who arrogantly proclaimed “If you don’t do TDD, you’re unprofessional“, tried to make light of Erik’s creative rant with this lame blog post: “One Hacker Way!“. Nice try Bob, but we know you’re seething inside because many of your sacredly held beliefs were put on the stand. You seem to enjoy hacking the sacred cows of the reviled “traditional” way of developing software, but it’s a different story when your own cutlets are at steak.

Mr. Meijer pointed out what I, and no doubt many others, have thought for years: agile, particularly Scrum, is a subtle, insidious form of control. At least with explicit, transparent control, one knows the situation and where one stands. With Scrum, the koolaid-guzzling flock is duped into believing they’re in control; all the while being micro-managed with daily standups, burndown charts, velocity tracking, and cutesy terminology. No wonder it’s amassed huge fame and success – managers love Scrum because it makes their job easier and anesthetizes the coders.

My fave laugh-out-loud moment in Erik’s talk was when he presented Jeff Sutherland as the perceived messiah of software development:


I’ve found that the best books and talks are those in which I find some of the ideas enlightening and some revolting. Erik Meijer’s talk is certainly one of those brain-busting gems.

The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function. – F. Scott Fitzgerald

Nice Tatt!

November 15, 2014 Leave a comment

It’s official! I’m the 4,829th member of the “Alice In Wonderland Tattoo Chain“.

Several months ago, I signed up for a kool Kickstarter project whose goal is to create and photograph the world’s largest tattoo chain. The completed project, brilliantly conceived of by Litograph’s Danny Fein, will be comprised of over 5,000 temporary tattoos. Each tattoo is one sentence from Lewis Carroll’s classic book “Alice’s Adventures in Wonderland“.


I received and applied my tattoo last week. I then uploaded a picture of my tatt to the collection site:

Nice TattAfter one week of distribution, over 500 tatt pics have been uploaded. When all 5,000+ tattoos (over 55,000 words) have been uploaded, anyone will be able to read the entire book as one long sequence of online tattoos. Pretty creative, huh?

At, besides tattoos, you can buy T-shirts and other items with the entire text of one of many classic works of literature delicately imprinted on them. I purchased the most appropriate T-shirt I could find for BD00, Machiavelli’s “The Prince:)

The Prince

Regime Change

November 12, 2014 4 comments

Revolution is glamorous and jolting; evolution is mundane and plodding. Nevertheless, evolution is sticky and long-lived whereas revolution is slippery and fleeting.

As the figure below from Neal Ford’s OSCON “Functional Thinking” talk reveals, it took a glacial 16 years for Object-Oriented Programming (OOP) to firmly supplant Procedural Programming (PP) as the mainstream programming style of choice. There was no revolution.

Starting with, arguably, the first OOP language, Simula, the subsequent appearance of Smalltalk nudged the acceptance of OOP forward. The inclusion of object-oriented features in C++ further accelerated the adoption of OOP. Finally, the emergence of Java in the late 90′s firmly dislodged PP from the throne in an evolutionary change of regime.

I suspect that the main reason behind the dethroning of PP was the ability of OOP to more gracefully accommodate the increasing complexity of software systems through the partitioning and encapsulation of state.

Proc to OO

Mr. Ford asserts, and I tend to agree with him, that functional programming is on track to inherit the throne and relegate OOP to the bench – right next to PP. The main force responsible for the ascent of FP is the proliferation of multicore processors. PP scatters state, OOP encapsulates state, and FP eschews state. Thus, the FP approach maps more naturally onto independently running cores – minimizing the need for performance-killing synchronization points where one or more cores wait for a peer core to finish accessing shared memory.

regime change

The mainstream-ization of FP can easily be seen by the inclusion of functional features into C++ (lambdas, tasks, futures) and the former bastion of pure OOP, Java (parallel streams). Rather than cede the throne to pure functional languages like the venerable Erlang, these older heavyweights are joining the community of the future. Bow to the king, long live the king.

Categories: C++ Tags: , , ,

Cry Babies

November 9, 2014 Leave a comment

On Oct. 6, the US Air Force awarded the Raytheon/Saab team a phase-one, four year, $19M, fixed-price contract to deliver 3 long range ground-to-air surveillance radars by 2018. The other two contractors vying for the award were Lockheed Martin (LM) and Nothrup Grumman (NG).

The contract award was expected in early September, but it was pushed back until Oct. 6. That could have been to ensure everything was handled properly to head off a potential protest from either Lockheed Martin or Northrop Grumman.

The total 3DELRR (3 Dimension Expeditionary Long Range Radar) contract value is estimated at $71M, and it requires the Raytheon-led team to produce an additional 3 radars. In the long run, the Air Force plans to procure 29 more radars for a grand total of 35 sensor systems. The total contract effort could span decades and possibly net $1B for the team. In addition, since “exportability” features were baked into the design UP FRONT, Raytheon will have the opportunity to sell many more radars to US allies all over the world without having to be concerned about US foreign technology transfer restrictions.

Since we’re not talkin’ chump change here, you can infer that the losing competitors were not at all happy with the Air Force’s decision – despite the delay to ensure a fair evaluation. But of course, as is standard practice with big government contracts, both losers filed formal protests of the award with the US government’s GAO (General Accounting Office) after they were formally debriefed on why they lost. NG did not publicly specify the grounds for its protest, but LM proclaimed that their offering was “the most affordable and capable solution.

The need to allow for contract award protests is obvious: to ensure that no hanky-panky occurred behind the scenes during the decision-making process. However, since the chances of being successful are small and the protest process is normally a huge waste of time and money for all involved parties, you would think that controls would be in place to prevent every single big ticket award to be protested willy-nilly. But alas, no matter what controls are in effect, a desperate loser can always find a cadre of clever lawyers to skirt the rules.

proposal process

Categories: technical

Abstract Decomposition And Concrete Composition

November 6, 2014 1 comment

On the left we have the process of abstract decomposition, and on the right we have the process of concrete composition:

Decompose And Compose

Note that during the concrete composition from parts to final system on the right, we gracefully transition through two stable, intermediate forms. Some people and communities, especially those obsessed with “velocity” and “time-to-market“, would say “bollocks” to all those value-subtracting, intermediate steps. We no need no stinking intermediate  forms:

direct composition






Get every new post delivered to your Inbox.

Join 471 other followers

%d bloggers like this: