DK: A software architect is responsible for designing a software system that meets its requirements. Those requirements can involve functionality, ease of use, scalability, performance, security, robustness (for example, a system that controls critical medical equipment), and extensibility. Any real software project will have to make tradeoffs in these areas and those tradeoffs are often too complex to foresee everything that could go wrong during implementation, including changes in requirements after the project starts. A good architect will make the right design decisions so that unanticipated problems can be solved with relatively small changes to the overall system architecture.
DDJ: Okay, more specifically, what is your role at Curl as VP of Engineering and CTO?
DK: My current role is more on the management side. Curl has been around for 10 years and in my earlier days, I was very involved in software architecture. I continue to be involved as time allows because it is something I like to do.
DDJ: A recently released tool from Curl is Curl Nitro, an extension of the Curl RIA platform. Can you tell us about the role of the software architect—you in this case—in the development of this project?
DK: Well, Nitro is really Curl Version 7.0. The product is quite mature and has a large code base. So at the detail level, there cannot be a single architect. One of the important features was an extension of the offline and run-outside-of-the-browser functionality that has been present since Version 4.0. There has been a trend towards allowing users to "install" applications. We wanted to provide this capability, but without the user having to grant unnecessary system privileges. The challenge here was to provide the security and deployment properties of sandboxed web applications, but in a way that lets end-users treat them like installed applications.
DDJ: What's the most difficult part of an architect's job when developing software like Curl Nitro?
DK: The fact that Curl is a development platform introduces architectural challenges that are not present in most applications. You have requirements such as making it as easy as possible for users of the platform to develop applications with high performance, security, etc. It is not obvious how to map these requirements into a system design. The key areas we focused on were extensibility, performance, and minimizing the number of lines of code needed to perform important functions. Performance is one tough example. If an architect does not pay sufficient attention to performance at the beginning, it is often very difficult or impossible to optimize performance later without essentially starting over. But too much attention to optimization early on can waste a lot of time when it turns out to not matter. A good architect will have a sense, based on intuition and experience, of what the right tradeoff is.
DDJ: Should an architect get involved in hands-on coding?
DK: That really depends on the size of the project. It is good for everyone on the team if the architect also is involved in coding. But in a very large project, the architect may have to own the complete high-level understanding of the system and may not have time to contribute to coding. But all the architects I have known would like to be doing at least some coding, even if they can't. Experience and love of coding are important parts of what makes a good software architect.
DDJ: The bigger the project, the more important it is to have an architect? True or false? Thoughts?
DK: I think it is important for any project to have an architect whether it is big or small. But a large project will require many architects operating at different levels of abstraction.
DDJ: Are there tools that help architects in their job? Modeling tools, for instance?
DK: Modeling tools can certainly help with object-oriented design. They would be most helpful when the requirements are very specific and not changing frequently. But the most important thing is that the architect is only one part of a successful team. Particularly for a product like Curl, the team must understand the architecture and what the goals are. That includes developers, test engineers, and writers. It is very important to have good specs, test plans, and other practices to ensure a smooth process from design through delivery.
