Developing Good Software is Damn Hard

Posted by Filip Ekberg on 29 Jan 2014

Since I first set my foot in the "Software Architecture" class back at the technical institute it feels like I've taken things for granted. Over the years I have seen myself as a pretty good software engineer, a programmer with many hats be it developing in C#, Java, Python, PHP, Objective-C, and I’ve tackled lots of different problems. It just hit me though developing good software is damn hard.

I've been working for a bunch of different companies now and been on lots of different projects all teaching me different things along the way. It wasn't until recently though when I got onto a project where everything was, sort of, by the book. As I mentioned, I've seen myself as a senior developer for a long time now and in many projects where I've been that has been the case. Starting on this project though has in a way opened my eyes again and I see that I still have so much to learn.

I don't say this as a bad thing, not having things to learn is one of the many reasons I've changed companies over the years as I like to be challenged. When I attended the "Software Architecture" class and the teacher talked about decoupled solutions and all that, I just thought it all sounded so very trivial, I wonder though, did I ever really write by the book code? "By the book" is an expression used a lot, even outside software development and it has sort of a negative ring to it. There's so many things that will not work by the book, so how about just focusing on the things that are possible to do by the book? I mean consider working on a really time intensive project, you won't have the time to do all the things you would in a multi-million dollar project, right? As long as the customer understands that - everything will be fine. Let's not get side-tracked on this, the customer rarely understands the implications of not doing it "by the book" and in the end, it's the customer that's going to be hurt from that.

When I use the phrase "by the book", I'm referring to the way that the software is designed and how it's evolving and not growing (too much) out of the bounds of what "by the book" is. In my case "by the book" isn't a negative term to use, at least not in this case. I can't and won't go into detail about what the project is, but it was well underway when I started working on it and I thought to myself that this would be yet another hard project and even harder domain to understand - oh boy was I wrong. The domain was very straight forward and the code was, well let me put it in simple terms, "by the book". Sure there are things that could be better, things that had to be hurried up to get finished in a certain amount of time. However, the quality of the code was impressive for something that had been developed on for at least 10-12 months.

Imagine the feeling, when you first fetch the code from the source control that the team works in, you compile it on your machine and starts browsing around. You notice that everything follows the same pattern, the project leads tells you to take a look at a certain piece of the software and uses terms from the business to describe something in the domain that you are about to work on. Suddenly you get this feeling that "damn I have no idea where to start", but as a senior developer you quickly ask ReSharper to find all the files that could have something to do with the buzz-words that the lead just used. In front of you is now a bunch of files that looks to be exactly what the lead was talking about. Opening these files directly gives you an insight into the business and the domain, it's like seeing a jumping unicorn on a rainbow - the structure is just so beautiful.

Well structured code will talk to you, without having someone explaining every single line of code for you. It will tell you a story about what the business has asked for and by just reading the code you can start talking to the customer about their domain - this is well structured code.

When I first fetch all the code from the source control I like to run all the tests, to see that everything is working - maybe even adding some tests of my own to understand the domain even better. None of the objects have default, empty constructors though, so how do I create them? How do I know what parameters to pass? Well in my world, all objects that exist in memory are valid objects without any errors. I notice another pattern when looking over the tests, all the tests ask for something through builders, these builders know how to setup valid objects that I can use in my tests. All of a sudden I am on my way to playing around with valid objects, writing tests and getting a so much better understanding of the domain.

I start to get a bit afraid after running all the tests and playing around with the code. What about the database? Did anything I just performed affect any of the data in the database? Not in this world. In my world everything is decoupled and I don't have to worry about the underlying data structure. Not even when testing actions from my controllers that I know for a fact modifies the data in the database. I notice that the actions raise events that someone else is listening to, this means that when I test my solution I can just ignore these events and be on my merry way. It hits me, it's so extremely rare to work with code that is so well structured and so well designed. I need to value this time, learn as much as I can so the next time I am asked to be a part of the design team of a new software I can amaze someone.

I just turned 27, today actually and I have been coding longer than I haven't. It's pretty amazing waking up and knowing that you will learn something new and that software development is so extremely fun, educating and yeah, damn hard.

I thought about naming this article "The beauty of a decoupled solutions", but the message didn't really seem to go through that well with that title.

Follow @fekberg