Be Careful with Software Metaphors. Over the years, there have been any number of popular software metaphors that help people radically misunderstand the realities of software development.
Probably the most famous and persistent one is the idea that making software is similar to building a skyscraper (or to building construction in general). This led us, as an industry, to approach software by starting with a knowledge worker “architect” who would draw grand schematics to plot every last detail of the software construction. This was done so that the manual laborers (junior developers) tasked with actual construction could just do repetitive tasks by rote, deferring to a foreman (team lead) should the need for serious thinking arise. It was important to lay a good foundation with database and framework selection, because once you started there could be no turning back. Ever. Software is just like construction, provided you’re terrible at building software. Component Assembly The mental model thus becomes one of assembly. The Serverless Start-up - Down with Servers! This is a guest post by Marcel Panse and Sander Nagtegaal from Teletext.io.
In our early Peecho days, we wrote an article explaining how to build a really scalable architecture for next to nothing, using Amazon Web Services. Auto-scaling, merciless decoupling and even automated bidding on unused server capacity were the tricks we used back then to operate on a shoestring. Now, it is time to take it one step further. We would like to introduce Teletext.io, also known as the serverless start-up - again, entirely built around AWS, but leveraging only the Amazon API Gateway, Lambda functions, DynamoDb, S3 and Cloudfront.
Monitoring Sucks. But Monitoring as Testing Sucks a Lot More. At Devopsdays I listened to a lot of smart people saying smart things.
And to some people saying things that sounded smart, but really weren’t. It was especially confusing when you heard both of these kinds of things from the same person. Like at Noah Sussman’s presentation on how rapid release cycles alter QA and testing, based on the work he did when he was the test architect at Etsy. Sussman is a smart guy who knows about testing. DevOps Isn't Killing Developers – But it is Killing Development and Developer Productivity. Short Commit Cycles. How often do you commit?
Once a week? Once a day? Once an hour? Every few minutes? The more often you commit, the less likely you are to make a mistake. Frankensystems, Half-Strangled Zombies, and Other Monsters. There are lots of ugly things that can happen to a system over time.
This is what the arguments over technical debt are all about – how to keep code from getting ugly and fragile and hard to understand and more expensive to maintain over time, because of sloppiness and short-sighted decision making. But some of the ugliest things that happen to code don’t have anything to do with technical debt. They’re the result of conscious and well-intentioned design changes.
Well-Intentioned Changes can create Ugly Code Bad things can happen when you decide to re-architect or rewrite a system, or start some large-scale refactoring, but you don’t get the job done. Digg v4's Architecture and Development Processes. A month ago history reset with the second launch of Digg v1, and memories are starting to fade since much of the Digg team joined SocialCode four months ago, so it seemed like a good time to describe the system and team architecture which ran and developed Digg.com from May 2010 until May 2012.
There won't be controversy here, not even much of a narrative, just a description of how we were working and the architecture we built out. Team Structure, Size and Organization We have to start with a bit of context surrounding the company's size, how the teams were organized, and how the structure was impacted by a series of layoffs and subsequent hiring.
For focus I'm not covering the Sales, Finance, Ad Management, Design, HR, BD teams and such; they were important pieces of the company and how it functioned, just not central to this particular story. Our story starts with a fairly traditional company layout, with distinct Product, Engineering and Operations leadership. Closing Thoughts. Deploy ALL the Things - Deployment Myths Part 2. Rollbacks and Other Deployment Myths. I came across an interesting post today via HN.
I’m surprised (only moderately) that I missed it the first time around since this is right up my alley: Why are you still deploying overnight? I thought this post was particularly apropos for several reasons. Iterationless Development – the latest New New Thing. Thanks to the Lean Startup movement, Iterationless Development and Continuous Deployment have become the New New Thing in software development methods.
Apparently this has gone so far that “there are venture firms in Silicon Valley that won’t even fund a company unless they employ Lean startup methodologies”. Although most of us don’t work in a Web 2.0 social media startup, or anything like one, it’s important to cut through the hype and see what we can learn from these ideas. One of the most comprehensive descriptions I’ve seen so far of Iterationless Development is a (good, but buzzword-heavy) presentation by Erik Huddleston that explains how development is done at Dachis Group, which builds online social communities. Work is managed using Kanban WIP limits and queues. Should You Ship This Code Before Reducing Technical Debt?! Technical debt is usually perceived as a measure of expediency.
Source: JulesH, Wikipedia, A control flow graph of a simple function. 10 Mistakes That Software Team Leads Make. Roy “Ten Mistakes” (as I shall now call it because I’m too lazy to keep typing the whole title), was a talk by Roy Osherove which I went to at Skills Matter.
He basically takes us through ten common mistakes he sees team leaders make, and offers some solutions to them. He also looks like Adam Sandler, I kid you not. Adam Sandler Here’s Adam, doing some funny acting, or something. Inside the Mind of Jeff Bezos. Manifesto for Software Craftsmanship. Punishment driven development. I'm a big fan of agile development. One of the key concepts that I like the most is story point estimation. The best suggestion I ever heard was to estimate the size of your stories in terms of gummy bears (at which point you can come up with possibly one of the best units of progress measurement, gummy bears / iteration), thereby making sure that nobody gets the impression that you're actually quoting any sort of real unit of time. The exact opposite of this is trying to estimate stories in an agile project in terms of hours.
All too often, even though these realistically are no more than "ideal hours", they are taken literally by everybody and if a developer doesn't manage to "burn down" 80 hours of development per week, they risk being told to either work harder or estimate better (it's often left ambiguous which solution is preferable), leading to what can possibly best be described as punishment driven development. It's our own damn fault. Agile Ruined My Life. I read the reply to my comment on a popular hacker board with sadness: (disclaimer: Agile consultants ruined the software group I work in.)Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil.
Agile Intifada. This blog post was inspired by a link my friend sent me titled “Agile Ruined My Life” as well as a conversation with my friends/co-workers and just wanting to clear up a few things about my previous “Agile Dilemma” post. Some of this is taken verbatim from an email exchange between myself and a few friends I greatly respect.
I agree/like agile in theory and practice. I agree and like TDD in theory and practice. Anything that makes it mainstream can be scathed and unfairly criticized. So now that I have this out of the way, and I will clarify it later, the rest of the post won’t be so nice for some.