Subscribe: Brad Appleton's ACME Blog
Added By: Feedage Forager Feedage Grade B rated
Language: English
agile  architecture  book  change  code  design  development  lean  organizing  software development  software  team  teams 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Brad Appleton's ACME Blog

Brad Appleton's ACME Blog

Agile CM / ALM Environments

Updated: 2017-11-11T20:33:07.725-06:00


SOA, Mashups, Mashed Knees and Surgery


Today is my birthday - I had arthroscopic knee surgery last night and am feeling pretty good so far (happy birthday to me). I know I still have a lot of meds/painkillers in my system and that its going to feel more uncomfortable the next few days. I'm still hobbling around on crutches but I'm feeling much more confident that I can attend (and present at) Agile2009.

I received some very good books on Mashups and SOA a few months back and I'm finally getting a chance to look at them in some more detail. They really are quite good! I think Mashups are the "latest frontier" for realizing the promise of SOA, and a natural evolution from Wiki-webs. Here are the books:

If you follow the links above to the homepage for each of the above books, you'll find some good excerpts and related articles that will give a preview of what to expect so you can judge for yourself.

BOOK: Running an Agile Project


First, on a personal note, I had the misfortune to tear cartilage in my right knee a couple days ago and will require surgery to repair/remove it. I'm hobbling around on crutches for the time being. I hope I can still attend (and present at) Agile2009.

Anyway, my review of Mike Holcombe's book Running an Agile Software Development Project appears in this month's Agile Journal.

Running an Agile Software Development Project is an interesting book. On the surface it looks like it would be very academic, because the author, Mike Holcombe, was a University Professor at the time, and running an “agile software development factory” of students (albeit for a real commercial development shop). And yet what is described in the contents is very much the practical, real-world results of running agile projects with those same people for real IT software development work.


Overall, I found Running an Agile Software Development Project to be interesting and enjoyable. It still seems just a bit academic for my taste, and probably wouldn’t be the first book I would recommend on the subject unless it was for a classroom audience (in which case this book would be an excellent one to use).

You can read the full review here!

WANTED: Seeking Single Agile Knowledge Development Tool-set


I'll be presenting at Agile2009 in Chicago on the Tools for Agility stage on Tuesday 25 August, 4:45pm-5:30pm.Here is my session description from Seeking Single Agile Knowledge Development Tool-setAren’t code, backlog-items, tests, designs & documents all just different forms of system knowledge at different levels of detail? Why can’t the same tools help refactor, browse, search, and provide build/test automation for non-code forms of knowledge without requiring a separate tool/repository for each format? This talk is intended as a challenge to tool vendors/developers to see how this simple treatment of all non-code items as part of a single, unified project knowledge-base can be at once both immensely powerful, and imminently practical, without requiring too much added complexity.Process/MechanicsApproximately ~30 minutes of slides/presentation to “make the case” for why this approach is useful and desirable, followed by discussion of challenges (to and from tool developers/vendors, as well as the rest of the audience) as to its usefulness and benefits, and why their current tools can’t easily do so and why the should or should not be easy to enhancement them to do it.OutlineSoftware development as knowledge developmentSource-Code as knowledgeRequirements (Stories) and Tests as knowledgeOther usable forms of project knowledge (e.g., build scripts & configuration, build/test result reports version control history/comments, online help & other supporting docs)How would I do this?Refactoring Knowledge (thinking about the rest of the “knowledge” the way we think about the code, and its habitability, navigability, and structure/refactoring)Applying other agile-practices (like TDD, Continuous Integration, etc.) to non-code knowledge developmentWiki-based skins, DSLs, and use-cases/design as domain-driven Wiki-word definitions Patterns (giving things names), Retrospectives results and lessons learnedViewing, searching EVERYTHING (even the code) via wiki?The “Wu-Wei” of Traceability (Tracing without Tracing)Versioning and operating on wiki-like entities, just like with code (e.g., making “working copies”, branches and tags)DISCUSSION & CHALLENGE: Why can’t (or how can) YOUR tools do this!Begin audience discussion/dialogue: Why can’t a tool like Eclipse or a Wiki-based CMS (such as Confluence) be used as a front-end to browsing/refactoring and navigating ALL the knowledge of the system? (not just code, but stories, tests, build/config data, CI reports, backlog, retrospective lessons).What makes it easy/hard for these and other tools like any of the following to do this, or to be simple “skins” or plug-ins on top of only a handful of tools instead of a whole kitchen sink full of separate tools and repositories.Eclipse, Confluence, Twiki?FIT, Fitnesse, ContourDoxygen / JavadocTrac / Agile-Trac?Jira / RemedySee also a blog-entry of mine entitled Can I have just one repository please?Learning outcomesThinking about Agile development as knowledge management & creationCurrent barriers to using agile techniques and supporting tools for non-code artifacts What do refactoring, TDD, continuous integration, etc. mean for non-code artifacts (and why you should care)Use of wikis for organizing, structuring and refactoring ALL system knowledgeWhy manual traceability is unnecessary (and even comes for free) when using such an approachPrimary target persona Tomas Tool-smith/Tool-vendorOther target personasBilly, Business Analyst David, Agile Developer Patricia, Project Manager Tara, Tester(download PDF here)[...]

Studies on Effectiveness of TDD?


This question came-up in a discussion earlier this week: Do we know of published studies on this subject? A quick Google-search turned up the following for me ...

Any others? Any comments on the above?

Resources on Retrospectives


I found a really good resource-list from George Dinwiddie on Introspection and Retrospectives that includes the following list of resources (mostly patterns & techniques) about conducting retrospectives. It contains many (but not all) of the links below:RestrospectiveTechniques compiled by George DinwiddieAgile Retrospectives Resource WikiSinging the Songs of Project Experience: Patterns and Retrospectives by Linda Rising and Esther Derby from Cutter IT Journal (PDF)Restrospective Agility by Tim Mackinnon in Objective View (PDF) Norm Kerth's website.Esther Derby's Seven Reasons to Have a Retrospective6 Reasons *not* to have a RetrospectiveWhat a Retrospective Ain'tTwo more ways to gather dataFive Tips for Retrospective Leaders and Meeting Moderators and Tips for Retrospective FacilitatorsRachel Davies' Heartbeat RetrospectivesHow To: Live and Learn with RetrospectivesRefactoring Your Development Process with RetrospectivesMarco Abis' Retrospectives IN and ON actionSample chapters 3 & 5 from Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen: Chapter 3, Leading RetrospectivesChapter 5, Selected ActivitiesChapter 10, Make it Soa 50min talk/presentation from Esther & Diana on YouTubeEllen Gottesdiener's Team Retrospectives — for better iterative assessment looks at the topic from a RUP perspective.Bill Wake's Some Patterns for Iteration RetrospectivesJames Carr's Retrospective PatternsIan Burgess' Agile Retrospectives Lessons LearnedIlja Preuss' Retrospective Anti-PatternsArticle: Leveraging Agile Retrospectives to Evolve Your ArchitectureSimon Baker on Retrospective Using Appreciative Inquiry (see similar article by Diana Larsen)Ben Coombs' A Retrospective based on Agile ValuesMark Levison's Agile Games for Making Retrospectives InterestingKris Blake's Retrospective Agenda for High-Performing TeamsScrum Alliance - Seven Ways to Revitalize Your Sprint RetrospectivesFabio Periera's Goal-Driven RetrospectiveMishkin Berteig's Agile Work: Cheat-Sheet for RetrospectivesAgile Journal - Iteration and Release Retrospectives: The Natural Rhythm for Agile MeasurementRetrospectives Content on, including ... InfoQ: Heartbeat Retrospectives to Amplify Team InfoQ: Making Retrospective Changes StickInfoQ: How Long Should Retrospectives Last?InfoQ: First (Forgotten?) Rule Of The Retrospective: Follow ThroughInfoQ: Annotated Burn-Down Charts Help During RetrospectivesInfoQ: Frequent Retrospectives Accelerate Learning and ImprovementJim Shore's brief recap and retrospective format from The Art of Agile Development (0596527675)[...]

