I attended the SATURN software architecture conference in Baltimore the week of April 27. This conference is sponsored by Software Engineering Institute in Pittsburgh, and it has a number of tutorials, technical talks, panels, and workshops on software architecture and software engineering topics.
SATURN is a small conference -- only about 215 people at SATURN 2015 -- but the talks and tutorials are very useful for many software professionals. It is a good blend of experience reports, tutorials, and software industry experts.
Most of the talks and panels at the SATURN conference were recorded. Links to the recordings will eventually be posted on the SATURN 2015 home page:
The main lessons from the SATURN conference:
There were four events at SATURN related to Microservices: a full-day workshop discussing research questions and practical questions about Microservices, a panel session on Microservices experiences which included a talk by Microservices pioneer Sam Newman, a “mock trial” of Microservices featuring Sam Newman and Simon Brown, and a presentation/discussion about the feasibility of using Microservices to support refactoring a legacy application.
Microservices is a design approach for building complex distributed systems. The system is divided into many small “services”, and the services are only allowed to communicate through inter-service messages. Unlike the SOA (Service Oriented Architecture) standard, service developers are free to choose any kind of message format or message channel. The result can a simpler, less bureaucratic, and less complex architecture.
I have a separate detailed writeup of the four SATURN sessions that I attended that focused on Microservices.
The main take-aways:
Mary Shaw ran a very good keynote on the question of whether software engineering is really engineering. She says that the term “software engineering” was coined in 1968 as an “aspiration”, not a true evaluation of current software development practices.
Mary’s thesis is that there are three stages on the road to making an “engineering” field. The first step is a “craft” – a set of individual skills that are mastered and communicated to others. The second step is “commerce” – the application of production skills and management to make the craft more repeatable and productive. The third step is “professional engineering” – the addition of “science” (a set of scientific principles, rules, reasoning, and practices).
This model works for civil engineering, which had to advance from building simple structures with basic materials and rules of thumb to building advanced structures with scientific knowledge that accumulated from theory, testing, and analysis of failures.
Mary’s explanation of the advance of software practices is similar. In early programming, it was mostly a craft. In the 1970s through the 1990s, there was a fair amount of work on systematic software development, which did have a positive impact on managing big projects. But it was still just at the “commerce” level – not much “science” to the innovations.
The good thing was that we codified a lot of knowledge and fundamental ideas:
Software architecture really emerged in the 1990s, and it has provided more systematic information for design decisions – architectural styles, explanations that help practitioners.
Mary’s conclusion is that we aren’t really doing “engineering” yet, or at least we aren’t doing it consistently. There are too many times where our engineering practices don’t protect us from major software problems: Toyota’s problems with unintended acceleration, many cases of data security breaches, all of the problems with the US government healthcare website rollout.
She says we aren’t always using the best-codified knowledge, and we aren’t using the best reference materials. But it isn’t all bad. We are starting to get some success in doing analysis of designs to predict the properties of a product.
How can we do better? Mary suggests that we don’t need to apply the same rigor to all software – we can work based on “risk” or “criticality” – the consequences of failure should drive us to do more oversight in selected places.
We also need to come up with better ways to “search” for knowledge and information – more than just searching web discussion groups. [Editorial comment: I like this idea. Who can trust the information that they find in Slashdot or other web sources?] Mary says we might embed knowledge in task specific tools.
The presentation by Rebecca Wirfs-Brock and Joe Yoder on Agile Quality was really useful. Rebecca is well known for her early work on object oriented design practices and Joe was an early expert on refactoring techniques. They are both very “pragmatic” about the application of agile and lean methods to software development. They shared many of their experiences from consulting with both agile and non-agile development organizations.
The main take-aways from their session:
Next year, SATURN 2016 will be in San Diego -- probably the last week of April. Check the SATURN website:http://www.sei.cmu.edu/saturn/2016Last modified: May 4, 2015