Does the architecture matter when the ways-of-working change?

More and more embedded companies adopts agile development as their way-of-working for software. For small systems this is straightforward, but for large development projects with hundreds of developers working on the same product there seems to be a typical evolution that an organisation goes through before successfully scaling agile.

Typically the transition starts with individual teams adopting agile practices, but fast iterations and shorter lead-times on team level does not automatically lead to shorter lead-times for new or updated products. The organisation as a whole still uses a stage-gate process or V-model for the product development. If the organisation is successful in changing their entire ways-of-working across all departments it becomes evident if the product architecture supports or hinders the new way-of-working.

The presentation concludes with some general guidelines for how software should be designed to support agile development of large embedded software systems.

Testing as inspiration

Good testing is one of the bottlenecks that needs to be solved if your organisation wants to embrace shorter iterations and quicker feedback. On team level it seems possible to do almost continuos testing, but when it comes to testing integrated systems and products, with deliverables from numerous teams it is critical to have a well-understood test strategy, in the sense what to test, why doing it and when does it needs to be done.

I am the first to admit that I am not a tester, but as a software designer and architect I have been inspired by skilled colleagues who are testers, which is a skill in its own. I regularly follow the blog thoughts from the test eye since they have a view of testing which inspires me as a software architect. Not only do they have a an approach to their craft which I think resonates very well  with how I think software design and development should be done in ana agile context. They also produce some really useful reference material, for example i regularly use their Software Quality Characteristics 1.1, which is the best summary of quality attributes in a concise form I know of. They have other useful material, like Den Lilla Svarta om Teststrategi (unfortunately only in Swedish).

Why I don’t like formal methods…

This is an old post which I rehash since I still think the topic is relevant. I know the topic of is a bit controversial and with it I alienate a lot of researchers and some practitioners. But I will try to clarify my arguments and hope that someone can prove them to be wrong.

  • To be more precise; it is not the formal methods in itself I dislike, but the prominence they seem to have at prestigious software engineering conferences. I think it is not at all in proportion to how well-used formal methods are among professional development.
  • Formal methods are really attractive from a researchers perspective. You can use concepts as theorem, proof and deduction and other nice things. But nice is not the same as relevant.
  • Even though I have heard about formal methods as one of the enablers to establish software engineering as a “real” engineering discipline for almost ten years I still don’t think they are nearer being well-established now than then.
  • Some claim that you can never be sure of the software unless you can prove properties about it, and I agree that presently formal methods are the only technique that promises to do so. But there is a lot of successful software out there which have not been proven.
  • Specifications that fulfil the requirement of being interpreted formally are hard to write. Compare it to learn a new programming language and be proficient enough to use it without any side effects.
    I don’t know if formal methods scale well. It is one thing to use it on a nice prototype system with 30 entities developed in your lab. It is another thing to use it on a system with 500 entities, many of these with quite varying quality in requirements and code.
  • I still don’t know of any that uses formal methods for real; i.e. as part of the normal way in products shipped to customers in business intent on making money. Not in one-shot attempts, pilot projects or by non-profit organisations.

A search on google skolar of industrial+software+formal+methods list papers from the 90s as the top results. And these seem more to be arguments against what I claim above rather than actual reports of usage. This scientific paper seems to have analysed currrent trends, but I would welcome examples that did not require a subscription to Springer.

The Reactive Manifesto

Some years ago I made an attempt to learn Erlang. It is often labeled as a functional programming language, but I think the important property of the language is it model of asynchronous processes, Joe Armstrong’s PhD Thesis provides a very good understanding of the basic principles. I think that some of the mechanisms in the language makes several pattens in Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects unnecessary.

An interesting parallel is The Reactive Manifesto, which to me seems to “reinvent” the ideas found in Joe’s thesis. I totally agree with the manifesto, and think it is applicable for embedded systems with multicore processors as well. It is just too bad that the web site with the manifesto has no references at all; it is impossible to see who wrote the original draft, what they have based the manifesto upon, or where I can find more information to dive deeper into.

Even if an architecture was based on reactive principles I think it would be quite useful to describe the architecture in views. I think the “standard” 4+1 views could be used quite easy for an Erlang or a reactive system system as well.
However it may not be the logical view that the other views are derived from, rather I would think that the process view would be the basic view. Kruchten has an underlying assumption that the logical view is object-oriented. This is obviously not first-calls building block so a different notion of the logical view is necessary.

Joe Armstrong strongly suggest a hierarchy of processes, and this is how I also interpret the Reactive manifesto:

“Large systems are composed of smaller ones and therefore depend on the Reactive properties of their constituents. This means that Reactive Systems apply design principles so these properties apply at all levels of scale, making them composable.”

A problem domain model could be a good way to identify the top-level processes, e.g. the PDM classes could be the initial processes and the asynchronous interaction will be implemented as messages, since reality is asynchronous.