During the last months I had multiple discussions with management about the right workload for software developers. Of course it looks like having a load of 100% is optimal, and for most professions it is. In software development however this is not the best you can do:
- Anything software related is very shortlived. What you’ve learned 2 years ago can be considered a bad practice or dead technology today. It’s one of the main treats of this profession: You’re always learning new things. But you need time to do this.
- Software Development is a very creative process. It’s highly complicated, even for smaller projects there are thousands of possible solutions. You will not find a good solution if you do not have time to think about alternatives. You will also lose your creativity when always working within the same rails.
Henrik Kniberg talks about pauses between Scrum Sprints in his book “Scrum and XP from the Trenches“:
In real life, you can’t always sprint. You need to rest between sprints. If you always sprint, you are in effect just jogging
The concept is quite clear, but I still had a hard time getting this appreciated by management. I recently read a story by Stephen Covey that probably would’ve helped a lot. It was about a man in the woods, working feverishly to saw down a tree:
“What are you doing?”
“Can’t you see? I’m sawing down this tree.”
“You look exhausted, how long have you been at it?”
“Over 5 hours, and I’m beat! This is hard work.”
“Well, why don’t you take a break and sharpen that saw? I’m sure it will go a lot faster.”
“I don’t have time to sharpen the saw. I’m too busy sawing!”
For my new job at Ubimax I need to improve my Java knowledge. I was tinkering around for the last weeks and got to know the language itself, the class library and some technologies like Spring. I also tried different tools, so far I really like IntelliJ and I’m impressed with the amount of tools to improve code quality like Findbugs or Checkstyle.
Playing around just goes that far and soon I needed a project where I could apply what I’ve learned. Luckily I was in need for a very specific usecase: During the last months I accumulated a lot of overhours and Rheinmetall wants me to use them all till my last day. I first calculated manually how many hours I needed to work each day to reach 0 overhours on the last day, but why do this if there’s an app for that?
I created a small and simple Android app called “AppBummler”, based on a German word that describes spending overhours and working less. Just for the sake of it I put it into the Play Store. Feel free to test it out, but it’ll probably not be of any use for a lot of people.
While clearing up my office book shelf I stumbled upon a book I got during my ISAQB training. It’s written in German and called “Vorgehensmuster für Software Architektur” which translates to something like “Software Architecture Patterns”. It’s written by Stefan Toth, a well known software architect and consultant here in Germany.
After getting the book some years ago I read it and found it very useful. Somehow it landed on the book stack, being forgotten about until recently. After rediscovering it I took some time to read it again. I was surprised on how many ideas it planted into my daily worklife and how much of its patterns I actually used during the last years in my job as a software developer and architect.
I’ve read a lot of books, but I wanted to point out this book in particular. Here are some of the patterns I found most useful. They are all described in detail in the book, so go get it if possible for you:
- Keep quality factors in mind: Software is always a trade-off between software qualities. Qualities like security and usability contradict each other, so you have to factor them in right from the beginning. Toth is taking this into account during every phase of the project, beginning with requirements analysis.
- Keep everyone involved: Context is King, a developer that does not know in which project context he’s working will probably not create what he should. Everyone knows the picture with the swing on the tree project. Toth describes how all project members should be involved during the project. He shows a lot of methods like project and architecture reviews that help building up knowledge about the context.
- Last Responsible Moment: The concept of LRM and how to handle it is one of the key concepts in project management. After a bit of practice it comes naturally, and a good architect knows how to handle it. That’s not to say that a good in-depth analysis of this concept and how to tackle it does not help.
- Active Risk Management: Along with LRM comes risk management. What are the different types of risks and how to minimize them? The book categorizes risks and shows a handful of concepts about what can be done for each category.
- Architecture Reviews: There’s nothing better than to crowd-solve a problem. It’s extremely rewarding to finding the best solution together. Even better, you get a lot of knowhow-transfer and free training on top of it. This is especially true for architecture – in the past I found that basic architecture and software design are among the most critical parts of a project. If you have the possibility to get everyone on board during this part of the project you will probably not have to deal with miscommunication and out-of-context development later on.
- Use feedback and retrospectives: A good software development process consists of as much feedback opportunities as possible. You should always reflect on your past decisions and ideas, often you find better ideas that are still possible to be implemented. This goes for architecture, but also for process and the whole social stuff.
- Show your progress early: This is also related to the whole feedback topic – Show what you got and see what the customer and other stakeholders think about it. Be as transparent as possible in your development process, you’ll get feedback that otherwise would never reach you and cost you a lot of trouble later on.
- Root Cause Analysis: I see this way too often – A problem occurs and a developer fixes it right away, not thinking about the real root cause of the problem. Oftentimes only the currently visible symptom gets fixed, but the real reason for trouble stays in the system. With proper methods like the 5 Whys it is possible to get to the real issue and fix it once and for all.
I also found a few things that I always wanted to do, but never had the opportunity. The biggest of them are Architecture Katas. I think Katas can improve architectural thinking and collaboration in the dev team a lot. The book names the coding dojo of the clean code school. A short google also turned up this English site.
Back in October I got the chance to write a guest blog post over at the Conan-Blog about how we’re using Conan at work.
Hopefully someone finds use in it. Conan really helped us pushing our C++ dev environment onto a new level.
I assume that I’m the first Rheinmetall employee who wrote a public blog post about how stuff is handled internally. #neuland 😀
Recently a lot is going on in my life. Two things stand out:
My son is born!
Finally on Dec 2nd 2016 my son Mattis was born. The last weeks were tiring, but it’s totally worth it! I’m so looking forward to all the things I’ll be doing with him. He’s currently in a phase where he’s sleeping in a baby carrier every evening, so it’s perfect for me to carry him around and do all the things with him.
Writing a blog post while carrying your son? – Check!
I’m changing jobs!
After 10 years working for Rheinmetall I felt that a change was more than overdue. In the last 2 years I got the chance to lead a very talented team of junior and senior developers – which was great. The only problem was that as soon as we wanted to do something outside of our small team we were restricted by all the downsides that come with large, unflexible companies: Legacy code, complex processes, office politics and more. It was very frustrating to have such a great progress and collaboration, just to get stopped every time by outside factors.
Timing’s everything, and somehow a small company from Bremen got it all right. After another very frustrating day in the office I got contacted by the CEO of Ubimax and from the first moment on it sounded very interesting. The technical side is very interesting and the working environment sounds awesome.
I’ll start by April, but I’m already working on learning everything I can. They’re mostly working on a Java-based technology stack – A thing I do not have a lot of experience with. So far it’s great, it’s much easier to write good quality code with an interpreted language.
I’m planning on being more active in the blog, hope this time it works out. I think that plotting down the things I’m learning is a good read for every reader, but also a good reminder for myself. I also hope that ta Ubimax I can be a bit more open with what I’m doing – in the defence sector everything is regulated and I had to be very careful on what information I share. We’ll see how this works out.
Quote of the day:
C++ is a very good language for writing efficient software, but not for writing software efficiently. – Jendrik Kretschmann (though I do not know where he picked it up)
I tried something new this weekend and created a Unity integration with my C2 ergometer. I was following the approach that I wrote about a few months ago:
For my test-integration I used this script to generate some Bots and (a simulated) player. I then learned the basics of Unity to connect some sort of generic 3D application to show what the boats are doing.
I uploaded the Unity project to Github too, it has some nice features integrated and I’m planning on extending it in the future.
I called the communication layer Fitznet – there’s Fitness and Network in there I guess. The protocol is based on Google Protobuf, I also created a small ZMQ Forwarder to keep the set up easy. Currently the whole thing is in an early development phase and I’m not sure if it will ever leave this state. But there’s some potential in there I think, perhaps if the right people are working on it…
Here’s a video of the current progress:
Our washing machine is located in the back of the house. This is sometimes a problem when we forget that we turned it on. Unfortunately it’s not one of those models that beep loudly when finished, it just stays there and let’s the wet clothes get stinky.
Thanks to OpenHAB I’m now able to get notified onto my Android phone whenever the washer is finished washing. I previously set up the OpenHAB remote service available via my.openhab.com. You need to install their addon, create an account and fill in the secret key of your OpenHAB installation. After that you can connect the official Android App with that service and access your OpenHAB on the go.
I also had to set up a Persistence config that stores the values of my items. I used the mysql addon with a local mysql-db. I used this tutorial to get it up and running.
I used a Fibaro wall plug to check the energy consumption of the washer. Find the configs on Pastebin:
Whenever the energy consumption goes up, the rule switches into the “Washer is active” state. If then the washer uses no energy for about 2 minutes, it goes into the “Washer is finished” state. Thanks to the Android App I’m getting notified whenever the state changes.