Variations in Test-Driven Development
“Red-Green-Refactor” is a familiar slogan from test-driven development (TDD), describing a popular approach to writing software. It’s been both popular and controversial since the 2000′s (see the recent heated discussions between David Hansson, Bob Martin, and others). I find that it’s useful but limiting. Here I’ll describe some interesting exceptions to the rule, which have expanded the way I think about tests.
The standard three-step cycle goes like this. After choosing a small improvement, which can be either a feature or a bug fix, you add a failing test which shows that the improvement is missing (“Red”); add production code to make the test pass (“Green”); and clean up the production code while making sure the tests still pass (“Refactor”). It’s a tight loop with minimal changes at each step, so you’re never far from code that runs and has good test coverage.
By the way, to simplify things, I’ll just say “tests” and be vague about whether they’re technically “unit tests”, “specs,” “integration tests,” or “functional tests”; the main thing is that they’re written in code and they run automatically.
Red-Green-Refactor is a very satisfying rhythm when it works. Starting from the test keeps the focus on adding value, and writing a test forces you to clarify where you want to go. Many people say it promotes clean design: it’s just easier to write tests when you have well-separated modules with reasonable interfaces between them. My personal favorite part, though, is not the Red but the Refactor: the support from tests allows you to clean things up with confidence, and worry less about regressions.
Now for the exceptions. Read more…
PayPal has gone through a cultural transformation with radical transparency as a cornerstone of the plan.
Three years ago, PayPal was growing exponentially, staying profitable and was considered the most successful online payments company in the world. This should have been the recipe of a company that was attracting top talent across the globe, and keeping their core engineers happy, thriving, and innovative. But, at the time, the PayPal engineering team wasn’t where they needed to be to stay ahead of the curve — they didn’t have the process, the tools, or the resources to extend their talent and stay engaged in creating amazing products and services.
Leadership had encouraged the formation of engineering silos to “concentrate expertise,” but this made it incredibly challenging to get things done. At the same time, popular services such as Google and Amazon were raising the bar for everybody. All businesses — not just software-focused businesses — needed to have websites (and mobile apps) that were snazzy and responsive in addition to being reliable. PayPal engineering needed to push the proverbial envelope to stay competitive in a fierce and unrelenting industry landscape.
For PayPal, the transformation started at the edge of the stack. The Kraken project, which was started by an internal team to support a new checkout system, proved that an open source platform could reduce time to market and still perform at scale. This was achieved largely in spite of the silo culture that ran rampant and tended to restrict innovation and creativity. Support from senior management and perception of less risk at the edge of the stack helped the project and ultimately unleashed a gold rush of interest in repeating the win with releases of internally developed improvements to other open source projects. When I came into PayPal, I received an avalanche of mail from teams who wanted to “open source something.”
A suitable network topology for building automation.
Editor’s note: this article is part of a series exploring the role of networking in the Internet of Things.
Today we are going to consider the attributes of wireless mesh networking, particularly in the context of our building monitoring and energy application.
A host of new mesh networking technologies came upon the scene in the mid-2000s through start-up ventures such as Millennial Net, Ember, Dust Networks, and others. The mesh network topology is ideally suited to provide broad area coverage for low-power, low-data rate applications found in application areas like industrial automation, home and commercial building automation, medical monitoring, and agriculture.
Your views on full-stack development could be featured at OSCON. Here’s how.
We’re putting together a series of short videos that explores the trend of full-stack development from the point of view of people who consider themselves to be full-stack developers—as well as those who’d like to be.
This means your insightful perspective on full-stack development could be seen by new developers and industry experts alike.
Want to participate? Here’s what you need to do:
Submissions are due by the end of the day on Monday, July 14. Read more…