- Scientific iteration is about shipping to prioritise learning. This is where the Eric Ries Lean Startup fans hang out.

- Greedy iteration is about shipping incrementally to get the value of each increment sooner. This is where the Dan Reinertsen Cost of delay kids are.

- Defensive iteration is building incrementally parts of a whole, not for the value of any increment specifically, but so you’ve defended against having an incoherent whole when an arbitrary product cycle closes. This is the domain of “potentially shippable increment” scrum types.

In short: iteration can mean a few different things, each thing has pros and cons but misalignment is all cons, so double check you’re all aligned and be kind to each other.

This is a presentation I've given about managing the human side of continuous delivery. In my experience, the challenges of deploying dozens of times per day are mostly interpersonal rather than technical.

The thing you should know about writing web-driving integration tests is that doing this well is at least as hard as writing a multithreaded program. And that’s a domain where human competence isn’t estimated to be high. The other problem with testing across process boundaries is that failure is a thing that can’t be entirely avoided.

So what you tend to wind up with there is a lot of tests that work most of the time. Even if you’re really good and prevent most race conditions, you’re still going to have some defects. Given enough tests, that means that one is always failed.

We realized that the whole point of tests is to gain confidence before changing things. And to the extent that there are false negatives in the tests, or the tests gum up the works, they’re doing the opposite of that.

Tests are one way to gain some confidence that a change is safe. But that’s all they are. Just one way.

German companies have a tradition of being thorough and perfectionist. In the digital world, however, you need to loosen those principles a bit. Technology is changing so fast; you need to be fast too. Make decisions even if the information you have is not as complete as you would like.Jeff Bezos put his finger on that when he wrote in his most recent letter to shareholders that "most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you're probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you're good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure."

It's hard to have a consensus about the state of the product because we all track different issues and different feature ideas in different places and different ways. We solved this issue when we do feature development by making a map of the scopes and tracking them in lists. Is there a way we could have a kind of "canonical reference" that is an overview of the whole product as we see it right now, with pain points and opportunities called out?

A crazy idea came to mind that I had to spike. I imagined the whole product projected onto a map, with pins stuck in the areas where we need to fix something or want to change something.

Those people over at Etsy seem to have a good head on their collective shoulders:

[A]re you abstracting away so that you truly can say “I don’t have to worry about this”? Or are you abstracting away because you’re aware of those guts, but want to focus your attention right now in this area. That is what we’re looking for.

Post-mortem debriefings every day are littered with the artifacts of people insisting, the second before an outage, that “I don’t have to care about that.”

If “abstracting away” is nothing for you but a euphemism for “Not my job,” “I don’t care about that,” or “I’m not interested in that,” I think Etsy might not be the place for you. Because when things break, when things don’t behave the way they’re expected to, you can’t hold up your arms and say “Not my problem.” That’s what I could call “covering your ass” engineering, and it may work at other companies, but it doesn’t work here.

And the ironic part is that we find, in reality, engineers are more than willing to want to know. I’ve never heard an engineer not wanting to know more about networking. I’ve never heard an engineer wanting to say “You know what, I don’t want to care about database schema design.” And so if the reality is that people do care, then it’s kind of a waste of time to pretend that we’re abstracting away. Because you’re going to not care up until the absolute second you do, and when you do, that’s all you want to care about

Abstraction not as a means to mask complexity and shift responsibility, but to help empower you on your current problem without total naïveté. It's not an escape hatch, but a compartmentalizing tool.

An interesting [Tweetstorm][t] follow-up to a [Hacker News comment][hnc] on software rewrites. First, from the [comment][hnc]:

The people who have the skills and discipline to take advantage of a rewrite don't need a rewrite. It's a short distance from that skill set to being able to break the problem down and fix it piece by piece. … Then you have the people who don't have the skills and discipline to continuously improve their code. What the rewrite buys them is a year of nobody yelling at them about how crappy the code is. They have all the goodwill and the hopes of the organization riding on their magical rewrite. They've reset the Animosity Clock and get a do-over. However, as the time starts to run down, they will make all of the same mistakes because they couldn't ever decompose big problems in the first place, and they lack the patience to stick with their course and not chicken out. They go back to creating messes as they go, if they ever actually stopped to begin with. Some of them wouldn't recognize the mess until after its done anyway.

The [Tweetstorm][t] mentions a meeting at Amazon, discussing a big where a big rewrite. Bezos distributed [this 1953 Naval atomic energy memo][m] that drew a distinction between "academic" and "practical" nuclear reactor plants. It's a must read, and even though it is short, here are some larger choice quotes:

The tools of the academic-reactor designer are a piece of paper and a pencil with an eraser. If a mistake is made, it can always be erased and changed. If the practical-reactor designer errs, he wears the mis- take around his neck; it cannot be erased. Everyone can see it.
…
For a large part those involved with the academic reactors have more inclination and time to present their ideas in reports and orally to those who will listen. Since they are innocently unaware of the real but hidden difficulties of their plans, They speak with great facility and confidence. Those involved with practical reactors, humbled by their experiences, speak less and worry more.