Refactoring @ Scale


In my previous post, Refactoring for Agility, I posted an outline and some thoughts for Part I of an Overview on Refactoring. Now I'm ready to post on Part II which is about refactoring @ scale. By "at scale" I mean in the larger context of other agile practices, as well as for large projects.PART II - REFACTORING @ SCALE1. Scaling-UpTo scale refactoring for larger projects, some additional techniques & issues must be added to the mix.Note that this is “in addition to” (not “instead of”)Refactoring In-the-SmallRefactoring @ ScaleSmall, Fast & Frequent RefactoringsLarger, Periodic & Planned RestructuringsEmergent DesignIncremental Design & Evolutionary ArchitectureDeferred RefactoringRestructuring & Technical DebtCode SmellsArchitecture SmellsDesign Principles & PatternsSoftware Modifiability TacticsSimple/Clean CodeSupple/Domain-Driven Design2. Emergent DesignEmergent Design is a fancy name for the resulting design that “emerges” from the synergy of combining Refactoring together with TDD, Continuous Integration and Automated Testing.Emergent Design means that ...3. Technical Debt [a.k.a. Design Debt]4. Restructuring Technical DebtIf we accrue a non-trivial amount of technical debt, we can’t simply “refactor” it away.Paying it off typically requires restructuring efforts (or even reengineering) that must be planned.Iteration plans must accommodate specific tasks for these restructuring efforts (or even be dedicated to restructuring).Ignoring it, or deferring it for very long is not a viable option!5. Overview of RestructuringIdentifies higher-level issues (“architecture smells”) that typically represent violations of known principles of good software architecture & design.Periodically applies larger-scale “refactorings” and/or many small refactorings that were previously deferred.The goal is to “pay down technical debt” in order to limit the increasing costs of accumulated complexity.Typically requires a concerted effort that must be separately planned.Uses not only design patterns/principles, but also architectural patterns/principles, as well as software modifiability tactics.6. Refactoring vs. RestructuringSee Martin Fowler's description in Refactoring Malapropism7. Restructure PeriodicallyRestructuring is often associated with absent or neglectful refactoring and/or design.But … Any large software project spanning multiple teams eventually needs restructuring.Even in the presence expert-level architecture, design & continuous refactoringThis is just a reality of software evolution/entropyTherefore … Large software projects should assume that periodic restructuring will be necessary, and should plan accordingly to:Clean-up accumulated code-smells and apply numerous refactorings that were deferred but are now sorely needed, Address architecture smells by applying restructurings, patterns and modifiability tactics that have broader impact.8. Architecture SmellsSee Stefan Roock's and Martin Lippert's book Refactoring in Large Software Projects (There was an earlier version of their work entitled Large Refactorings").Smells in Dependency GraphsSmells in Inheritance HierarchiesSmells in PackagesSmells in SubsystemsSmells in Layers9. Software Modifiability TacticsLocalize Changes (increase cohesion)Prevent Ripple Effects (reduce coupling)Defer Binding-time (defer decision-making)10. When to Consider/Plan Restructuring?11. Evolutionary ArchitectureSoftware Architecture concerns infrastructure elements that must exist before you can begin execution.Architecture is about things that are hard to change later, it is difficult to allow an architecture to emerge.For large projects, this includes high-level organization of the system into functionality/elements that will be allocated to separate teams.Key techniques of Evolutionary Architecture include:Deferring Irreversible Decisions to the “Last Responsible Moment” (LRM Princ[...]

Refactoring for Agility


Some of you might have guessed from my recent posts on Emergent Design, Technical Debt, JEDI Programming, and 5S Qualities of Well Designed, Well-Factored Code, that I've been looking into trying to teach the fundamentals of refactoring and how it scales to larger projects. I've gathered some references and quotes and some ideas for slides that I wanted to bounce around on my blog.Here is an outline and some thoughts for part I of some slides ...PART I - REFACTORING FOR AGILITY1. Overview of RefactoringIdentifies design-maintenance issues (“code smells”) that typically represent violations of known principles of good design.Incrementally and iteratively applies a set of design improvement techniques (“refactorings”).The goal is to minimize complexity & duplication in order to maximize simplicity & ease-of-change.Encourages the “right” design details to emerge “just-in-time” with minimal guesswork/rework.Scaling-up includes the use of periodic restructuring, initial & incremental design (“just enough”), and evolutionary architecture.2. Refactoring Defined [cite definition(s)]3. Refactoring Myths -- Refactoring is NOT …“Rework” – redesigning things that could, and should, have been designed correctly in the first place.Design “gold-plating” – work that adds no business value, and merely serves to stroke the egos of perfectionists who are out of touch with business reality.Miscellaneous code “tidying” – the kind that is “nice to have,” but should only happen when the team has some slack-time, and is a luxury we can do without, without any serious consequences. A license to “hack” – avoiding any and all initial design & analysis and instead jumping straight to coding with no “real” design.Reengineering – large-scale restructuring that requires a concerted effort over the course of several weeks/months to re-write or re-architect significant parts of the system.4. Refactoring IS …A systematic approach to source-code “hygiene” that minimizes the chances of introducing bugsImproving the design of the code after it has been writtenA behavior-preserving transformation of source-code structureThe process of simplifying & consolidating a work-product by making several, small, successive revisions focused on: preserving correctness, removing redundancy, revealing thoughts & intentions, and improving clarity & conciseness.A disciplined way of making changes while exposing the project to significantly less risk.An effective means to address the economic reality of software growth/complexity by reducing & amortizing its cost throughout the daily business of code development & maintenance activities.5. Why Refactor?6. How to Refactor7. Rules of Clean Code8. Rules for Simple Code9. The Steps of Refactoring10. Code Smells11. Categories of RefactoringsSmall RefactoringsLarger Refactorings/RestructuringsEach category contains as many as a dozen or more refactorings, most of which are catalogued at Refactorings (Some refactorings from real projects)See for an up-to-date list (and the “Refactoring to Patterns” catalog too)13. What to do if …?I spot a “smell” that is not already known or catalogued?There is no specific known/catalogued “refactoring” for what I think I need?14. When to Refactor?While adding functionalityWhile fixing a bugWhile reviewing codeAfter coding the same/similar thing for the third time (to “factor out” the duplication)A.k.a.: The Rule of Three: 3 strikes and you refactor.After the third time you deferred refactoring a change, for any reason [The Rule of Three, again]Before the end of the iteration if you haven’t been following The Rule of Three 15. Refactor Continually16. When NOT to Refactor?When the build is broken or tests don’t passWhen it would compromise meeting an i[...]

Mercurial, Git and Scala


Three more brand new books I just received that are worth mentioning ...

For those who may not know ...
  • Mercurial (like Git) is an open-source, distributed version-control system.

  • While Scala is the "hot" new JVM-based programming language that not only contains the "best of both worlds" from other statically-typed languages (like Java) as well as dynamic languages like Groovy, but also the best of both worlds from object-oriented programming languages (OOPLs) and functional programming languages (like Erlang and Haskell). Plus it has message-passing and actor-based support for concurrency (like Erlang) while still being strongly typed and having access to all your favorite Java APIs (and anything else that compiles to JVM). Not too mention that Scala has a kick-butt Web development framework called Lift that is a next-generation framework to the likes of Rails/Grails and Apache Struts.

Scala is my first pick for the programming language that is most excitingly poised for the multi-core programming revolution in the age of multicore processors, cloud-computing, web 2.0 and access to all your favorite Java APIs/apps.

BOOK: Landing the Tech Job You Love


I blogged earlier about The Passionate Programmer and The Nomadic Developer.

A new book just came out that seems like the perfect complement to these two: Landing the Tech Job You Love by Andy Lester (also from the Pragmatic Programmers). I've only just started reading it but so far I like it a LOT! It also received a nice review by Mike Riley in DDJ online.

Rather than cite the blurb from the book this time, I rather like the description given in the press release:

It’s tougher than ever to get that great job. Companies are more demanding and your competition is smart, tech-savvy, and resourceful. You’ve got the right skills for the job—you also need the right skills for job hunting. You need to work deliberately on your new job hunting skills, and this book can help. Old fashioned cookie-cutter job hunting skills aren’t enough: Land the Tech Job You Love gives you the background and the hard-won wisdom to leapfrog those who play by the old rules.

Andy tells us, “Life is too short for a job you don’t love. You’re not stuck—other opportunities are available for you, if you know where to look and can work the hiring process to your advantage. This book will help you get that job you love.”

In this book, you’ll learn how to find the job you want that fits you and your employer. You’ll uncover the hidden jobs that never make it into the classifieds or Monster. You’ll start making and maintaining the connections that will drive your future career moves.

Andy started writing this book years before the recession (a.k.a. “econopocalypse”) hit. He looked at the conventional wisdom and the advice available in generic books on job hunting, and found the conventional wisdom just didn’t work for programmers, system administrators, testers, and other related development positions.

He looked at everything from whether you should look for work on online job boards to whether you should lead off your resume with your objectives. Although he has definite answers for these two, he found that the answer to most questions is “it depends.” His book leads you to taking an honest assessment of what you offer and what you want in a job so that you end up in a job that is a good fit for you and your employer.

This is an important book for you to read whether you currently have a job or not. The same tactics you take to make yourself more employable will also make it easier to get promoted in your current company.

Also see Andy Lester's presentation on Effective Job Interviewing from Both Side of the Desk and his blog @ for his thoughts on "Job hunting and working life for programmers, sysadmins and all other techies"

BOOK: The Economics of Iterative Software Development


In the July issue of the Agile Journal I reviewed Walker Royce, Kurt Bittner and Mike Perrow's book The Economics of Iterative Software Development: Steering Toward Better Business Results. Here is an excerpt ...

The Economics of Iterative Software Development: Steering Toward Better Business Results is an important text for anyone trying to persuade management to "go iterative" as well as to anyone needing to measure & track the kinds of business results that management needs to see for a software development project.

I'll be perfectly honest: I was expecting this book to be an extremely dry and boring read, albeit full of lots of useful information densely packed in mathematical models and formulas, perhaps reminiscent of past college days reading a huge tome on socio-political economic theories. It wasn't as bad as I'd feared. Yes - it is a bit dry in places, but those are the exception rather than the rule. And there are lots of "war stories" sprinkled throughout that hold your interest and stop your eyes from glazing over.


All in all, The Economics of Iterative Software Development is a solid-book that is a relatively light/quick read with lots of good, practical advice on how to apply an economic model of thinking and measurement for managing and tracking business-results of an iterative project. If you need help doing that, or with communicating to your management about the need and benefits of an iterative approach, then you need to read this book!

See the full review for more details.

JEDI Programming - Just Enough Design Initially


I left a comment on the "What is Missing?" entry at the Agile-in-a-Flash blog. The author's asked the questioin "What is missing?" from the stack of Agile flashcards they are developing. I responded ...I think the "JEDI" approach is missing (any by that, I don't mean the mantra of "use the source Luke" ;-)I think there is something missing regarding TDD and Design. Uncle Bob's three rules of TDD (and other writings) often mislead people to think that there is ZERO design up-front, as is if NOT doing Big-Design-Up-Front (BDUF) implies that therefore there is zero up-front design (NoDUF).This is false (and Uncle Bob has even vehemently said so in The Scatology of Agile Architecture) but how does a newcomer reconcile it with the three rules of TDD? I can't write test-code without being able to invoke the thing-under-test. I can't invoke a thing if I haven't attempted to design the interface.If I design an interface (even for a single method/subroutine) I have to have some inkling of which class/package/module it would go in, at least INITIALLY! There is some initial amount of design I do before writing a test that is both necessary and sufficient to define "just enough" of the interface of what I want my test-case to test.So I think that is what is missing, a card called "JEDI", for "Just Enough Design Initially."To my knowledge, this particular definition of the JEDI acronym in agile development was first used by Stephen Palmer and other FDD luminaries at and (just do a Google-search on "JEDI" AND "Just Enough Design").I also think there is a relationship between JEDI and Eric Evan's " Domain-Driven Design (DDD), Supple Design (part of DDD), as well as *some* of the so-called "Pre-factoring". But it can be a risky, slippery-slope, so it would be great to have some guidance to help us know when we've done "Just Enough Design In-front/Initially."I suppose JEDI is a way of straddling the "appropriate range" of risk between anticipation and adaptation. I envision some kind of graph or diagram with axes ...On the left-hand side of overanticipating we have "too much too soon" and big/all up-front design.All the way on the right-hand-side we have "too little too late." Here you are faced with legacy-rewrites, system re-engineering, large-scale restructuring, etc.The problem with both extremes is the creation of technical debt:One Extreme does it by adding complex structures and behaviors too early in the cone-of-uncertainty and causes too much rework to rewrite that which was not yet certain and subject to much variability.The other extreme does it by sheer entropy/decay/rot that results from inattention and/or negligenceIn the middle we have a delicate balance that we need to strike, and which JEDI represents: "Just enough" and "Just-in-Time." The problem is that this is a range, not a single perfect point. What makes the problem harder is that the range is different for different projects, depending on a number of factors (including scale and distribution). There is a certain amount of "pay-up-front" and "pay-later" that need to be balanced with "pay-as-you-go."I imagine this "range" represents how to find the "sweet spot" that demarcates Just Enough Design Initially:In the middle of the scale is pure refactoring. It is strictly emergent, pay as you go just-in-time by focusing ruthlessly on keeping code clean and simple.Minor-to-moderate restructurings (too large to be refactorings, too small to be total re-writes) are to the right. Sometimes larger systems and/or systems constructed by multiple-teams can do a great job at refactoring and still not be able to avoid the need for minor-to-moderate restructuring, particular for aspects of the design that cut across teams and architecture and functionality.Just to the[...]

