How We Build Features. X Access to videos, talks, and worksheetsInvitation to private Google Plus CommunityJoin in on live Q&A webinars and fireside chats. The Framework Myth. If ever there was an irresistible programmer’s platitude, it is that code-reuse is invariably a good thing. Unfortunately, even the best of advice can be taken to a ludicrous extreme, the construction of generic frameworks within organisations. Mike Mooney gives a warning, based on painful experiences. I was working for a company a few years ago: The company had been around for a while, and had a bunch of genuinely intelligent senior developers working for them.
These developers noticed that a set of common problems arose repeatedly over the course of several years, and there were being solved repeatedly in different ways, at great cost, without reference to the previous solutions. This seemed wasteful since writing data-access code was particularly repetitive and error-prone.
Many teams were sharing the same database but using different code, so there were inconsistencies in how similar business data was treated. Of course, the company had attempted this before. Well, OK, I lied. Technical debt. Technical debt (also known as design debt[citation needed] or code debt) is a neologistic metaphor referring to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete.
If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future. Just like financial debt, these uncompleted changes incur interest on top of interest, making it cumbersome to build a project. Although the term is used in software development primarily, it can also be applied to other professions. Managing software debt. Scrum et al. How Facebook pushes updates. 7 Myths of Entrepreneurship and Programming. (Photo: Stuck in Customs) For the last two years, one name has come up again and again when talking with A-class start-up investors: Pivotal Labs.
See, Pivotal Labs quietly helps dozens of the fastest-growing tech companies in the world, including freight trains like Groupon and Twitter. If your start-up needs to get good coding done quickly, as in lightning fast — or if new hires need to get good at coding quickly — top venture capitalists are likely to look over their shoulder and confide: “Call Pivotal Labs.” I first met the Founder of Pivotal Labs, Rob Mee, when one of the start-ups I advise, TaskRabbit, began working with them. One thing is immediately clear: Rob is obsessed with how to get obscenely high output.
But that’s nothing new. Here’s the differentiator: he’s obsessed with how to get obscenely high output with sustainable effort. My kinda guy. I then posed a few questions: How do you create a scalable, bullet-proof business? Think software doesn’t apply to you? Enter Rob Mee 1. Release Management Done Right. I was having lunch with a colleague the other day when his phone rang with the distinctive office ringtone. Rolling his eyes, he excused himself to take the call.
It was just a run-of-the mill workplace emergency, but there was one thing he said that I couldn’t help overhearing: “fine! I guess we’ll just do a new release for QA.” It stood out like nails on a chalkboard. “Huh, what do you mean?” My palm immediately met my forehead. That got me thinking. In fact, it took me quite a few years as a developer – and a bit of time working on BuildMaster – to realize that not only is this a process, but a whole discipline.
It doesn’t matter how great the code is (nor how well it’s documented or tested) when there are production problems amidst a dozen different-but-related applications that are maintained by various teams and released on various schedules. The Process of Releases and Builds The nouns “release” and “build” are words we’ve obviously all heard before, and most certainly even used.