Posts

This post appeared first on factor10.com. It just doesn’t make any sense! Your software team has been getting slower and slower up to a point where every new feature is painfully forced through the system, wrecking everything it touches, leaving everyone afraid to make any changes in the first place and adding more and more defensive processes that slow the system down additionally.

In the blogpost about structural idealization I explained how structural engineers model reality to answer the question whether their designed structure can withstand the forces applied to it. But how does an engineer know which forces will be applied to their structure? The weight of the structure can be approximated at best, and natural occurrences like wind or snow or a car crashing into the building are much harder to anticipate and quantify. And how does an engineer consider a car crashing into the structure while still building reasonably economical?

I sometimes joke that I have gone full-circle: from Structural Engineer to Software Architect. Structural Engineering and Architecture are of course not at all the same thing (like you can never suggest that to either Structural Engineers or Architects!), but people tend to mix those two up. I in fact think it should be called ‘Software Structural Engineer’ instead of Software Architect. That would be more correct and would make my joke funnier. Let me explain…

I started my software development career as a structural engineer who programmed, developing analytical applications for other engineers. When I moved to a traditional software company, I went from one extreme to another, from having all the roles of a software development team at once to becoming a “code monkey” with no context about what I was building and why. In search of a middle ground I came across Domain-Driven Design (DDD), which in its essence is about getting to know the Domain you are developing software for. But without being a Domain expert yourself.

About a year ago I attended a workshop held by Dan Bergh Johnsson and Daniel Deogun, authors of the book Secure By Design. They presented the topics of their book and on three additional occasions we met in smaller groups and had guided discussions on the topics. I like the mix of Domain Driven Design and cybersecurity a lot, it gave me a whole new perspective (and justification!) on why to apply Domain Driven Design. One concept I have been using extensively since I read the book is Domain Primitives and I want to share how I utilize it.

I published SwatchIt, a native Android app I have been working on, to the F-Droid Android Store 🎉. Now you can get it on F-Droid. All apps published through F-Droid are free and open source software (FOSS) and F-Droid itself is free and open source as well. If you don’t already have F-Droid installed, you should go ahead and install it, it is not as complicated as it looks even on certified Android devices (for now.. but that is a topic for another post). Publishing to F-Droid comes with some efforts, mainly since every app that you download through F-Droid must be built by F-Droid as well, so it is not enough to upload an APK.

I started writing a native Android application with Jetpack Compose at the beginning of this year. I have been working on it in my free time and it solves a problem I have been having since I started knitting: Swatch Management.