Floehopper

thoughts on the bergy bits of life

What we hope is becoming clear from this chapter is how we’re growing a design from what looks like an unpromising start. We alternate, more or less, between adding features and reflecting on - and cleaning up - the code that results. The cleaning up stage is essential, since without it we would end up with an unmaintainable mess. We’re prepared to defer refactoring code if we’re not yet clear what to do, confident that we will take the time when we’re ready. In the meantime, we keep our code as clean as possible, moving in small increments and using techniques such as Null Implementation to minimise the time when it’s broken. Section on “Emergent Design” within current draft of Growing OO Software, Guided by Tests by Steve Freeman & Nat Pryce.

I presented several characteristics of people that have recognizable effects on methodology design.

The first is that we are sensitive to communication timing and modalities. The prediction is that physical proximity and ease of communication has dominant effect.

The second is that people tend to inconsistency. The prediction is that methodologies requiring disciplined consistency are fragile in practice.

The third is that people vary, not just daily, but from group to group. Methodologies don’t currently, but do need to deal with this cultural variation.

The fourth is that people like to be good citizens, are good at looking around and taking initiative. These combine to form that common success factor, “a few good people stepped in at key moments.”

Characterizing people as non-linear, first-order components in software development by Alistair Cockburn.
To me, taking that longshot at a venture backed liquidity event that leaves you with enough money to be rich is akin to playing the lottery. But building your own business that you control feels a lot more like the ideal of entrepreneurship that many people claim to espouse. Given the odds, is taking venture capital the best way to get rich?
Lynda tells Jill how sad she is that the plinth entries are selected by a computer.

BBC - Radio 4 - The Archers - Synopsis

But not even a mention of my elegant code :-(

In the last several years, though, Agile has become more popular. The market has grown, but the number of organizations willing to be great has shrunk. The emphasis has shifted from “be great” to “be Agile.” And that’s too bad. As much as I like it, there’s really no point in Agile for the sake of Agile.

Worse, with so many organizations interested in “being Agile” rather than “being great,” a whole industry is springing up around providing watered-down, non-threatening, non-boat-rocking (and non-functioning) Agile. If the point is to Be Agile, there’s no need for Agile to actually work. Sell a certificate and walk away. Everyone’s happy, right? Right?

Yuck.

James Shore: Stumbling Through Mediocrity
- Don’t track bugs, fix ‘em.
- Manage debt to keep moving fast.
- Eliminate individual anxiety and keep the team resilient by pair-programming all the time.
- Don’t branch and don’t stay away from the trunk for longer than 2 hours.
- If the build breaks fix it immediately, otherwise what’s the point of having it.
- Operate all the environments, including production, yourselves. And do your own support.
- Plan just enough when it’s needed to prevent stalling.
Selected bullet points from AGILE IN ACTION: ‘No excuses’ done done