Emergent Design and Evolutionary Architecture - Resources


As a bit of a follow-up to my earlier posting on Technical Debt - Definition and Resources I gathered some resources on the subject of Evolutionary Architecture and Emergent Design (which is closely related to refactoring, restructuring and reengineering).Emergent Processes and Emergent Models of Architectural Practice, by Tom Wiscombe of emergentarchitecture.comNeal Ford's series of IBM developerWorks articles on Evolutionary Architecture and Emergent DesignChris Sterling's (upcoming) book on Architecture in an Agile OrganizationArticles on Emergent Architecture, from InfoQ.comCompeting in the Era of Emergent Architecture: The Case of Packaged Software Industry, Proceedings of the 40th Annual Hawaii International Conference on System Sciences (2007)Any of the fine presentations by Ryan Shriver, over at theagileengineer.comDean Leffingwell's writings on Agile Architecture and Intentional ArchitectureJon Kern's Just Enough Early Architecture to Guide Development, from TechnicalDebt.WetPaint.comOOPSLA '09 workshop on "Architecture in an Agile World"Software Architecture and Agile Software Development - An Oxymoron? by Philippe Kruchten Agile Architect by Philippe Kruchten Is Design Dead? by Martin Fowler (see the section "Growing an Architecture") 97 Things Every Software Architect Should Know (the book)Extending an architecture as it earns business value by Alistair Cockburn Agile Architecture - How much is enough?, by Eoin WoodsThe Agile Architect site (including the role of the agile architect)Articles at blog.softwarearchitecture.comAgile Architecting by Erik Philippus Eric Evans' work on Domain-Driven Design, see in particular the DDD Pattern Summaries and the InfoQ eBook Domain Driven Design Quickly (also this Step-by-Step Guide to DDD)Scott Ambler's Scaling Agile Development via Architecture from the Agile JournalLean Software Architecture, from Jim Coplien and Gertrud BjornvigAgile Architecture and Agile Architecture Requires Modularity, by Kirk Knoernschild Product Line Architectures and Agile Development, M.Ali Babar Going Agile? Beware of Architecture-Related Changes and Challenges, M.Ali Babar The Evolutionary Architecture Practice from the Eclipse Process Framework DevJam's David Hussman on Architecture and AgilityArchitecture Meets Agility, by Hakan ErdogmusToward and Evolutionary System of Systems Architecture, by Scott Selberg & Mark Austin, INCOSE 2008Guidelines for Lean Model-Based (System) Architecting and Software EngineeringSystems Engineering and Architecting Challenges: Application to Agile Development, by Murray CantorThe (freely available online) book Object-Oriented Reengineering Patterns, by Serge Demeyer, Stéphane Ducasse and Oscar NierstraszThe System Reengineering Patterns Project, by Perdita Stevens from Heriot-Watt University in Edinburgh (also see the SEI page on software reengineering)[...]

