Software architects have it easy, or so many coders and engineers believe. Find out what an architect's day-to-day working life really looks like in this Full Java life interview. Java programming veteren Bruce Brouwer discusses his approach to upgrading legacy Java web applications to a service-oriented front-end architecture, his rapidly evolving web UI toolkit, and why he generally prefers working with Java's constraints to opting for a less rigorous JVM language.
Like many software developers, I’ve always been skeptical of architects. Too often they seem to make demands about how the work of coding will be done without having to live with the consequences. I'm the guy who once wrote an article called "Why I'm not an architect," and I have been known to quip "His favorite IDE is MS Outlook."
Then I met Bruce Brouwer, an application architect at Gordon Food Service (GFS), a family owned food distributor with offices in Michigan. When I met Bruce, he was deep into his computer screen, looking at actual code. His task was to integrate GFS's Ruby-based Compass compiler into an application build using JRuby, and his approach to the work seemed anything but abstract. I was intrigued.
Bruce's job at GFS, he says, is to both set the vision for future web applications and demonstrate his vision with proof-of-concept applications. He typically works with development teams on the first few implementations of a roll out. The cutting edge issue Bruce was working on, on the day we met, was how to move GFS past traditional request/response web applications into a service-oriented front-end architecture (SOFEA), where all the presentation logic is handled in the browser rather than on the server.
Bruce shared some of his ideas for pushing beyond classic service-oriented architectures (SOA) into more message-based paradigms. These ideas have to work on paper, but Bruce needs buy-in from the technical teams in order to make them work. As an architect, he provides implementation guidance across teams, technologies, and even legacy systems. His is a fascinating perspective, and one I thought worth sharing.
Matt Heusser: Talk to me about your career as a programmer and architect. How has your role changed over time? How did you approach your role as a junior programmer versus as a mid-career programmer or as an architect today?
Bruce Brouwer: After college I moved into my first real job. From almost the very beginning, I was pushing at the boundaries. There was this tedious process of updating the data access layer of this application. All the new hires were subjected to the pain of working that process. After my first time, I decided to automate it. Management was impressed, so they asked me to run it for all the tables in the database. It took about a week to clean up the mess from my automating what turned out to be a broken process.
As I continued in my career, I found many more opportunities to make things easier to develop. A phrase quickly became associated with me: "One line of code." I kept pushing my work to make things simpler for developers. I wasn't truly happy with my work until you could do something that was previously complicated, but now was as simple as one line of code.
But you can only go so far by making better tools. I had to start thinking on a bigger scale. When you start playing in this bigger world, you again need to push the boundaries. Maybe a SQL database isn't necessary. Maybe waiting for a response from that service isn't the best use of time. Maybe Java doesn't cut it anymore.
Okay, that last point is a bit contentious, but it is a question that I have asked. But simply asking these questions isn't the real job of an architect. Even designing an absolutely brilliant architecture isn't enough. You need to be able show others how to get there, step by step. An architect needs to be grounded in the real world, experiencing the problems that come from what they have designed. This takes both technical and social effort.
Matt Heusser: What technologies are you working with now?
Bruce Brouwer: Not too long ago I decided to fill out my LinkedIn profile, listing all the technologies that I actually use. During that effort, I learned that LinkedIn has a limit. I don't say that to brag, I think that is a problem. There are just too many things that you need to know to be a good developer in today's world. We need to do better at constraining the list of tools that we use to do our job.
Largely, what I use is Java and Spring. What I have been recently working on is designing the future of web application development at GFS. GFS has been developing web applications using Java EE from the time before there were frameworks like Struts or JSF. Now there are some new ideas that challenge these server-side web frameworks, like SOFEA and responsive design. Yes, we could shoe-horn these ideas into the current Struts 2 infrastructure that we have, but it is time to make a real break between the UI and the back end. This way we will be better positioned to respond to the pace of change in the web UI layer without having to make such drastic changes in the service layer.
"Now there are some new ideas that challenge server-side web frameworks, like SOFEA and responsive design. Yes, we could shoehorn these ideas into the current Struts 2 infrastructure, but it is time to make a real break between the UI and the back end."
For this new web UI, I have almost a completely new tool suite: Angular and Twitter Bootstrap, and of course jQuery. What I am pursuing is to build the entire UI from static resources. None of the UI will rely on the server generating any dynamic UI content. It needs to work in a plain Apache Web Server; no PHP, no Perl, nothing.
As for the service layer, GFS has an enormous Java legacy. And for the most part, it's actually pretty good. GFS has pursued a service-oriented architecture for years, utilizing Spring POJOs. Services are at the core of SOFEA. JSON is the data transport of choice these days, and Spring MVC makes it easy to expose these POJOs via JSON. So SOFEA is actually a really good fit for GFS.
The challenging part, though, has been that vision of making that web UI truly static. To make a good web app that is fast requires some other tools. I am using Compass for managing CSS. For JavaScript I am using the Google Closure compiler, which has the awesome feature of source maps. Throw in some other requirements of cache busting and making it easy to develop and all of a sudden you need a complete build solution for something that ends up becoming just a bunch of text files.
There are a few impressive tools that have started to answer these challenges. I've been pretty impressed with Grunt and Yeoman and I even made the pitch to GFS to abandon Maven for Yeoman; at least for the web UI. I got the impression that ditching Maven might be a bit too far for tools that aren't even a year old yet. So I started making a Maven plugin to pull this all together. There are Maven plugins to handle Compass and Closure, but they don't provide a complete solution that can even modify the HTML development versus production and also provide live-reload functionality. This has actually been a wonderful experience writing this Maven plugin, which of course is written in Java.
Maybe soon I'll be able to convince management to allow me to give this back to the open source community.
Matt Heusser: How long have you been an architect? What were you working on a year ago?
Bruce Brouwer: I've been an application architect for eight years now. I made the jump from senior programmer to architect when I moved to GFS.
My previous big project, which I was working on a year ago, was the transition to Google Apps. This was a real learning experience for me as well. I had this grand idea of synchronizing the legacy calendar with Google Calendar during the transition. I used the Google APIs from Java along with Spring Integration to make it all happen. At least for a while. After a few serious glitches, I had to admit that it wasn't worth the risk. Being both the architect and a developer on that project helped me keep the real world in perspective.
"We've had to draw a line in the sand for what is and is not appropriate to use Google for when integrating with our existing systems. It can be difficult when you are forced to temper some of that enthusiasm. "
Google brings a whole new world of possibilities to GFS. We are only starting to feel its impact in the way we design our systems. I've already had plenty of conversations with people who want to use Google because it is the shiny new toy. We've had to draw a line in the sand for what is and is not appropriate to use Google for when integrating with our existing systems. It can be difficult when you are forced to temper some of that enthusiasm.
Matt Heusser: As an architect, you've reached a level that only a small percentage of programmers achieve. Do you have advice for programmers starting out in their career?
Bruce Brouwer: I love it when new programmers come up with an idea to challenge the current status quo. Usually they want to use some new tool to make a task easier. It is when this happens that I can help them look at the bigger picture. Oftentimes that means pointing out the problems with bringing in that tool. Talking through the problems sometimes forces the new programmer to open their eyes to larger issues.
So my advice is to a new programmer is to go ahead and challenge some ideas. Find a senior programmer or architect that you can use as a mentor and voice your idea. Likely the idea won't pan out but you will learn a lot by finding out why you're wrong, not just that you're wrong. But remember, too, that senior programmers and architects can suffer from myopia and you might just find an idea worth pursuing.
Matt Heusser: Who is your customer? (Or, to borrow a line from the Bobs in "Office Space": What would you say you do here?)
Bruce Brouwer: I don't really directly support any customer in the sense that there would be a direct business focus. I'm actually placed within the infrastructure side of IS, along with the DBAs and server admins. The rest of IS really has a focus to serve a particular area of the business. It might seem strange to place a Java developer in infrastructure, but it allows me to focus on issues that have a larger architectural focus than others might have. While others are trying to work through defining business processes, I get to focus more on the technology that is used to solve everyone's problems in a reusable way.
People often ask me to assist other projects; sometimes for extended periods of time. This helps me stay grounded in the real world. It also helps me to spread new ideas throughout the rest of the development teams. I have found that when I was asked to play the part of the project's architect my influence was limited to more junior developers; it's actually been more useful for me to contribute on other projects that already have an architect, because I can push my ideas with those who are more influential in their part of the organization.
Matt Heusser: How long have you been programming in Java? How have you seen the language and Java programming itself change over those years?
Bruce Brouwer: I didn't really take Java seriously until Java 1.3. So, that would be about 13 years. But even then, Java didn't really become a joy to develop in until 1.5 came around with generics. There are so many good uses of generics, and most people don't seem to use them beyond the Java collections framework.
Back when I started with Java, we wrote almost everything ourselves. Over time, I've seen how the rest of the world has embraced Java, especially in the open source community. That explosion of open source is the most important change that I've been through during my career in Java programming. It's something that really hasn't been matched by any other language until recently.
Matt Heusser: Talk to me about using JRuby at GFS. What's your take on JVM languages; should we all become Clojure programmers now?
Bruce Brouwer: JRuby was really a means to an end at Gordons. Compass is really the premiere Sass implementation out there and it happens to be written in Ruby. I've also used Rhino and Groovy as well on the JVM. I have seen how powerful and capable these other languages are, but so is Java.
Other languages like Scala, and you mentioned Clojure, have gained popularity lately. While you can do the same thing in Scala with something like half the code of Java, I believe readability can suffer more quickly than it does in Java. A while back, I saw a number of contractors with stickers on their laptop that said "Typing is not the bottleneck." I completely agree. Thinking through the problem and making it clear for the next guy is more important than finding clever ways to reduce the number of lines of code you write. Don't get me wrong, maintaining less code is better than more code, but it needs to be clear what is going on.