Here’s one way of incrementally learning how to generate better estimates:
Like 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:
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
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:
After 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 Litograph.com, 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” :)
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.
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.
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.
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.
On the left we have the process of abstract decomposition, and on the right we have the process of concrete composition:
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:
As a result of an online Twitter exchange with Mr. Jon Quigley, I was able to purchase a copy of his and Kim Pries’s book, “Project Management Of Complex And Embedded Systems“. In exchange for a half-price deal, I promised to blog a review of the book and, thus, this is it.
As indicated by the book title, the subject matter is all about the methods and tools commonly used by program/project managers for orchestrating large, capital-intensive, multi-disciplined, product development endeavors. Specifically, the content focuses on how the automotive industry successfully manages the development and production of products composed of thousands of electro-mechanical parts and hundreds of networked processors, some of which run safety-critical software. Even though we tend to take them for granted, when you think about it, an automobile is an extremely complex distributed system requiring lots of coordinated mental, physical, and automated, labor to produce.
The book provides comprehensive, yet introductory, coverage of the myriad of tools and processes used in the world of big project management. It’s more of a broad, sweeping, reference book than a detailed step-by-step prescription for executing a specific set of processes. It’s jam packed with lots of useful lists, figures, tables, and graphs. The end of each chapter even includes a specific “war story” experienced by one or both of the authors over their long careers.
As a long time software developer of complex embedded systems in the aerospace and defense industry, much of the book’s subject matter is familiar to me. RFPs, SOWs, WBSs, EVM, BOMs, V&V, SRRs, PDRs, CDRs, TRRs, FMEA, staged-gate phases, prime-subcontractor relationships, master schedules, multi-level approvals, quality metrics, docu-centric information exchanges, etc, are amongst the methods used to facilitate, focus, constrain, and guide end-to-end system development. Many of the chapter-ending war stories tickled my funny bone too!
For the types of projects Mssrs. Pries and Quigley target in the book, kicking off a project at sprint 0 with a self-organizing team of eight cross-functional developers and a primed product backlog of user stories just doesn’t cut it. So, if you’re a young, naive, cloistered software developer or scrum master or product owner who belittles all “traditional“, rigorous, non-agile processes, I highly recommend this book. It will give you a glimpse into a whole different world and broaden your horizons – perhaps allowing you to see both the trees and the forest.