Embracing Change - quotable quotes on change and uncertainty


Every now and then I come across a good quote about embracing the fact that change and uncertainty are an essential inherent reality of software development. Here are the ones I like so far. Do you have another one you like? If so, leave a comment and share it with me.It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are revised, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are.-- Karl Wiegers, Cosmic Truths about Software RequirementsThe growing unpredictability of the future is one of the most challenging aspects of the new economy:Turbulence—in both business and technology—causes change, which can be viewed either as a threat to be guarded against or as an opportunity to be embraced.Rather than resist change, the agile approach strives to accommodate it as easily and efficiently as possible, while maintaining an awareness of its consequences. Facilitating change is more effective than attempting to prevent it.Learn to trust in your ability to respond to unpredictable events; it's more important than trusting in your ability to plan for disaster.Agile processes harness change for the customer's competitive advantage.-- Martin Fowler and James Highsmith, On the Agile ManifestoOrders must change rapidly in response to change in circumstances. If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.-- Taiichi Ohno, Toyota Production SystemIt’s not the strongest who survive, nor the most intelligent, but the ones most adaptable to change.-- attributed to Charles DarwinDoubt is not a pleasant condition, but certainty is absurd. -- VoltaireIt is not necessary to change; survival is not mandatory.-- W. Edwards DemingWhen the rate of change outside exceeds the rate of change inside, the end is in sight.-- Jack WelchThe Futility of Fighting Change: Requirements, technologies, teams, priorities, companies, usage, users, everything will change. There are things you cannot know until you know them. Give up. Change is inevitable. Our process must be a process, therefore, of change.-- Scott L. Bain The Nature of Software Development, May 2008Uncertainty is inherent and inevitable in software development processes and products.-- H. Ziv and D.J. Richardson, The Uncertainty Principle in Software Engineering, Aug 1996It will be important to organize future projects with enough agility to be able to adapt to the additional emergence of new sources of unpredictable change.-- Barry Boehm, Making a Difference in the Software Industry, March 2008When we program, we transform a poorly understood problem into a precise set of instructions that can be executed by a computer.When we think we understand a program?s requirements, we are invariably wrong.When we do not completely understand a problem, we must research it until we know that we understand it.Only when we truly understand a problem can we develop a superior product to address that problem.What the users think they want will change as soon as they see what we develop. -- Watts Humphrey, Some Programming Principles--Requirements, January 2003There is a very fancy technical term biologists use to describe completely stable systems. This highly sophisticated technical term is the word “DEAD!” Change is not the enemy – stagnation is!-- from The Unchangeable Rules of Software ChangeRequirements changes late in the lifecycle are competitive advantage, IF you can act on them!-- Mary PoppendieckBecoming agile means accepting uncertainty about the future as a way of dealing with the future.[...]

Technical Debt - Definition and Resources


