Architecture at CraftConf

At Craft Conf, there were some presentations about software architecture. I visited all of them and also searched for this subject in other talks. It was interesting to hear the same concepts from more places and to put together a picture how software architecture looks like in the mind of the presenters of today’s conferences.

Stefan Tilkov: Architecture War Stories. It was indeed about weird stories from real life. I wrote down two things: If something is sophisticated, probable you shouldn’t do it. And having many architects is wrong. Many people liked this talk very much but I’m not really interested in real stories. I’m rather interested in the causes behind the stories to be able to avoid situations which head to weird architecture. Luckily for me, other talks were more abstract.

The title of Rachel Laycock’s talk contained the very fashionable word combination “Continuous Delivery” beside “Architecture” so I anticipated it will be great, and it was. Rachel came with the same mindset what I heard two years ago at Devoxx from Kirk Knoernschild. She used the phrase: Architecture is the stuff which hard to change. Architecture isn’t how the big parts fit together as some older sources say. She listed the five most important principles:
  • Last responsible moment. - defer decisions if possible. (Managers demand a stake in the ground approach because it’s more comfortable for them but it’s in violation with modern architecture principles like ‘last responsible moment, defer decisions’.) 
  • Architect for evolvability - don’t try to fix everything. 
  • Postel’s Law, a.k.a the robustness principle: - Be conservative in what you do, be liberal in what you accept from others. In other words, code that sends commands or data to other machines (or to other programs on the same machine) should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear. 
  • Architect for testability - (good design is testable) 
  • Conway’s Law. - The Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”. Another thought about Conway’s law from Fred Brooks (mythical man-month): “Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organisation is important to effective design.” 
She mentioned microservice architecture as a good direction (not the only one who mentioned it) and explicitly suggested not to use ESB or at least not to put any business logic in it. There were three recommended readings (all from Martin Fowler): The Strangler Pattern, Branch by Abstraction - these are articles and a book: Continuous Delivery. Well, not too many words were spoken about Continuous Delivery.

I’ve heard an important aspects about Continuous Delivery at other talk: Don’t use branching but use flexible runtime feature flags.

Title of Simon Brown’s talk operated with the other fashionable word “Agile”. I didn’t like this talk as much as Rachel’s one, maybe because I didn’t hear what I wanted. Simon said, that one architect should be enough in a company, or at least very few. It was said by Stefan Tilkov also, but in other articles I saw opinions about being all developers some kind of architect is the good way. I think the truth might be somewhere between. The other thing which I didn’t like the need for a proper UML diagram of the system, although, sometimes I also print a diagram for myself of the currently developed software, but it’s not necessarily standard UML and far not proper. It’s not maintained together with the code. He mentioned C4 which is also in connection with diagrams. In his definition: Architecture is the significant structure elements or architecture is the structure down until component level. Further advices were: Just enough upfront design is enough, never do Big Upfront Design. He recommended this book. I liked he mentioned that there’s something between monolithic and the very fashionable microservice architecture, it’s impossible to make it in one go, it can be implemented by a continuous transition.

In Nat and Steve’s presentation’s title there were no Architecture just SOLID. I liked very much the different kinds of pasta they showed for us, especially because we were before lunch. So, basically there is the spaghetti code which we know all, it’s the good old procedural legacy code. But OO code is all nice and clean? Well, maybe not. There is lasagne code, which is OO but it’s just layers on top of each other and you never get to the bottom. Ravioli code is also OO but you can’t get how and why the different objects and classes piled up on each other, possibly by the dependency injection framework. And there is OO spaghetti code which is made by events and event handlers and it’s similarly hard to unravel it’s behaviour like the procedural code (if not harder).

Michael Feather’s talk’s title was very specific because it contained the “Conway's Law”. He recommended to read the Leaky Abstractions from Joel. Mentioned Feature vs. Component teams. In some corporation teams may work on features or components and it’s reflected in the software itself. Further terms or recommended practices were: oscillating teams, production coverage, silent alarms, ownership.

Other very popular subjects of the conference was Continuous Delivery and Functional Programming which both have some connection with architecture. Though reactive programming and functional idioms very low-level stuff, not how the big parts fit together and not component-level design, they play an important part in architecture. So yes, I could cite some other talks where architecture was concerned but it’s time to stop here. I learnt a lot, everybody should learn a lot about it, and it’s not the last post from me about this subject.

And don’t forget, that quality means many different things, but customers are interested in functionality.


Craft Conf Workshop - Gojko Adzic

The day started with a mistake I’ve made. I didn’t check my mailbox accurately and missed the info that workshops aren’t held at the conference venue. I knew that there were some email but I thought it’s redundant and everything is on the homepage. It wasn’t. After all, I managed to track it down and get to the Prezi office in time when the workshop was held.

The workshop was about  How to Make Big Impact with Software Products and Projects by Gojko Adzic. We had to form group which was very nice because most people didn’t know each other. We had to come up with an imaginary milestone plan for some kind of a software. It was interesting that the seven groups came up with quite different ideas and every group was able to defend his own viewpoint. One group defended the idea that they didn’t want to touch the legacy code of the system, other team came up with the idea to rewrite the legacy part. The conclusion was, that no ranking can be defined, it’s nearly impossible to judge, which will be the best solution. It was also extremely difficult to work with people who I didn’t know and not necessarily agree with them, but we have to came up with a solution in five minutes.

In other tasks we had to make mindmaps and implementation plans and after each task the presenter held a presentation about the conclusions of our results. Some takeaways:
  • Make a victory condition for user stories, which is different than DoD which is a technical thing. Victory is, when the story really works in the practice as it was expected.
  • A user story should be about changing a behaviour not creating one. In most cases the operation, which is described by the story, is already doable but maybe not enough effective.
  • Raise the level of discussion. Challenge stories, they’re not given by god. In fact, users aren’t designers, they can’t design a software. Never rely blindly on their claims.
  • Never say No to stakeholders just Now or Not Now.
  • A story can be sliced in many different ways, for example by a group of users.
  • Quality means many different things. It’s hard to come up with some success criteria but in most cases more aspects have to be investigated. If a high-quality code doesn’t fulfill the users’ functional requirements it’s still valueless.
  • Reserve a learning budget. Implementing an easier variant of the functionality may give useful feedback about the correctness of the idea. Implementing doesn’t necessarily means writing code. An automatic behaviour can be mimicked by hand for some users (for example sending ‘automatic’ notifications).
  • A Maslow pyramid can be defined for software, where the lowest level is the fact, that the software actually builds and runs. Next level up is to be performant and secure, then to be usable, then to be useful and the top is to be successful.

So, the message was basically injecting the lean process into the Scrum/Agile process which I very much like. I don’t think if all companies can apply this, especially the ones which still have some waterfall-ish way of thinking but it’s definitely a good direction for startup-like companies.

The presenter had another talk on the conference with somewhat similar content which can be seen here.

It was nice to form groups and the workshop itself was great. On further days of the conference I met some former team-mates and had some discussion with them. It was also interesting to see Prezi office basement and their magic words (boarding, prezilians, HP). We had a great dinner in Apacuka. After the workshop I had a glass of wine in Aquarium and one more near Epam office, then I went to one of the meetups but let it be the subject of another post.