Archive
Software Reuse
As a follow up to my last post, I decided to post this collection of quotes on software reuse from some industry luminaries:
Planned? Top-down? Upfront? In this age of “agile“, these words border on blasphemy.
The Odds May Not Be Ever In Your Favor
The sketch below models a BD00 concocted reference cost curve for a single, one-off, software-intensive product. Note that since the vast majority of the accumulated cost (up to 3/4 of it according to some experts) of a long-lived product is incurred during the sustainment epoch of a product’s lifetime, the graph is not drawn to scale.
If you’re in the business of providing quasi-similar, long-lived, software-intensive products in a niche domain, one strategy for keeping sustainment costs low is to institutionalize a Software Product Line Approach (SPLA) to product development.
A software Product Line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. – Software Engineering Institute
As the diagram below shows, the idea behind the SPLA is to minimize the Total Lifetime Cost by incurring higher short-term costs in order to incur lower long-term costs. Once the Product Line infrastructure is developed and placed into operation, instantiating individual members of the family is much less costly and time consuming than developing a one-off implementation for each new application and/or customer.
Some companies think themselves into a false sense of efficiency by fancying that they’re employing an SPLA when they’re actually repeatedly reinventing the wheel via one-off, copy-and-paste engineering.
You can’t copy and paste your way to success – Unknown
If your engineers aren’t trained in SPLA engineering and you’re not using the the terminology of SPLA (domain scoping, core assets, common functionality, variability points, etc) in your daily conversations, then the odds may not be ever in your favor for reaping the benefits of an SPLA.
Related articles
- Out Of One, Many (bulldozer00.com)
- Product Line Blueprint (bulldozer00.com)
Beginner, Intermediate, Expert
Check out this insightful quote from Couchbase CTO Damien Katz:
Threads are hard because, despite being extremely careful, it’s ridiculously easy to code in hard to find, undeterministic, data races and/or deadlocks. That’s why I always model my multi-threaded programs (using the MML, of course) to some extent before I dive into code:
Note that even though I created and evolved (using paygo, of course) the above, one page “agile model” for a program I wrote, I still ended up with an infrequently occurring data race that took months, yes months, to freakin’ find. The culprit ended up being a data race on the (supposedly) thread-safe DB2 data structure accessed by the AT4, AT6, and AT7 threads. D’oh!
Don’t Do This!
Because of its oxymoronic title, I started reading Paul McMahon’s “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement“. For CMMI compliant orgs (Level >= 3) that wish to operate with more agility, Paul warns about the “pile it on” syndrome:
So, you say “No org in their right mind would ever do that“. In response, BD00 sez “Orgs don’t have minds“.
Ultimately And Unsurprisingly
Take a look at the latest, dorky, BD00 diagram below. The process model on the left is derived from the meaty, 482 page CMMI-DEV SEI Technical Report. The model on the right is derived from the lean, 16 page Scrum Guide.
Comparing CMMI-DEV and Scrum may seem like comparing apples to oranges, but it’s my blog and I can write (almost) whatever I want on it, no?
Don’t write what you know, write what you want to know – Jerry Weinberg
The overarching purpose of both process frameworks is to help orgs develop and sustain complex products. As you can deduce, the two approaches for achieving that purpose appear to be radically different.
The CMMI-DEV model is comprised of 22 practice areas, each of which has a number of specific and generic practices. Goodly or badly, note that the word “practice” dominates the CMMI-DEV model.
Unlike the “practice” dominated CMMI-DEV model, the Scrum model elements are diverse. Scrum’s first class citizens are roles (people!), events, artifacts, and the rules of the game that integrate these elements into a coherent socio-technical system. In Scrum, as long as the rules of the game are satisfied, no practice is off limits for inclusion into the framework. However, the genius inclusion of time limits for each of Scrum’s 4 event types implicitly discourages heavyweight practices from being adopted by Scrum implementers and practitioners.
Of course, following either model or some hybrid combo can lead to product quality/time/budget success or failure. Aficionados on both sides of the fence publicly tout their successes and either downplay their failures (“they didn’t understand or really follow the process!“) or they ignore them outright. As everyone knows, there are just too many freakin’ metaphysical factors involved in a complex product development effort. Ultimately and unsurprisingly, success or failure comes down to the quality of the people participating in the game – and a lot of luck. Yawn.
Great, But Weird And Slow
Damien Katz is the soft-spoken Couchbase CTO and creator of the Apache CouchDB (written in Erlang and C/C++). In this InfoQ presentation, “Erlang, the Language from the Future?“, Damien praises the Erlang programming language. But he also points out its turds: weirdness and slowness.
Damien says that Erlang’s weird Prolog-like syntax prevents massive adoption; which prevents lack of massive investment; which prevents massive VM performance improvement.
To prove his point, Mr. Katz uses Java as an example of “getting it right“. When Java arrived on the scene in the mid-90’s, it was dirt slow compared to C and C++. But because Java’s syntax was C-like and it didn’t suffer from the frustrating quirks and gotchas of C/C++, it was embraced quickly and massively by the software industry. This lead to massive investment, which lead to large JVM performance increases and a boatload of productivity-enhancing development tools.
I like Erlang a lot for the concurrent, distributed type of software I write. However, Damian hits the nail right on the head. What do you think?
Hurry! Hurry!
Lots of smart and sincere software development folks like Ron Jeffries, Jim Coplien, Scott Ambler, Bob Marshall, Adam Yuret, etc. have recently been lamenting the dumbing-down and commercialization of the “agile” brand. Since I get e-mails like the one below on a regular basis, I can deeply relate to their misery.
Hurry! Hurry! After just 2 days of effort and a measly 1300 beaners of “investment“, you’ll be fully prepared to lead your next software development project into the promised land of “under budget, on schedule, exceeds expectations“.
Whoo Hoo! My new SCRUM Master certificate is here! My new SCRUM Master certificate is here!
Scrum Cheat Sheet
While reading Schwaber and Sutherland’s official Scrum Guide, I decided to concoct a graphical UML-heavy cheat sheet of the monstrously famous agile framework.
Scrum Framework Components
System Class Diagram
Scrum Roles
Scrum Events
Scrum Artifacts
Unexplained Resurrections
If you dive head first into the work of Bill Livingston and/or Rudy Starkermann, you’ll find it easy to either develop or maintain a doomsday mindset of a future increasingly dominated by bigger and more inhumane institutions. Their rigorously developed physics and control engineering-based theories of institutional behavior can seem ironclad and 100% irrefutable. BD00 has drunk the kool-aid, but not the whole glass.
According to BD00’s interpretation of Livingston’s D4P, once an established institution encounters a novel and identity-threatening situation, annihilation is sure to follow because it is incapable of learning and adapting at the expense of losing its identity. I think that to be true in general, but not in the absolute. There are too many counter-examples of resurrection in the real world that go unacknowledged in his work:
- IBM was on its deathbed stuck in a “mainframe hardware” mindset, but it recovered under cookie-man Lou Gerstner by transforming itself into a software services company.
- Apple was on its deathbed, but it recovered under Steve Jobs and a financial bailout from Microsoft (yes, Microsoft!).
- My company, which was consistently losing money, heavily in debt, and arguably on its deathbed, is now debt-free and making money in a wickedly brutal economic environment.
I’ve had the privilege of e-interacting with both Bill and Rudy over the past several years. Bill sends me his draft work regularly for feedback/review and he’s very inviting of criticisms and challenges. However, I’m not satisfied with his answers when I pose cases like those listed above to counter those examples in his books that promote his theories.
When all is said and done, Livingston and Starkermann are two genuine social science originals and much of what they say is true. I highly recommend delving into what they have to say.
Related articles
- Yin And Yang (bulldozer00.com)
- From The Ground Up (bulldozer00.com)
- Building The Perfect Beast (bulldozer00.com)
- Cross-Disciplinary Pariahs (bulldozer00.com)
Marginalizing The Middle
Because they unshackle development teams from heavyweight, risk-averse, plan-drenched, control-obsessed processes promoted by little PWCE Hitlers and they increase the degrees of freedom available to development teams, agile methods and mindsets are clearly appealing to the nerds in the trenches. However, in product domains that require the development of safety-critical, real-time systems composed of custom software AND custom hardware components, the risk of agile failure is much greater than traditional IT system development – from which “agile” was born. Thus, a boatload of questions come to mind and my head starts to hurt when I think of the org-wide social issues associated with attempting to apply agile methods in this foreign context:
Will the Quality Assurance and Configuration Management specialty groups, whose whole identity is invested in approving a myriad of documents through complicated submittal protocols and policing compliance to existing heavyweight policies/processes/procedures become fearful obstructionists because of their reduced importance?
Will penny-watching, untrusting executives who are used to scrutinizing planned-vs-actual schedules and costs in massive Microsoft Project and Excel files via EVM (Earned Value Management) feel a loss of importance and control?
Will rigorously trained, PMI-indoctrinated project managers feel marginalized by new, radically different roles like “Scrum Master“?
Note: I have not read the oxymoronic-titled “Integrating CMMI and Agile Development” book yet. If anyone has, does it address these ever so important, deep seated, social issues? Besides successes, does it present any case studies in failure?
… there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer makes enemies of all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order… – Niccolo Machiavelli
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 