Archive
Agile Software Factories
The next big thing in software development is here….
Where’s my hard hat? Whoo Hoo!
Motherbuckers
I love discovering people and companies that buck the current “kool and hip” trends followed religiously by the herd (mooo!). One of these motherbuckers is Evernote Inc. I’m not an Evernote user, but the app is phenomenally successful and has an enthusiastic following.
In “One Reason Everyone Has Outsourced Their Brains To Evernote | Fast Company”, Evernote CEO Phil Libin says:
We do everything native. That was actually the big decision. Right from the beginning we said, “No common denominator crap.” No HTML5. Just all native on every platform.
You would think that it makes no business sense to maintain a separate, resource-sucking team for each supported platform, but think again:
Yes, it’s really expensive. Yes, it takes a ton of developers. But it works for Evernote: As Libin says, they’ve got independent teams for every platform. They compete to make the best version, steal from each other, and leapfrog one another. Since each platform is different–BlackBerry, for instance, has that keyboard thing–the versions are tailored to them. And each fits. – FastCompany
Which Path?
Please peruse the graphic below and then answer these questions for BD00: Is it a forgone conclusion that object-oriented development is the higher quality path from requirements to source code for all software-intensive applications? Has object-oriented development transitioned over time from a heresy into a dogma?
With the rising demand for more scaleable, distributed, fault-tolerant, concurrent systems and the continuing maturation of functional languages (founded on immutability, statelessness, message-passing (e.g. Erlang, Scala)), choosing between object-oriented and function-oriented technical approaches may be more important for success than choosing between agile development methodologies.
Our Stack
The figure below shows a layered view of the latest distributed system product that I’m working on. Customer teams compose their applications by writing their own system-specific Crumbs and linking them with our pre-written, pre-tested Crumbs. In the ideal case, customers don’t have to write a single line of Crumb code. They simply compose, compile, link, configure, and deploy an amalgamation of our off-the-shelf Crumbs as a set of application components that meets their needs.
Note that we are using C++11 to build the system. Also note the third party, open source libraries that we are building upon. Except for Poco, Crumb developers don’t directly use the OpenDDS or ACE/TAO APIs. Our Crumb “Tray” serves as a wrapper/facade that hides the complexity those inter-process communication facilities.
My role on the development team is as a Libs team “Crumb” designer/writer. If I gave you anymore product views or disclosed anything more concrete, then I’d either get fired or I’d have to kill you, or both.
What are you currently working on?
How Can We Make This Simpler?
The biggest threat to success in software development is the Escalation of Unessential Complexity (EUC). Like stress is to humans, EUC is a silent project/product killer lurking in the shadows – ready to pounce. If your team isn’t constantly asking “how can we make this simpler?” as time ticks by and money gets burned, then your project and product will probably get hosed somewhere downstream.
But wait! It’s even worse than you think. Asking “how can we make this simpler?” applies to all levels and areas of a project: requirements, architecture, design, code, tools, and process. Simply applying continuous inquiry to one or two areas might delay armageddon, but you’ll still probably get hosed.
If you dwell in a culture that reveres or is ignorant of EUC, then you most likely won’t ever hear the question “how can we make this simpler?” getting asked.
But no need to fret. All ya gotta do to calm your mind is embrace this Gallism :
In complex systems, malfunction and even total malfunction may not be detectable for long periods, if ever – John Gall
Tight, Theory-Based, Loose, Empirical
Processes designed to execute the business of an enterprise should be tight and theory-based. Processes designed to develop the products of an enterprise should be loose and empirical.
In the best performing companies, this ridiculously simplistic BD00 generalization is true? In the worst companies, the opposite is true?
Boulders And Pebbles
When embarking on a Software Product Line (SPL) development, one of the first, far-reaching cost decisions to be tackled is the level of “granularity” of the component set. Obviously, you don’t want to develop one big, fat-ass, 5 million line monstrosity that has to have 1000s of lines changed/added/hacked for each customer “instantiation“. Gee, that’s probably how you operate now and why you’re tinkering with the idea of an SPL approach for the future.
On the other hand, you don’t want to build 1000s of 10K-line pieces that are a nightmare for composition, configuration, versioning and integration. For a given domain, there’s a “subjective” sweet spot somewhere between a behemoth 5M-line boulder and a basket of 10K-line pebbles. However, if you’re gonna err on one side or the other, err on the side of “bigger“:
…beware of overly fine-grained components, because too many components are hard to manage, especially when versioning rears its ugly head, hence “DLL hell.” – Martin Fowler (UML Distilled)
The primacy of system functions and system function groups allows a new member of the product line to be treated as the composition of a few dozen high-quality, high-confidence components that interact with each other in controlled, predictable ways as opposed to thousands of small units that must be regression tested with each new change. Assembly of large components without the need to retest at the lowest level of granularity for each new system is a critical key to making reuse work. – Brownsword/Clements (A Case Study In Successful Product Line Development)
So, How Do You Know?
In the software development industry, going too slow can result in nothing getting done in an “acceptable” amount of time and thus, impatient managers cancelling projects. On the other hand, going too fast can result in hackneyed designs, halted downstream progress due to lots of rework on an unmanageable code base, and thus, frustrated managers cancelling projects.
As the figure below shows, the irony is that going too slow can result in less sunk cost due to earlier cancellation than going too fast – which gives a false illusion of great progress till the fit hits the shan.
So, how do you “objectively” know if you’re going too fast or too slow? It’s simple: you freakin’ don’t. However, in a world increasingly dominated by “agile” indoctrination, faster seems to be always equated with better and the tortoise vs. hare parable is heresy.
Heaven And Hell
This is one of those picture-only posts where BD00 invites you to fill in the words of the missing story…
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 