I never liked Dots. Every time I popped one into my mouth, I thought it might pull out a filling. But artistic dots, now they’re a whole ‘nother story.
In “The Art Of Asking“, Amanda Palmer movingly writes about collecting, connecting, and especially, sharing personalized dot-connected products as follows:
Collecting the dots. Then connecting them. And then sharing the connections with those around you. This is how a creative human works. Collecting, connecting, sharing. This impulse to connect the dots—and to share what you’ve connected—is the urge that makes you an artist. If you’re using words or symbols to connect the dots, whether you’re a “professional artist” or not, you are an artistic force in the world. You’re an artist when you say you are. And you’re a good artist when you make somebody else experience or feel something deep or unexpected. – Amanda Palmer
If you think mining and connecting seemingly random dots is difficult, exposing the resultant products for all to see can be downright scary. The fear of rejection is always lurking in the background.
Amanda’s dotty insight reminds me of the greatest commencement address I ever heard – Steve Jobs’s speech to Stanford grads in 2005. In that inspirational talk, Steve chronicled how he unknowingly collected his dots over the years and then serendipitously connected them together into the idea that led to the birth of the world-changing Macintosh computer.
You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life – Steve Jobs
I don’t know about you, but I feel like I’m full of… dots. I’ve got a boatload of dots hiding out in the deep recesses of my mind that are just waiting to be internally connected and externally shared. This blog is one catalyst for coaxing some of those cleverly concealed dots out of hiding, connecting them together, and sharing the result.
If you haven’t yet discovered the joy of mining, connecting, and sharing your personal dot collection, isn’t it about time that you made an attempt to do so?
I’ve been following Scott Berkun for at least a decade. Every month or two, I mosey on over to his site to get my Berkun fix and see what he’s up to. I’ll read some of his blog posts and/or watch a video of one of his great talks.
While watching Scott’s lecture to MIT students on innovation, I paused the video to steal this insightful graphic:
People (especially in western cultures) love short and sweet stories of epiphanies and overnight success – the tip of the iceberg. They yearn to believe that world changing innovations happen in flashes of instantaneous insight, no preparation required, all glory and no sweat.
Scott’s research for his Myths Of Innovation book busts the misconception of all mental play and no work. Oh sure, the epiphanies and eureka moments do indeed occur. But odds are that the innovator has been obsessing over a specific problem; immersing herself in the meticulous details of the problem and its enveloping context. The innovator has likely been exploring solution paths for months, years, or even decades. The hard, persistent, sustained, work of mulling over ideas prepares the innovator to receive the proverbial epiphany as thrust down upon her from the heavens.
But alas, doing the hard work can only get you to the bus stop. It doesn’t guarantee that the bus will arrive – ever.
On my first pass through Bertrand Meyer’s “Agile!” book, I interpreted its contents as a well-reasoned diatribe against agilism (yes, “agile” has become so big that it warrants being called an “ism” now). Because I was eager to do so, I ignored virtually all the positive points Mr. Meyer made and fully embraced his negative points. My initial reading was a classic case of the “confirmation bias“; where one absorbs all the evidence aligning with one’s existing beliefs and jettisons any evidence to the contrary. I knew that the confirmation bias would kick in before I started reading the book – and I looked forward to scratching that ego-inflating itch.
On my second pass through the book, I purposely skimmed over the negatives and concentrated on the positives. Here is Mr. Meyer’s list of positive ideas and practices that “agile” has either contributed to, or (mostly) re-prioritized for, the software development industry:
- The central role of production code over all else
- Tests and regression test suites as first class citizens
- Short, time-boxed iterations
- Daily standup meetings
- The importance of accommodating change
- Continuous integration
- Velocity tracking & task boards
I should probably end this post here and thank the agile movement for refocusing the software development industry on what’s really important… but I won’t :)
The best and edgiest writing in the book, which crisply separates it from its toned down (but still very good) peer, Boehm and Turner’s “Balancing Agility And Discipline“, is the way Mr. Meyer gives the agilencia a dose of its own medicine. Much like some of the brightest agile luminaries (e.g. Sutherland, Cohn, Beck, Jeffries, Larman, Cockburn, Poppendieck, Derby, Denning (sic)) relish villainizing any and all traditional technical and management practices in use before the rise of agilism, Mr. Meyer convincingly points out the considerable downsides of some of agile’s most cherished ideas:
- User stories as the sole means of capturing requirements (too fine grained; miss the forest for the trees)
- Pair programming and open offices (ignores individual preferences, needs, personalities)
- Rejection of all upfront requirements and design activities (for complex systems, can lead to brittle, inextensible, dead-end products)
- Feature-based development and ignorance of (inter-feature) dependencies (see previous bullet)
- Test Driven Development (myopic, sequential test-by-test focus can lead to painting oneself into a corner).
- Coach as a separate role (A ploy to accommodate the burgeoning agile consulting industry. Need more doer roles, not talkers.)
- Embedded customer (There is no one, single, customer voice on non-trivial projects. It’s impractical and naive to think there is one.)
- Deprecation of documents (no structured repository of shared understanding to go to seek clarification on system level requirements/architecture/design issues; high maintenance costs for long-lived systems; costly on-boarding of new developers)
I’ve always maintained that there is much to like about the various agile approaches, but the way the agile big-wigs have been morphing the movement into a binary “do-this/don’t-do-that” religious dogma, and trashing anything not considered “agile“, is a huge turnoff to me. How about you?
While watching Neal Ford’s terrific “Agile Engineering Practices” video series, I paid close attention to the segment in which he interactively demonstrated the technique of Test Driven Development (TDD). At the end of his well-orchestrated example, which was to design/write/test code that determines whether an integer is a perfect number, Mr. Ford presented the following side-by-side summary comparison of the resulting “traditional” Code Before Test (CBT) and “agile” TDD designs.
As expected from any good agilista soldier, Mr. Ford extolled the virtues of the TDD derived design on the right without mentioning any downside whatsoever. However, right off the bat, I judged (and still do) that the compact, cohesive, code-all-in-close-proximity CBT design on the left is more readable, understandable, and maintainable than the micro-fragmented TDD design on the right. If the atomic code in the CBT isPerfect() method on the left ended up spanning much more space than shown, I may have ended up agreeing with Neal’s final assessment that the TDD result is better – in this specific case. But I (and hopefully you) don’t subscribe to this, typical-of-agile-zealots, 100% true, assertion:
The downside of TDD (to which there are, amazingly, none according to those who dwell in the TDD cathedral), is eloquently put by Jim Coplien in his classic “Why Most Unit Testing Is Waste” paper:
If you find your testers (or yourself) splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it. Test at a coarser level of granularity. – Jim Coplien
As best I can, I try to avoid being an absolutist. Thus, if you think the TDD generated code structure on the right is “better” than the integrated code on the left, then kudos to you, my friend. The only point I’m trying to make, especially to younger and less experienced software engineers, is this: every decision is a tradeoff. When it comes to your intimate, personal, work habits, don’t blindly accept what any expert says at face value – especially “agile” experts.
Last Saturday was a bad day. The head came flying off my five iron while hitting balls at the golf dome and I broke my giant tini’ glass. Boo hoo, poor me.
Looking on the bright side, I get to buy a new set of clubs. I also have a fashionable, albeit smaller, backup tini’ glass.
Even though hard-core agilistas (since every cause requires an evil enemy) present it as thus:
For large, complex, multi-disciplined, product developments, it should be as thus:
Note1: This bogus post was inspired by Bertrand Meyer’s book: “Agile!“. Specifically, the juice is squeezed from chapter 2: “Deconstructing Agile Texts“.
Business gurus love to fabricate crises and instill fear in their deep-pocketed C-level executive clients so they can pitch their latest idea (at $2000/day plus expenses) to “reinvent management!”
Steve Denning is a big-league business management guru, ala Gary Hamel, Tom Peters, Ken Blanchard, Bob Sutton, etc. Even though Mr. Denning has no software background, he somehow got into Jeff Sutherland’s refrigerator and managed to drink a whole pitcher of “agile” koolaid with nary a burp.
In a brilliant marketing move to distance himself from his peers, Steve has jumped on the “agile” bandwagon. He’s been busy advocating the migration of Scrum out of the software development trenches; up the ladder and into the corner office we go. I can visualize it: CEO as Certified Product Owner, COO as Certified Scrum Master, and the rest of the C-suite as second-class, uncertified, “developers“. (Why is there no certification program for developers?)
In closing out this post, I’d like to share with you this brief twitter exchange between Mr. Denning and the lowly BD00 :