I ran across a few really good papers on the subject of technical debt that are fairly comprehensive in their treatment of not just what it is, but also how to manage it:Technical Debt and Design Death: How to ensure you can deliver business value in the future as well as in the present; by Kane Mar and Michael JamesManaging Technical Debt - a whitepaper, by Steve McConnell (requires registration, which is free, but also see the blog-entry 10X Software Development - Technical Debt)Design debt economics: A vocabulary for describing the causes, costs, and cures for software maintainability problems; by John Elm, IBM developerWorks, June 2009Managing Technical Debt; by Tom Brazier Software Debt - Depreciation of Value for Software Assets and Technical Debt - Reducing Internal Quality for Short-term Gain, by Chris Sterling, from his forthcoming book Managing Software Debt (also see his video presentation)For those not already well-versed on the subject, Technical Debt [a.k.a. Design Debt] occurs when our software becomes difficult or risky to change, and takes increasingly more time & effort to evolve. Technical debt represents the cost of the accumulated amount of rework that will be necessary to correct and/or recover from the deviation between:the current design of the system, versus ...a design that is minimally complex yet sufficiently complete to ensure correctness & consistency for timely delivery.This effort grows more than linearly over time as a system becomes bigger and more complex.The economic impact of technical debt is directly related to the cost of complexity and its resulting “friction” against the velocity of the development team (and, subsequently, upon the ease of system evolution).Technical debt can be caused by under-engineering just as much as it can be caused by overengineering (overdesigning). It is a difficult, delicate and dynamic balancing act to achieve the necessary and sufficient amount of design to implement only the essential complexity required by system:Sometimes we knowingly (under great pressure) do something the "quick & dirty" way, with the intent to "do it right" later (but not too late).Sometimes we try to do too much to soon, and elaborate or implement details of the requirements when we and our customers/users haven't yet learned enough about the true needs of the system.Sometimes we haven't yet learned enough about good design, and unintentionally violate design principles, resulting in undesirable dependencies that make code or other work-products hard to change.Sometimes we neglect to properly "tend" to the design and don't give it the necessary amount of ongoing care and feeding needed to keep it "fit" and "supple."But whether it is a deviation between principles and practice (knowingly or unknowingly), guessing incorrectly, anticipating too early, neglect, poor quality, or even just the laws of software evolution, we must make plans and take action to deal with the inevitable entropy of evolution or else we will sink too far into technical debt.That's just my two cents on the subject of course. What do others have to say about it?Wikipedia defines Technical Debt by referring to the words of Ward Cunningham, who first drew the comparison between technical complexity and debt in a 1992 experience report:"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."On th[...]

Gee Scrum Method Owners!


