Why We Completely Rebuilt DoSomething.org
By Matt Holford
In March 2014, we relaunched DoSomething.org as a completely new website, from web servers to visual design. Here are three reasons why our biggest investment over the last two years has been in moving away from the monolithic, bloated app of 2013 into a much more varied ecosystem, one that yields benefits from product development to staff retention.
1. Destroy the bloated app.
Many organizations start with a small tech footprint: the team bootstraps just enough to get the operation off the ground. But one law of small apps is that touching them makes them bigger. Feature builds, operational changes in the organization, business opportunities: these all cause developers to touch the app, which grows accordingly. The slippery slope to watch out for ends with the one code base that tries to accomplish all things.
A big app is just big — size is not necessarily a problem in itself, although there’s plenty of debate on monolithic vs. alternatives that makes for great reading. (There was a fantastic Twitter throwdown on this in 2014. Go read it, then come back.) A bloated app suffers from trying to solve too many problems, implement too many features, provide too many services.
A big app is just big. A bloated app suffers from trying to solve too many problems, implement too many features, provide too many services.
And it’s often a constricting force: everyone working on the app — which is everyone — is writing in the same language, using the same tools within the same architecture to solve problems. Plenty of very successful orgs have heavily normalized their application stack and toolset, but there are risks: unhelpful specialization, technology blinders, and boredom.
2. Save the sad developers.
We work hard at DoSomething.org to find and keep great engineers. We’ve learned from experience and watching others (lookin’ at you, Etsy) that publicizing the technology we use and the way we build products is a powerful passive recruiting tool. But if we don’t walk the walk, there’s not much to publicize. And we’ve learned that our great office culture isn’t enough to keep serious developers — they need to be learning continuously, because they know that the landscape is constantly changing.
Some helpful warning signs that your bloated app has spread a suffocating blanket of frustration: Developers run home to code side projects in other languages as therapy. They ask to go to conferences that cover technologies you don’t use. They spend an inordinate amount of time tricking out their IDEs. They theorize about the pros and cons of rebuilding your bloated app in Go or Scala. This is developer theater — trying to act like a team that gets real work done. Meanwhile, the bloat continues and your app acquires staggering technical debt. And then you start obsessing about Conway’s Law and whether its chickens are right now roosting in your sprint board.
Great office culture isn’t enough to keep serious developers — they need to be learning continuously.
I want to be very clear: I am not advocating rewriting your app to make people happy. If you’re thinking about this, if the senior engineers are arguing for it, go read the many hilarious and sad things (thing 1 and thing 2, for starters) that exist on the web about rewrites. I should also acknowledge that we did in fact decide to rewrite our app starting in late 2013, and it was insane and terribly complicated, but ultimately worth it.
3. Developers want to learn.
If you are letting your engineers stagnate, then you’re essentially pushing them out the door. Part of the core of software development is discovering new techniques and tools, prototyping in uncertain conditions, trying and failing and learning. All very hard to do on a bloated app: whatever interest the challenges bring is generally outweighed by the complexity of getting any work done at all.
A bloated app makes experimentation harder, in terms of both isolating the experiment and incorporating tests into the app’s approval and deployment stream. Systems like Etsy’s feature switching tools can help greatly with this, but they don’t eliminate the complexity of prototyping or experimenting within a massive codebase. And feature switching isn’t possible without modular code, a concept that can only seem a fever-dream apparition to the disheartened developers we’re talking about.
There’s also the added stress of deploying experiments to production as additions to a monolithic app, as opposed to standalone prototypes. If learning can only happen on the critical path, don’t be surprised if your team shies away from crazy ideas. (Sometimes — often — the crazy ones are what push your organization forward.)
Want to work with us? Check out our jobs page.
Originally published at blog.dosomething.org.
Matt Holford is the CTO of DoSomething.org. He spends time with computers and tweets here.