FEATURED STORY

How the DevOps revolution informs software architecture

The O'Reilly Radar Podcast: Neal Ford on the changing role of software architects and the rise of microservices.

hans_christian_hansen,_architect_seier+seier_Flickr

In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.

Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:

“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”

Read more…

Comment: 1

Signals from the O’Reilly Software Architecture Conference 2015

From careers to culture to code, here are key insights from the O'Reilly Software Architecture Conference 2015.

Experts from across the software architecture world came together in Boston for the O’Reilly Software Architecture Conference 2015. Below we’ve assembled notable keynotes, interviews, and insights from the event.

Software architects: post-“post-useful”

The old notion of a software architect being a non-coding, post-useful deep thinker is giving way to something far more interesting, says Neal Ford, software architect and meme wrangler at ThoughtWorks. “Architecture has become much more interesting now because it’s become more encompassing … it’s trying to solve real problems rather than play with abstractions.”

Read more…

Comments: 2

A software engineer’s role traversal

Software engineer and author Jason Myers on changing roles in a changing market.

jm_snake

We often hear about how the tech job market is booming and has space for newcomers, but what does that mean for the developers already in the market? In December of 2014, Fortune.com predicted that 2015 would be an excellent year for developers to change jobs. Citing Dice.com, they note that jobs are popping up all over the country. In fact, Dice’s survey also reports 40% of hiring managers seeing voluntary departures, a higher number than was seen just six months earlier.

These are all large, general numbers. What does a job change, and the changing market, look like for individual developers? To get a better sense, I spoke with Jason Myers, who is working on our upcoming Essential SQLAlchemy, 2e title. Jason recently went from working for the email marketing service Emma, Inc., to working for networking giant Cisco. Here, he talks about how a change like that feels, and how the market looks to him.

Read more…

Comment

3 simple reasons why you need to learn Scala

How Scala will help you grow as a Java developer.

Editor’s Note: If you’re a Java developer these days, one who is fully entrenched within the Java SE or Java EE development environment, you’ve grown accustomed to waiting for new features and updates. Change happens at the speed of dial-up, which is a blessing for legacy code, servers, and software infrastructure that thrive on maintaining profitable grace through clunky predictability. You may have even dabbled with a JVM language, such as Scala or Clojure, thinking you could do more with less code — and you can — but then you’ve realized the barrier to entry is steep compared with the needs of meeting day-to-day responsibilities. Why learn something new, you’ve thought, when there’s no strong incentive to change?

With Scala Days nearly upon us, the Fort Mason Center in San Francisco will be awash with developers excited to share ideas and explore the latest use-cases in this “best of both worlds” language. Scala has come a long way from its humble origins at the École Polytechnique Fédérale de Lausanne, but with the fusion of functional and object-oriented programming continuing to pick up steam across leading-edge enterprises and start-ups, there’s no better time than right now to stop dabbling with code snippets and begin mastering the basics. Here are three simple reasons why learning Scala will help you grow as a Java developer, as excerpted from Jason Swartz’s new book Learning Scala.

1. Your code will be better

You will be able to start using functional programming techniques to stabilize your applications and reduce issues that arise from unintended side effects. By switching from mutable data structures to immutable data structures and from regular methods to pure functions that have no effect on their environment, your code will be safer, more stable, and much easier to comprehend.
Read more…

Comments: 2

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…

Comments: 4

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