[Personal note: I originally wrote this a few months before the Agile 2009 Conference, but forgot topublish" it, so it stayed in draft mode quite a while until I later discovered it and pressed "publish"]Sung to the tune of Gee, Officer Krupke! from West-Side Story -- Music: Leonard Bernstein, Lyrics: Stephen Sondheim (see video of the movie performance)Background:For about a year now, I believe there has been a greater than usual amount Agile-related blogging and mail-list discussion on the subject of the shortcomings of what is currently the most popular agile development method: Scrum. Some of them are legitimately about Scrum, others are really more about the kinds of problems one encounters introducing Agile methods without appropriate emphasis/execution of the technical practices (especially Refactoring and TDD).Its seems much of it may have started around the same time that Alan Shalloway (and later others, including Ron Jeffries, below) were banned from the ScrumDevelopment list for “going meta” and discussing problems with and/or additions to Scrum itself instead of how to apply/use it. Alan subsequently created the Lean-Agile list for such discussions (and is also working on a book).As of this writing, more recent examples include the following:James Shore, The Decline and Fall of AgileTwo specific threads on the ExtremeProgramming list: What about Scrum + CI + Automated-Tests? and What if Code Smells were counted as … Robert (”Uncle Bob”) Martin, presentation on Craftsmanship and Ethics, and a follow-up blog-entry on Quintessence: The fifth element for the Agile ManifestoThe thread from the Lean-Agile list on Controlling Say (was Definition and Scope of Scrum / PO Role) Ron Jeffries, Context My Foot! and Quality-Speed Tradeoff — You’re kidding yourselfJurgen Appelo, The Decline and Fall of AgilistsCast of Characters: You will need individual actors portraying the following roles!Alan Shalloway, Ron Jeffries, Peter Alfvin, Brad Appleton, Uncle Bob (Robert C. Martin), NOTE that the people are real, but the dialogue is fictional, even tho it is derived from bits and pieces of actual messages and blog-posts.Lyrics:RON (spoken): Hey, you! ALAN (spoken): Me, Officer Jeffries? RON (spoken):That’s Scrum Master Jeffries to you! Gimme one good reason for not draggin’ ya to the scrumdevelopment list to answer for blamin all yer troubles on Scrum. What’ll you say to Schwaber, ya punk!ALAN (sings):Dear kindly Scrum-Lord Schwaber, You gotta understand,It's just our agile nature that gets us Scrum-list banned.Our management is clueless, our backlog’s full of junk,Golly Moses, that’s where Scrum has flunked!ALAN with BRAD & PETER:Gee Scrum-method owners, we're very upset;Your method doesn’t scale and we’re in technical debt!We ain't no extremists, Our motives are clean,Deep down inside us there is Lean!ALAN: There is Lean!ALL:There is Lean, there is Lean, There is untapped Lean,Deep inside XP and Scrum there’s Lean.RON (spoken -- imitating Scrum list-owner):That's an off-topic discussion!ALAN (spoken):Lemme tell it to the world!RON (“Scrum list-owner”):Just tell it some place else!ALAN (singing, while creating the Lean-Agile list):Dear Lean-Agile list-readers, The Scrum-list is too closed.Despite their Agile leaders, the truth must be exposed:They didn't want discussion of what Scrum oughta add.Leapin' lizards, that's why I'm so “rad!”ALAN:Hey Scrum-method owners, you're really deep-fried!There’s plenty wrong with Scrum that needs Lean-thinking applied!PETER: Those darn product-owners have gotta be curbed!RON: They’re p[...]

Resources on Self-Organizing Teams for Agility


In the past several blog-entries I've been focusing on the agile principle of self-organization, what it means, and what it implies for teams. So far, I've written about Agile Self-Organization versus Lean Leadership, Self-Organization and Complexity, and Agile Self-Organizing Teams.For some online resources (articles and presentations) on self-organization and self-organizing teams, I recommend the following:InfoQ.Com articles: High-Performance Teams – Avoiding Teamicide, Coaching Self Organizing Teams, and Ensuring Success for Self Organizing TeamsLeading a Self-Organizing Team, PDF presentation by Mike Cohn given at the Jan 2009 Dallas Agile Project Leadership Network (APLN)Flock-theory applied, by James Brett -- a look at Flock Theory by D.Rosen for answers to creating highly optimized, self-organised Scrum teams Exploring Self-Organizing Software Development Teams, by Diana LarsenAgile Processes and Self-organization, by Ken Schwaber Understanding Self-organizing Teams in Agile Software Development, from 2008 Australian Software Engineering Conference (ASWEC2008) The Manager's role in Agile, and 7 Agile Coach Failure Modes, by Lyssa Adkins and Michael Spayd Scum vs Scrum: Emergent behavior in slime molds and software development teams, by Matt Truxaw Agile Software Development and Complex Adaptive Systems, a 4 part series of articles by Michael Dubakov: part1: Introduction to Agile Software Development and CASpart2: Software Development is a Complex Adaptive System - No Doubtpart3: The Edge of Chaos and Hyper-Productive Software Development Teamspart4: Simple Rules, Complex Systems and Software DevelopmentHolacracy - The Self-Organizing EnterpriseSteering from the Edges, by Sanjiv Augustine Roots of Scrum: Takeuchi and Self-Organizing Teams, by Jeff Sutherland Learning is the Bottleneck, by Amr Elssamadisy & Deborah HartmannLeadership is not obsolete in Self-Organizing Teams, by Mary PoppendieckMore articles on Self-Organizing Teams Polyanna Pixton's papers/presentations on Agile leadership & collaborationWhen to stand back, when to step-in (Managing self-organizing teams), by Esther DerbyWhat is the best leadership style for a software team? by Andriy Solovey (also see Evolutionary Software Architecture and Self-Organizing Teams: The Army versus Jim HighsmithSelf Organization in Scrum and Self-Organization & Shock Therapy, presentations by Jeff Sutherland (also see the corresponding video Self-Organization - The Secret Sauce for Improving Your Scrum Team)Of ants and men: self-organized teams in human and insect organizations The Meaning of Self-Organization in Computing and The Science of Self-Organization and Adaptivity, by Francis HeylighenMishkin Berteig on Team Self-OrganizationSwarming: The Birds, Bees and Agile, by Tom Perry and Dhaval PanchalLimits of Self-Organizing Teams, by Alan KellyBureaucracy & Organizational Politics: Emergent Characteristics of Structure, an essay from Jurgen Appelo on Self-Organizing TeamsSystemic Analysis of A Team’s Self- Organizing processes: some insights into the knowledge managementBe Empowered (That’s an Order !) “Experience the Dynamics and the Paradoxes of Self-Organizing Teams”, by Laurent Bossavit and Emannuel GaillotConditions for Self-Organizing in Human Systems by Glenda Holladay Eoyang (Ph.D. Thesis)Series of articles on Group Coherence for Agile/Project Teams:Group Coherence for Project Teams - A Search for Hyper-ProductivityGroup Coherence for Project Teams - Common PurposeGroup Coherence for Project Teams - Collaborative InteractionGroup Coherence for Project Teams – Group CreativityGroup Coherence[...]

Agile Self-Organizing Teams


The previous blog-entry on self-organization was lots of jargon and technical mumbo jumbo that didn't say too much about what that means for teams of people. So let's shift from talking about self-organizing systems in complexity science to talking about how it applies to self-organizing teams in an agile context.A self-organizing team is a team that is led and organized by it's members, to attain goals and objectives specified by management within the constraints of its environment:Management can shape and "nudge" the team and its members, but management doesn't try to dictate the details of "what" the solution is nor the process of how to create it.The team is responsible for not only leading and organizing itself to achieve its goals, but also to monitor and adapt its behavior to correct/improve its own performance.This means the team can change how it leads and organizes itself in order to respond to feedback and constraints from its environment, which also implies that ...There is no single central "leader" for the team over the lifetime of the team/project - the "leader" is not a static assignment, but rather a dynamic roleSo the person(s) leading any given moment may change, depending on the particular decision, activity, or problem being addressed in any particular context/situation.By themselves, self-organizing teams are neither "good" nor "bad." They simply "are." They require a supporting management environment (the "fitness landscape") and organizational culture that establishes, communicates, rewards and reinforces the "right" set of values and principles. Without supportive management and the proper leadership culture, there is a very high likelihood that a self-organizing team may be unable to create good results or effective processes (or both). In fact, it's not uncommon for a newly formed & "empowered" self-organizing team to fall into many of the same dysfunctional patterns of behavior that it was most trying to escape from within the "management" that only recently "empowered" the team.An "agile team" is (supposed to be) a self-organizing team that is guided by the agile values and agile principles (given by the agile manifesto) and is supported by a trusting and empowering style of management. With management supporting their agile values/principles, Agile teams "self-organize" to collectively decide and do what is needed in order to: make and meet commitments, develop a quality product, respond to feedback, and adapt to changes.So an Agile Self-Organizing Team is:Autonomous: There is no single central decision-making authority. Control is distributed collectively to the team.Adaptive: The team dynamically adjusts as needed across roles, functional specialties, and other boundaries, in order to solve their own problems and improve their own performance.Accountable: The team collectively shares responsibility for results, and members hold each other accountable for outcomes.Here are some choice quotes regarding self-organizing teams ...“The team makes most decisions, while every member could step in and become leader in specific areas and situations. People are highly capable, committed and self-driven.”—Andriy Solovey, What is the best leadership style for the software team?“This causes a shift in the roles of managers from planning, controlling, directing, and managing to new roles like building trust, facilitating and supporting team decisions, expanding team capabilities, anticipating and influencing change.”—Diana Larsen, Exploring Self-Organizing Software Development Teams"Responsibility-Based Planning and Control: Respecting people means that teams [...]

Self-Organization and Complexity


In my previous blog-entry I talked a little about how self-organization is a key aspect of software agility. In this blog-entry I'd like to explore in more detail just what "self-organization" really means.Self-organization comes from complexity science and the theory of complex adaptive systems (CAS). A system is "self-organizing" if, left to its own devices, it tends to become more organized over time. This is in stark contrast to the concept of entropy from the laws of thermodynamics whereby a closed system tends to move to a state of increasing disorder in the absence of outside influences.In a complex adaptive system where self-organization occurs, we necessarily have an open system rather than a closed one. The theory goes that if a complex system possesses the necessary emergent properties in an appropriate fitness landscape, then the system will yield emergent behavior, exhibiting system-wide "patterns", that increases the "order" or organization in the system. Hence the system has become self-organizing as a result of this emergent behavior & structure.Some of the emergent properties of self-organizing systems can include:Autonomy,Adaptability,Decentralization,Dynamic reconfiguration,Positive & Negative Feedback Cooperation & Information exchangeThe theory of complex systems suggests that self-organized systems are:better in selecting optimal state and local decisionsrobusteffectively adapt to environment and use feedback loopsoften come up with emergent and unexpected solutionsself-regulated and better cope with perturbationsAccording to James Highsmith,“There's no hierarchy of command and control in a complex adaptive system. There's no planning or managing, but there's a constant re-organizing to find the best fit to the environment. The system is continually self-organizing through the process of emergence and feedback”The Emergent Phenomena Research Group at Brywn Mawr says:"In self-organizing systems, global order (i.e., complex aggregate structure/behavior) results (emerges) from the local behaviors of simple agents following simple rules specifying conditions under which those agents act (interact) in such a way that the results of the agents' actions are fed back as input to the operation of the rule system at some future time step. "In The Science of Self-organization and Adaptivity, Francis Heylighen writes:Self-organization is basically the spontaneous creation of a globally coherent pattern out of the local interactions between initially independent components. This collective order is organized in function of its own maintenance, and thus tends to resist perturbations. This robustness is achieved by distributed, redundant control so that damage can be restored by the remaining, undamaged sections. ...Self-organizing systems are characterized by: distributed control (absence of centralized control), continual adaptation to a changing environment, emergent structure from local interaction, robustness/resiliency (able under change and can quickly repair, correct, adapt/adjust), non-linearity, feedback (both positive and negative), self-sufficiency and closure/coherence. ...Organizational closure turns a collection of interacting elements into an individual, coherent whole. This whole has properties that arise out of its organization, and that cannot be reduced to the properties of its elements. Such properties are called emergent.Every self-organizing system adapts to its environment; Systems may be called adaptive if they can adjust to such changes while keeping their organization as much as possible intact.From Software Devel[...]

Agile Self-Organization versus Lean Leadership


Getting back to the agility cycle ... recall that I started with the business agility cycle and used that to derive the software agility cycle. There isn't a great deal of difference between the first two steps of the business-agility cycle and the software-agility cycle, other than the fact that much of the former takes place at a higher-level of organizational management and strategy.The biggest difference between the two cycles happens after those first two steps. In the business agility cycle we then decide-communicate-act, suggesting that it is the higher-ups who make and communicate the decisions and the lower-end of the organizational food chain (the "worker bees") that execute the organization's strategic solution.If that seems a bit command-and-control, its because it is (a bit). It's also likely necessary in larger organizations where it is virtually impossible to avoid having 2 or more layers of management. There, the "communicate & act" steps are really the process of providing focus, and communicating objectives and constraints to the knowledge workers, and letting them apply principles of collaboration and self-organization to solve the problem (like in the software-agility cycle).So the key difference between business-agility and software-agility is the extra emphasis of the latter on "the people factor" and on the notion of dynamic self-organization of knowledge-workers as empowered, self-organizing teams. This difference between agility at the business-level versus software-level is also the key difference between Lean-vs-Agile:Lean focuses more on flow whereas Agility focuses more on adapting to change (this is true of both software agility and business-agility). As it turns out, focusing on flow requires being able to adapt to change; and focusing on adaptiveness and responsiveness requires a focus on flow. So here, the end-results may be quite similarAgile software development emphasizes a very hands-off management style of not just trusting and empowering the team(s), but often to the extreme of basically saying "leave us alone and don't interfere" to management (and in return promising extreme transparency and frequent tangible end-results).Much of this is due to the fact that the scope of Agile development is limited to software projects and teams, whereas Lean is targeted at enterprise-wide scale across the whole value-stream.That is not to say that Lean (or business-agility) don't emphasize trusting and empowering workers and teams (they do). But they don't have the underlying inherent attitude of "just trust us and stay out of the way." The "trust" often doesn't seem to extend as far in the other direction with Agile development (e.g. not trusting management direction to the same extent that management is asked to trust the team).I think this stems from the fact that software agility started more at the grass-roots level, with developers and teams struggling to create good, quality software in the face of what was all too often a fundamentally broken management framework for the governance, visibility, and lifecycle of software development projects. Because they were working and trying to get support from the bottom-up, they needed to be shielded from and unshackled by all the dilbert-esque "pointy haired managers" and their big, bad governance framework with its "evil" waterfall lifecycle.And in that context, the advice of "just get out of the way and trust us and we promise to deliver working software every 2-4 weeks" is actually a very effective strategy to employ. When management doesn't "get it", their[...]

Value Proposition for Agility


I'm sure I'm not the first person to think it, but I just came across the description of a newly published book whose title made me think about this subject. The book is:

Reading Minds and Markets: Minimizing Risk and Maximizing Returns in a Volatile Global Marketplace, by Jack Ablin and Suzanne McGee.

The title immediately made me think that this was the right language to use when communicating with business-people and senior management to describe what agility is in terms of its benefits to the bottom line.

Investopedia describes a "Value Proposition" as: "A business or marketing statement that summarizes why a consumer should buy a product or use a service. This statement should convince a potential consumer that one particular product or service will add more value or better solve a problem than other similar offerings."

So I think that "value proposition" is the right term to describe what is it about agility that I want to describe to a business-person or senior manager that should make them want to care about what agility is and why they should adopt it.

With the above in mind, here is my "value proposition" for agility:
Agility is all about harnessing the power of collaborative people and frequent delivery to:
  • learn & adapt to change,
  • minimize risk & cycle-time, and ...
  • maximize returns & customer-value
in a volatile global marketplace.

There! Top that! :-)

Think you have a better value-proposition for agility that is more succinct while still touching on the minimally sufficient set of key attributes? (the people-factor, frequent value-delivery, cycle-time, responsiveness to change and risk/ROI)

If so, then I want to see it! Leave a comment and let me know!

BOOK: The Art of Lean Software Development


In the June issue of the Agile Journal I reviewed Curt Hibbs, Steve Jewett and Mike Sullivan's The Art of Lean Software Development: A Practical and Incremental Approach. Here is an excerpt ...

With last month's announcement of the Lean Software and Systems Consortium at the 2009 Lean & Kanban Conference, it seems fitting that this month's book is about Lean Software Development and how Agile development practices support Lean Thinking.

The Art of Lean Software Development: A Practical and Incremental Approach is an introduction to Agile software development practices through the lense of Lean thinking. The first thing you need to know about this book is who its target audience is [...] from the publisher's website for the book: "This book has a very specific purpose -- it is aimed squarely at the complete novice. The one who has been hearing all the Lean-Agile buzz, really knows nothing about it, and wants to learn more quickly to decide if they want to dig deeper (without having to read a 500 page tome)."
Now that we've finally gotten that out of the way ... The Art of Lean Software Development actually succeeds at its intended purpose. It is a very "lean" introduction to the subject of applying lean thinking to software development. (You can see for yourself by looking at the online excerpts of chapter 2 and chapter 4.)
I like just about everything that The Art of Lean Software Development has to say. It is a bit of a dry read but a very quick one. ... For those more interested in the abridged version or the line-manager's equivalent of a technical overview, The Art of Lean Software Development is a very quick and easy read that successfully introduces the history and essentials of Lean and Agile software development from a Lean thinking perspective.

See the full review for more details.

The Dynamics of Leadership-Team Behavior


Interesting article in BusinessWeek from Jim Collins on the Dynamics of Team-Leadership Behavior. It's actually an excerpt from his latest book "How the Mighty Fall: and Why Some Companies Never Give In."Anyway ... the Dynamics of Team-Leadership Behavior is divided into leadership behaviors of teams on the way up vs. on the way down: Teams on the Way Down Teams on the Way Up People shield those in power from unpleasant facts, fearful of penalties and criticism for shining light on the rough realities People bring forth grim facts—"Come here and look, man, this is ugly"—to be discussed; leaders never criticize those who bring forth harsh realities People assert strong opinions without providing data, evidence, or a solid argument People bring data, evidence, logic, and solid arguments to the discussion The team leader has a very low questions-to-statements ratio, avoiding critical input and/or allowing sloppy reasoning and unsupported opinions The team leader employs a Socratic style, using a high questions-to-statements ratio, challenging people, and pushing for penetrating insights Team members acquiesce to a decision but don't unify to make the decision successful—or worse, undermine it after the fact Team members unify behind a decision once made, then work to make the decision succeed, even if they vigorously disagreed with it Team members seek as much credit as possible for themselves, yet do not enjoy the confidence and admiration of their peers Each team member credits other people for success, yet enjoys the confidence and admiration of his or her peers Team members argue to look smart or to further their own interests rather than argue to find the best answers to support the overall cause Team members argue and debate, not to improve their personal position but to find the best answers to support the overall cause The team conducts "autopsies with blame," seeking culprits rather than wisdom The team conducts "autopsies without blame," mining wisdom from painful experiences Team members often fail to deliver exceptional results and blame other people or outside factors for setbacks, mistakes, and failures Each team member delivers exceptional results, yet in the event of a setback each accepts full responsibility and learns from mistakes [...]

BOOKS: The Passionate Programmer and the Nomadic Developer


Gosh, when I write/say the titles of these two books together in one line it looks like the title of some kind of computer-geek romance novella. (maybe it will sell more books that way :-)Anyway, I'm mentioning these two books together because they both relate to subject of managing your career if you are a professional software developer, and they are both complementary to one another.The Passionate Programmer: Creating a Remarkable Career in Software Development, by Chad Fowler, is really the revised edition of an earlier work by him under a different book title. It's from the Pragmatic Programmers, so that by itself practically guarantees its pretty darn good. The blurb for the book is pretty darn accurate too: "This book is about creating a remarkable career in software development. In most cases, remarkable careers don’t come by chance. They require thought, intention, action, and a willingness to change course when you’ve made mistakes. Most of us have been stumbling around letting our careers take us where they may. It’s time to take control. This revised and updated second edition lays out a strategy for planning and creating a radically successful life in software development." Several excerpts are available from publisher's homepage for the book.The Nomadic Developer: Surviving and Thriving in the World of Technology Consulting, by Aaron Erickson, is a must read for anyone considering becoming a software development consultant (or by anyone who recently became one). Chapter 6 - Surviving, is available as an online excerpt.The "blurb" for this book is a bit long so I'll include only part of it here: "There are real advantages to being a consultant. You make contacts with a lot of different people; you get exposure to many industries; and most important, unlike a software developer in the IT department for a brick-and-mortar company, as a technology consultant, you are the profit center…so long as you are billing. Consulting can be hugely rewarding–but it’s easy to fail if you are unprepared. To succeed, you need a mentor who knows the lay of the land. Aaron Erickson is your mentor, and this is your guidebook. Erickson has done it all–from Practice Leadership to the lowest level project work. In The Nomadic Developer, he brings together his hardwon insights on becoming successful and achieving success through tough times and relentless change. You’ll find 100% practical advice and real experiences–his own and annotations from those in the trenches. In addition, renowned consultants–such as David Chappell, Bruce Eckel, Deborah Kurata, and Ted Neward–share some of their hard-earned lessons."I don't need to tell anyone that we are in tough economic times with cuts and force reductions abounding and new jobs being scarce. Seems to me that getting both of these books together makes just plain good sense for anyone in our line of work these days.[...]

5S Qualities of Well Designed, Well-Factored Code


The other day I was trying to explain to someone the properties of code that is well-factored and found myself using aliteration with 'S' words. That made me wonder if they were equivalent to Lean's "5S", which is as follows:Seiri (Sort) - Organize the work-area, leaving only the tools and materials necessary to perform daily activitiesSeiton (Straighten, Set in Order) - the orderly arrangement of needed items so they are easy to use and accessible for “anyone” to find.Seiso (Shine) - Keep everything clean and swept. Don’t allow litter, scrap, shavings, cuttings, etc., to land on the floor in the first place.Seiketsu (Standardize) - Creating a consistent approach for carrying out tasks and procedures. Orderliness is the core of “standardization” and is maintained by Visual Controls.Shitsuke (Sustain) - the discipline and commitment of all other stages. Without “sustaining”, your workplace can easily revert back to being dirty and chaotic. That is why it is so crucial for your team to be empowered to improve and maintain their workplace. Does the above apply to the structure and content of the code itself? Have you ever come across code that is truly well-factored? I don't just mean correct and that it follows coding standards, I mean the structure of the code itself not only had such clarity of thought and order, but it also had all the qualities that we like to think of that make the code changeable/malleable with ease. Here is what I think those qualities are:Sufficient scope (content & functionality) – The code implements only that which is necessary. It doesn't have more content than needed, or more behavior or interfaces or abstractions than needed. It is "just enough" code to get the job done, while still possessing the other properties below. XP ensures this by taking the “next most important” requirement, creating only just enough content (spec, requirements, even branches) that can be implemented for current activity in the current workspace. Then write only “just enough” code to pass the test (then you refactor).Simple, clean code – The code isnt just "Lean" in its content and functionality, but also in its structural design. Dependencies and duplication are minimized while clarity, cohesiveness, and conciseness are maximized. In XP, once the code result is “sufficient” in content & correctness, we refactor to simplify the structure and dependencies as much as possible.Supple design – This comes from the chapter of the same name in Eric Evans Evans' book Domain-Driven Design. Supple means pliant, malleable, limber, yielding or changing readily. Code that is well-factored is at once so simple yet sufficient as to be firm yet flexible. Yet the flexibility comes not so much from what you added as from what you left out and how you organized it. It is more than just simple and sufficient, there is an inherent model or "theory" of the program inside the programmer's head, and that structure and intent are clearly conveyed and deeply realized by the code and somehow manages to incorporate the subject domain in it as well. Evans cites patterns of supple design like: Intention-Revealing Interfaces, Side-Effect-Free Functions, Assertions, Conceptual Contours, Standalone Classes, Closure of Operations, Declarative Style of Design.Serviceable product – Making the code easy to change isn’t enough. Use coding standards too. But beyond that, ensure that what [...]

HBR on Rebuilding Trust


Some of you may recall some earlier blog-entries of mine on the topic of trust:Trust: The social virtues and the creation of prosperity by Francis FukuyamaMore Articles on TrustBuilding Trust: In Business, Poliotics, Relationship and Life by Solomon and Flores, andThe Speed of Trust: The One Thing that Changes Everything by Stephen M.R. CoveyAs it turns out, the current issue of Harvard Business Review is on the theme of Rebuilding Trust (follow the hyperlink for executive summaries). The article "Trust Revisited" has a roundup of the other articles in the issue that deal with trust:The public’s trust in business leaders has never been weaker. According to the Edelman Trust Barometer, released in January, trust in U.S. business dropped from 58% to 38% in one year. European businesses are in nearly as much trouble with the public. Businesses in emerging markets are faring better—but not by a lot. If companies can’t address this problem, an economic turnaround may be delayed indefinitely: Banks won’t lend money; innovation will slow to a crawl; trade across borders will fall even more rapidly; governments will overregulate the private sector; unemployment numbers will continue to rise; and consumers won’t open their wallets for anything they consider nonessential. A complex modern economy simply can’t function unless people believe that its institutions are fundamentally sound.The articles' executive summaries are:Rod Kramer, in “Rethinking Trust,” argues that most of us trust others far too easily. While the pundits claim that businesses need to rebuild consumers’ trust as soon as possible, Kramer argues that we need to remain skeptical.Joel Podolny’s piece “The Buck Stops (and Starts) at Business School,” indicts the schools that train managers and executives and shares his thoughts about how to reinvent business education—and thereby regain people’s trust.James O’Toole and Warren Bennis argue passionately that senior managers must build a culture of transparency to repair that problem. “What’s Needed Next: A Culture of Candor” makes the case that trust within organizations is the bedrock for rebuilding it in business as a whole.In “How to Be a Good Boss in a Bad Economy” Bob Sutton and another Stanford professor take a different perspective on the destructive dynamic of senior management behavior during tough economic times — and describes a better one.There is also an article from the previous month's issue about "When Contracts Destroy Trust."[...]