FEATURED STORY

How CI removes the pain

The tradeoffs of (accidentally) discarding continuous integration.

Engineering Practices for Continuous Delivery

I’ve given a continuous delivery workshop a few times with ThoughtWorks Chief Scientist Martin Fowler, who tells an interesting story about continuous integration, from the first software project he ever saw. When Martin was a teenager, his father had a friend who was running a software project, and he gave Martin the nickel (or five pence) tour — a bunch of men, predominately on mainframe terminals, working in an old warehouse. Martin remarked that the thing that struck him the most was when the guide told him that all the developers were “currently integrating all their code.” They had finished coding six months prior, yet despite that they weren’t sure when they were going to be done “integrating.”

That revelation surprised Martin: in his mind, software development was a discreet, scientific, deterministic process, not at all represented by the vague comments of these developers. But the practice of as-late-as-possible integration was common back in an earlier era of software development. If you look at software engineering texts of the ’60s and ’70s, every project included an integration phase. This isn’t how we think of integration today, which happens at the granularity of services and applications. Rather, a common practice was to have developers code in isolation for weeks and months at a time, then integrate all their code together into a cohesive whole. And that phase was, not surprisingly, a painful part of most projects. Yet, that type of 60s and 70s workflow is still codified in some version control tools today, even though we have now determined that late integration is the opposite of how we should approach this problem.

Read more…

Comment: 1

Meta-design: The intersection of art, design, and computation

Modern design products should be dynamic, adaptable systems built in code.

intersect_Bill_Ohl_Flickr

Editor’s note: this post originally appeared on Rune Madsen’s blog. It is reprinted here with permission.

This post is about something I see as a continuing trend in the design world: the rise of the meta-designer and algorithmic design systems.

“Meta-design is much more difficult than design; it’s easier to draw something than to explain how to draw it.” — Donald Knuth, The Metafont Book

Until recently, the term graphic designer was used to describe artists firmly rooted in the fine arts. Aspiring design students graduated with MFA degrees, and their curriculums were based on traditions taught by painting, sculpture, and architecture. Paul Rand once famously said: “It’s important to use your hands. This is what distinguishes you from a cow or a computer operator.” At best, this teaches the designer not to be dictated by their given tool. At worst, the designer is institutionalized to think of themselves as “ideators”: the direct opposite of a technical person.

This has obviously changed with the advent of computers (and the field of web design in particular), but not to the degree that one would expect. Despite recent efforts in defining digital-first design vocabularies, like Google’s Material Design, the legacy of the printed page is still omnipresent. Even the most adept companies are organized around principles inherited from desktop publishing, and, when the lines are drawn, we still have separate design and engineering departments. Products start as static layouts in the former and become dynamic implementations in the latter. Designers use tools modeled after manual processes that came way before the computer, while engineers work in purely text-based environments. I believe this approach to design will change in a fundamental way and, like Donald Knuth, I’ll call this the transition from design to meta-design. Read more…

Comment

3 easy reasons why you’ll move your business to the cloud

Migrating to cloud-native application architectures leads to innovation.

Editor’s note: this is an advance excerpt from Chapter 1 of the forthcoming Migrating to Cloud-Native Application Architectures by Matt Stine. This report examines how the cloud enables innovation and the changes an enterprise must consider when adopting cloud-native application architectures. Also, Matt will be conducting a two-day intensive training on the fundamentals of cloud-native applications at our Software Architecture Conference happening March 16-19 in Boston.

Available 2/25/2015

Available 3/18/2015

Let’s examine the common motivations behind moving to cloud-native application architectures.

Speed

It’s become clear that speed wins in the marketplace. Businesses that are able to innovate, experiment, and deliver software-based solutions quickly are outcompeting those that follow more traditional delivery models.

In the enterprise, the time it takes to provision new application environments and deploy new versions of software is typically measured in days, weeks, or months. This lack of speed severely limits the risk that can be taken on by any one release, because the cost of making and fixing a mistake is also measured on that same timescale.

Internet companies are often cited for their practice of deploying hundreds of times per day. Why are frequent deployments important? If you can deploy hundreds of times per day, you can recover from mistakes almost instantly. If you can recover from mistakes almost instantly, you can take on more risk. If you can take on more risk, you can try wild experiments—the results might turn into your next competitive advantage.

The elasticity and self-service nature of cloud-based infrastructure naturally lends itself to this way of working. Provisioning a new application environment by making a call to a cloud service API is faster than a form-based manual process by several orders of magnitude. Deploying code to that new environment via another API call adds more speed. Adding self-service and hooks to teams’ continuous integration/build server environments adds even more speed. Eventually we can measure the answer to Lean guru Mary Poppendick’s question, “How long would it take your organization to deploy a change that involves just one single line of code?” in minutes or seconds.

Imagine what your team… what your business… could do if you were able to move that fast!

Read more…

Comment

Swift-like Swift code

A brief introduction to Swift optionals.

swift_swarm

Swift is becoming the language of choice for more and more developers on iOS and OS X. It’s fast, simple, clean, and has a number of features that simply aren’t available to Objective-C programmers.

While it isn’t a hard requirement to do so, several projects are being ported from Objective-C to Swift — especially those in their early stages — in order to take advantage of the speed, power, and safety of Swift. One of those projects isn’t actually a software project — it’s the upcoming Swift edition of iOS Games Programming Cookbook. When we began updating the book for Swift, the first thing that we had to do was to rewrite all of the book’s code in the new language. However, a straight re-write from one language into another isn’t enough. Swift behaves differently than Objective-C in very important ways, and that means that your ported Swift code needs to be aware of how Swift does things.

Read more…

Comment: 1

Variations in event-driven architecture

Find out if mediator or broker topology is right for you.

Editor’s note: this is an advance excerpt from Chapter 2 of the forthcoming Software Architecture Patterns by Mark Richards. This report looks at the patterns that define the basic characteristics and behavior of highly scalable and highly agile applications, and will be made available to download in advance of our Software Architecture Conference happening March 16-19 in Boston.

Coming soon.

Available now!

The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is also highly adaptable and can be used for both small and large, complex applications. The pattern is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events. 

The event-driven architecture pattern consists of two main topologies, the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events together without the use of a central mediator. Because the architecture characteristics and implementation strategies differ between these two topologies, it is important to understand each one to know which is best suited for your particular situation.

Read more…

Comment

Elvis has left the ivory tower

Pragmatism now rules in team structure, technology, engineering practices, and operational innovation.

Karnakpanorama_b

Ancient history in computer science (2004) provides a gem about the personas that Microsoft envisioned as users of the development environment Visual Studio. They developed three:

  • Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems. He focuses on productivity and learns as needed.
  • Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learning while working on the solution.
  • Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem and typically learns in advance before working on the solution.

These designations received a lot of negative press, particularly around the Mort persona, but I want to focus on Einstein and Elvis.

Formerly, software architects exemplified the Einstein persona: isolated from day-to-day development details, focused on building abstractions and frameworks. The isolation is so common that it spawned its own “Ivory Tower Architect” derogatory phrase. But the realities of building systems that scale as fast as the business does invalidates that approach. Now, Elvis, the pragmatic developer, has ascended to architect while simultaneously descending from the Ivory Tower. Modern architects don’t have the luxury of isolation from the gritty realities of software development today. Pragmatism now rules in team structure, technology, engineering practices, and operational innovation because:

Read more…

Comment: 1