Developing Good Software is Damn Hard

Posted by Filip Ekberg on January 29 2014 9 Comments

architectSince 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.

Vote on HN

9 Responses to Developing Good Software is Damn Hard

  1. Jon LimjapNo Gravatar says:

    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.

    Darn, that makes me feel jealous!

  2. wtkNo Gravatar says:

    I’m sure you’re coding skills are god awful. There’s always unearthed bugs in complex systems. If you see unicorns in an existing code base, then you don’t truly understand the code.

  3. Terry A. DavisNo Gravatar says:

    When I first write code, it might be 1,000 lines. Then, I make it better and it is 500. When you write code it is 1,000, then you make it 2,000.

  4. JessNo Gravatar says:

    @wtk When you’re telling someone they are “god awful” at something you might want to make sure you do it with perfect grammar. Otherwise you run the risk of looking like an idiot.

  5. dagarfolNo Gravatar says:

    What a horde of envious people! This guy says he has found a place where people take serious consideration in keeping the code clean, decoupled and well designed, and all you have to say is “you have not understood the code”, “your skills are awful” and “I can do it better than you”
    First, less lines of code doesn’t mean “better”, especially when talking about readability, maintainability and extensibility of the code. So stop that bullshit and start being a bit more humble.
    Second, about the unicorns, I am sure there are complex parts of the code to discover for the author, but if I found myself looking at a code base where everything is tested, using builders for the objects in the tests, with decoupled classes and components, I would also feel like that. And given your comment, Terry, I am sure *you* would also feel like that. So again, if you don’t have anything positive to say, you’d better keep your envy to yourself.

    BTW, I am also envious and jealous

  6. Pingback: Weekly Digest for Developers: Jan 26 – Feb 2, 2014 - Super Dev Resources

  7. MichałNo Gravatar says:

    Envious and jealous!

    That’s the environment and project every developer would like to work, I guess. :) And I think achieving such ‘clean’ project is the hardest part in our day-to-day work.

    BTW. About the title – if the software development was simple, would it be still so exciting as it is now? ;)

  8. Filip EkbergNo Gravatar says:

    Excellent point Michał! I think we would not be as exciting if it was in fact too easy! Do you think so?

  9. MichałNo Gravatar says:

    Exactly!

    I can hardly imagine something more frustrating than looking for a bug in the same code for thousandth time or having no idea how to add some brand new feature to existing functionality in the late afternoon. And there is nothing more rewarding than coding the next day morning those easy (and so obvious! ;) ) solutions to the issues from yesterday :)

    The satisfaction from solving problems (the big and smaller ones), implementing some nice feature or just simply giving customer the thing what was requested (and seeing her/his happiness of using it) is something that gives me the power to do more stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>