The generation that has been growing up was raised in a world that was radically different from the world we live in now. There is a generational shift, and we know that what we were taught is no longer true:
We were taught to trust information from authorative sources, but we’ve learned to prefer the voices of named individuals. Be personal.
We were taught to categorize, but we know that searching beats sorting. Don’t do the computer’s work.
We were taught that information is scarce, but we know that the real problem is too much information, not too little. Avoid producing unneccessary information.
We were taught that power comes from controlling information, but we know that the greatest threat to information is irrelevancy. Ease up on information security.
We were taught to create products that everyone would want, but we know that needs are individual. Target the few.
We were taught to guide our customers, but we know they would rather serve themselves than wait for a sales clerk. Open your tools to your users.
We were taught to use tools that reside on our computer, but we don’t use the same computer for long and we don’t work alone. We use tools that reside on the web. Be available everywhere.
We were taught that your value is determined by what you have, but we’ve learned that your value is determined by what you give away. Share your knowledge.
We were taught to read the instruction manual, but we know we learn by playing with new tools and toys. Support exploration.
We were taught that good information has a price, but we know that only information that is totally free participate in the network of knowledge. Free your information.
We were taught to spend our time on useful things, but we don’t bother unless it is also fun. Earn our attention.
If you didn’t already know these things, and you feel you’re living in a world you no longer understand, this is why: You are not a digital native.
A big “thank you” to my colleagues Harald, Trond, Mona, Eli, and Jan Helge for feedback on the draft of this article.
What will the daily experience of software development look like, say, five years from now? Have our current processes reached their peak, or will the world continue to change? Alan Kay said “the easiest way to predict the future is to invent it.” Here are some ideas of the future I want to invent: I hope it will be dramatically better than what we currently do.
The term “Continuous Integration” was first discussed when Extreme Programming was starting to garner interest in the late 90s. From then, it has gone from being a manual process that top-notch team used, to being an automated, nearly ubiquitous process. The tools have gone from being home made through demanding tools like CruiseControl to user friendly tools like Hudson. After Hudson, is there still any radical change in store for us?
Somewhat independent of the evolution of Continuous Integration tools, there have been four trends that have developed in the last few years:
Continuous testing: Tools like autotest for Ruby and Kent Beck’s JUnit Max for Java execute your tests after every change you make to the source code. Autotest is widely used within the Rails community, and even though JUnit Max did not get the takeoff Kent was hoping for, I think there’s still great potential in this sphere. I’ve used both tools, and they transform the way I work for the better.
Distributed source control greatly increases our flexibility in terms of multiple sources and stages of source code. Especially Git has seen growing interest in the last two years. Github is quickly becoming one of the large project hosting providers.
Continuous deployment: Organizations have started pushing the result of their continuous integration process further towards production. In the last three years, I’ve worked on two large projects, both of which deploy every build to a test server. The company IMVU, with it’s large customer base, deploys automatically into production roughly 50 times per day.
Smaller checkins: In the last issue of The Agile Toolkit George (no last name given in podcast or notes) suggest checking in every time your build is green. I’ve never worked on a project like that, but I’ve experienced a gradual increase in how frequently we check in.
If we extrapolate from these trends, where do they lead? Here is what I think will be the development experience of advanced teams in the future:
Whenever I save a file, my (fast running) tests are run in the background.
When all the tests run successfully, my changes are pushed up to my personal clone of the repository.
A first stage continuous integration server listens to changes from all the developers repositories. When it verifies the tests, it pushes the changes to the integrated repository.
Every few minutes, my workspace is updated to reflect new changes from other developers in the integrated repository.
After the integrated repository, similar build processes propagate code changes through slower, and possibly even manual tests. The verified result is stored in the staged repository.
At the push of a button, I can roll the code from the staged repository into any test or production environment.
Sounds far fetched? Vincent Massol wrote about unbreakable builds five years ago. Distributed version control is being adopted quickly and will greatly simplify the implementation of such processes. Despite Kent Beck’s regretful decision to stop active development of JUnit Max, I believe the time for continuous testing is near. The process I outline can include as enough verification steps to make the organization comfortable. As the trend of improving test quality continues, this process will be gradually more automated.
The strange thing is that we’ve almost made a complete circle: Before the widespread use of revision control, many developers would edit the code directly in their production environment. Extreme Integration will feel almost like this, but with enough non-intrusive verification to make even the most paranoid test manager happy.
Thanks to Martin Eggen for digging up the information on IMVU’s Continuous Deployment. Thanks to Sarah Brodwall, Trond Pedersen and Finn-Robert Kristensen for helpful comments.
It’s not secret that Apple likes to control their platform tightly. As long as their dictatorship is a benevolent one, whether you find this objectionable or not is a rather uninteresting question.
But lately, the question seems to be less and less academic: Google’s Voice Application for the iPhone got rejected and two existing applications (GV Mobile and Voicecentral) were removed from the AppStore! This is an extremely nasty thing to do to the developers.