“Rather than boiling the ocean, we take a little cup at a time and boil it.”—Barney Gomez, chief technology officer, California Department of Health Care Services, on extreme programming.
Immutability can be a very dangerous thing.
When you’re working on a blockchain development project, the implications of bad code can be catastrophic. That’s because the blockchain is immutable. You can’t go back in and de-bug it.
This means that, in Ethereum, once you deploy a bad smart contract, anyone is free to attack it as long and as hard as they can.
Of course, Ethereum didn’t invent the smart contract, but it has popularized it, and made it doable on the blockchain. Ethereum lets developers program their own smart contracts which are executed according to the rules the developer programed. Unlike traditional contracts, a smart contract automatically executes those obligations, often through an escrow-like account. Also unlike a traditional contract, when the terms of a smart contract are recorded on the blockchain, they cannot be altered.
And there’s the rub.
“Smart contract development is different from most other contemporary development as there are rarely any easy upgrade paths,” explains Daniel Zakrisson, editor of ICONOMI. “Deploy it and once the contract is in use you are pretty much stuck with it.”
The only way to be confident your smart contract is solid is to test meticulously — and that means continuously. This is why we’re fans of Extreme Programming (XP) for smart contract development. XP is often used when having accurate code is a matter of life and death; XP was used at NASA’s Jet Propulsion Laboratory, which, among many other feats, developed software for Mars exploration missions.
It’s a perfect fit for blockchain. Presenters at ETHDenver offered a tidy analogy explaining why blockchain is different. Maybe not Mars-exploration different, but nevertheless…
“If building most traditional webapps is similar to a minute clinic, then blockchain is more comparable to an Emergency Room. Some issues are small, but most of them are extremely hard to fix once you get past a certain point, if at all, and every possible negative outcome has to be accounted for. If not, you could be facing dire consequences.”
So blockchain and XP make sense together, and smart contracts and XP are absolutely ideal for each other. XP emphasizes business results first and takes an incremental approach with a focus on continuous testing and revision.
In an XP environment, code is vigorously tested throughout the project development cycle and developers implement any changes.
To better understand why XP is ideal for smart contracts, let’s take a closer look at what XP entails and where it came from.
A Little History
XP is an Agile software development methodology intended to improve software quality and responsiveness to changing customer requirements. Agile approaches call for iterative cycles of analysis, design, coding and testing to progressively elaborate/define a software product. They generally include strong customer involvement in the software development process, good communication inside teams and iterative cycles of development, including XP and SCRUM.
The first official XP project was started March 6, 1996, by a team at Chrysler as a way to manage the company’s payroll.
So, what does it do? Here’s a good introduction:
“Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested.”— Extreme Programming: A gentle introduction
A Philosophy of Coding: The Five Basics
XP is founded on five basic principles:
Communication: XP doesn’t depend on extensive documentation. Rather, XP proponents stress the importance of communicating using whiteboards, face to face discussions, etc.
Simplicity: What’s the simplest thing that will work? That’s at the heart of XP. IBM — at the forefront of blockchain — is a fan of XP’s simplicity:
“One main tenet of extreme programming is a focus on simplicity. The idea of programming in pairs is to ensure that code is constantly reviewed while it is being written. Through pair collaboration, code reviews happen in real time and knowledge is shared without the need for extensive documentation or education sessions. At IBM, we have found that pair programming is a great way to teach the team skills. This practice is founded on the belief that the simplest and often the most effective way to learn is by doing. […] At IBM, we believe that ‘less is more’ and that ‘no code has no bugs.’ These statements recognize that all code has bugs, and at the same time say that a simpler solution to a problem often will have fewer lines of code. Concise code is usually easier to understand and, therefore, more likely to work. In the end, there are no bugs in code that you don’t ever write and won't ever need.”
Feedback: Feedback — from clients, other teams etc. — helps identify areas for improvement and optimization. Teams also get feedback because they test their software starting on day one. No one “owns” the code. This may be the most distinguishing characteristic of XP. “This essential loop of going back and forth differentiates Agile systems in general and Extreme Programming in particular, from other software project management methodologies,” EduCBA explains in its XP primer.
Courage: This is the hardest to describe, so we’ll just go directly to the source, one of XP’s founders, Don Wells, at www.extremeprogramming.org/: “We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes whenever they happen.”
Respect: Respect refers not only to team members, clients, and oneself; it also implies respect for the code being written and for the client’s expectations and needs.
The Basic Practices
There are 12 basic XP practices, sometimes referred to as rules. But Wells emphasizes that they aren’t hard and fast rules: “Our rules set expectations between team members but are not the end goal themselves. You will come to realize these rules define an environment that promotes team collaboration and empowerment, that is your goal. Once achieved productive teamwork will continue even as rules are changed to fit your company's specific needs.”
If you’re familiar with XP, you know some of these 12 practices go by different names. We’re starting at the source — www.extremeprogramming.org/ — but also pulling in more contemporary interpretations, including those from Tech Republic, and Agile in a Nutshell.
- User stories (“the planning game”): User stories serves the same purpose as use cases. The customer defines the desired features for the new application and describes each feature’s business value and priority. This is not a requirements document, Wells insists. “User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement.”
- Small releases (building blocks): Applications are developed and delivered in a series of small, frequently updated versions.
- System metaphor: This is simply a standardized naming scheme. Each project has an organizing metaphor, which provides an easy-to remember, even intuitive, naming convention.
- Collective code ownership: No one person owns or is responsible for individual code segments. Code is reviewed and updated by everyone on the team, allowing for a more collaborative effort. Ideally, any developer on the team can work on any part of the codebase at any time.
- Coding standard: This is what enables collective ownership. Everyone codes in the same style and format, allowing for collaboration and rapid code sharing. “Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.” (Agile in a Nutshell)
- Simple design: This, of course, harkens back to the principle of simplicity. The best design is the easiest one that works.
- Refactoring: This allows you to improve the code without changing or breaking its functionality. “Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.” (Agile in a Nutshell)
- Continuous Testing: Before programmers add a feature, they write a test for it. Each building block (small release) is thoroughly tested prior to release.
- Pair programming: As the name suggests, XP programmers work in pairs. (More on this below.)
- Continuous integration: Software builds are completed several times a day. This keeps all developers on the same page by keeping the application up to date with the most recent coding changes. All changes are integrated into the codebase at least daily.
- Sustainable pace: For XP practices to be effective, developers can’t be burned out or sleep deprived. Occasional overtime is tolerated, but too much overtime is considered a sign that something’s wrong with the process.
- On-site customer: Ideally, the customer must be available at all times to set priorities, deliver and establish requirements, and answer questions.
Pair Programming, DevOps and XP
Based on these practices, it’s clear that, like DevOps, XP ignores the mythology of the solo programmer working 24/7, writing massive amounts of code.
And yes, we know: Many blockchain developers do work alone. But we believe that blockchain in general and smart contracts in particular are not cut out for the Lone Ranger approach. XP, with its focus on collective ownership, on-site customers, and continuous integration, is playing an increasingly important role in blockchain development.
One example that falls into both the XP and DevOps categories is pair programming. Two developers work from a single workstation. One writes the code, the other reviews it as it’s entered. IBM identified several benefits of pair programming, including
- higher-quality code because of real-time review;
- better-designed solutions through shared collaboration;
- better distribution of knowledge across the team;
- faster delivery because solutions are found more quickly; and
- consistent coding practices through collaboration.
“Even before pair programming had a name, it was common to find programmers working in this manner, as programming lends itself to challenging problems that are often best solved by two people working together,” according to an IBM primer on the approach.
Test, Test and Trust
Last year, Nigel Montgomery, research director at Gartner, offered this dire warning about smart contracts: “Today the technology is immature and mercurial, and once live, the outcome is irrevocable. Smart contracts are something CIOs should invoke at their peril.”
He has a point. They should not be approached lightly, and they shouldn’t be trusted to a solo developer working on his 20th hour of coding and 10th Red Bull. Smart contract development is an iterative, collaborative process with no room for error. But with the right partner, it doesn’t have to be risky at all.