• Maintenance work
• Features of the codebase that resist change
• Operability choices that resist change
• Code choices that suck the will to live
• Dependencies that resist upgrading

…

The code that was originally written by a small tight knit team with a clear vision of the problem is now being worked on by (often much more senior) separate teams working in some degree of silo. What was a productive lack of indirection to the code becomes a poorly considered lack of abstraction resisting change.

Hence the paradox: how is it that a team of brilliant senior engineers need 6 months to clean up after that one early programmer’s weekend kludge job?

A customer request starts a process within our company that produces an end result which is of value to the customer. What should happen in between is flow. Work should flow through the organization, everyone pitching in when needed, to finish the work as quickly as possible, but without skipping on quality.
…
**We manage flow to serve our customers better**. As a by-product, people will be happier when they’re actually fulfilling a customer request instead of working on an item completely separated from its original context. Essentially, flow brings back the meaningfulness in our work.

This is not a talk about speed coding, or writing thousands of lines of crappy code in a weekend. This is a talk for software craftsman who test drive clean code, but who also have a nagging feeling: “Man, I know I could be doing this faster.” We’re going to discuss everything from touch typing, to keyboard shortcuts, to faster pair programming techniques, to hardware, to build automation, to staying in the zone, to caffeine consumption, to ergonomics, to music and headphone selection, refactoring, language and framework selection, tech debt management, rapid prototyping, whiteboard design sessions, back of napkin mockups, guerilla tactics for getting in front of requirements and staying there, and what to do when you’re 30 lines down a stack trace and someone wants to tell you about something funny their kid did over the weekend.

The fact that both content and styles can be managed by plain text files should have inspired Apple to introduce something based on the same principle. … With current native tools you cannot succeed in management of complex auto layout: we neither have visual tools that would allow us to set up constraints for complex views nor we have fine-grained DSLs developed by Apple officially.

**This is why so many Open Source solutions appear to compensate that lack of native support for semantics of UI …. It is worth mentioning that so far AFAIK nobody ever tried to create alternative to Interface Builder because nobody wants to compensate THAT mouse-driven thing.**

Nobody is trying to build a better Interface Builder because it's a dead end. WWDC-talk-driven-development, not scalable for real world development.

- Set up a proxy NSArray that looks like it holds an entire paginable data set
- Upon access of placeholder items, fetch the real content
- Set up your views and view controllers to only deal with this NSArray proxy
- Profit

It just goes to show you that if you focus on messaging well-factored objects, not additive procedures, as the core of your design, things have a tendency to fall into place. From day one, the controller should be written in a manner that it’s displaying some opaque collection of data. Whether that data is backed by a remote API and/or populated by batches of pages *should not* change any substantial elements at the controller/view layer. We’ll delegate responsibilities behind different objects and proxies while keeping the interface sound.

This is also a perfect example of, “design is how it works.” This infastructure makes for a better experience both in the code *and* the user experience. The UI feels more responsibe and fluid, in part because that’s the aesthetic of the code.

A good example of extracting behavior out of large UIViewControllers and into reusable objects that the author calls intentions. These plain objects compose very well right from Interface Builder, injected with dynamic behavior via IB’s runtime attributes.

Something like the ObserveIntention makes totaly sense – a reusable object for configuring a binding between a source and a target – but some of the other intention objects seem awkward given their ties to delegate interfaces. The model containers also seem to be a smelly layer of indirection to compensate for IB and nibs’ shortcomings around runtime outlets.

It's a little frustrating to read this tale of iOctocat moving from a paid app to a freemium in-app purchase version. Yes, iOctocat has received more downloads, but that alone doesn't help the developer continue improving the product. It's early, and the developer is hoping for a longer term return on the freemium model (more people using, more people catching the bug to upgrade). It could be promising, so I guess we will see.

Now, iOctocat isn't the best possible app, but it is pretty good. It delivers a valuable iPhone experience to GitHub. I use it routinely, if only for the feed aspect to help me keep up with my GitHub network's activity. I suppose what's frustrating is the target audience is people who not only need well-crafted software, but it's people who in-theory know what it takes to build that software and why it's important. Yet, there's still an overwhelming amount who shrug off the idea of oaying for it.

Of course, my frustration is worthless. There are a lot of other factors at play, and pricing things to capture their value is not easy.

In other languages, you're in a different environment operating your tools by remote control. You're limited by the abilities of your tools and you're not able to easily manipulate things in your environment. You can try to get closer and closer to the feeling of being there with virtual reality or better robotic probes, but in the end, there's nothing that's quite the same as swimming with the fish.

More great practices from Facebook. The presenter talked repeatedly about Facebook's obsession with speed, but he didn't mention anything about their development practices with respect to the Android emulator.

Android Bootstrap includes a full working implementation of Fragments, Fragment Pager, Account Manager, android-maven-plugin, Dagger, ActionBarSherlock 4, ViewPagerIndicator, http-request, GSON, Robotium for integration testing, API Consumption with an API on Parse.com and much more.

Link-bait-y title but good points regarding “microlibs” and many people's approach towards development. Also, jonsterling offered a good retort[1] that pointed towards a real lack of progression in the community and tools.