What’s your favorite part of software development, and why?


I love solving problems and making the lives and/or jobs of others easier. I have a natural fascination with puzzles, electronics and tools combined with a deep seeded need to create and combine things in different ways. This is part of what makes me loving software development. I get to combine many of the different things that I love, throw it all together and (hopefully) provide something of value to someone – even if it’s just me.

Ultimately, I want To Deliver Value

There are many different aspects of software development that I really get into. At a high level, I love the process of understanding, defining, building and delivering software. And I get the most joy out of my creations when I have evidence to say that the end users find it easy to use and that it does not get in their way. There’s a sense of pride and accomplishment in delivering small, working bits of a system and getting good feedback so that I can improve the system during the next release.

My Favorite Thing To Do Is Modeling

One of my favorite parts of software development is modeling the concepts that I’m building and codifying that model with code. I thoroughly enjoy the challenge of translating some knowledge that I have – whether I’m the expert or I am gaining the knowledge through discussion with an expert – into a functioning piece of software.

When it comes down to the real nuts and bolts of putting together an elegant solution in software, I tend to see the modeling process as the central and critical piece. Modeling is to me, what a cornerstone is to a builder of a cathedral. If you don’t get the cornerstone set correctly, you can jeopardize the entire project through 2nd order, 3rd order, and more, effects and problems. If you get it right, though, the rest of the project can line up and flow like clockwork. Every individual stone that is cut and laid, lined up according to the cornerstone, adds to the momentum of the project and the overall aesthetics.

Within a software project, these aesthetics are the API that you are building and using to create the final product – the working software system that solves a given problem or set of problems. If you get the model right, and the API you build around that model is lined up with your system’s actual needs, then the rest of the system can flow smoothly. Your data access will make more sense. Your UI will lay out easier. Your user experience design will make sense to the end users.

For me, the pride and sense of accomplishment that I get when my models get out of my way and let me build the solutions my customers need, is why I find modeling so intriguing and exciting. When I spend days or weeks refining models and designs, getting feedback and continuing the push the design, all that hard work is a build up to the accomplishment of orchestrating it all into a system that the user needs and wants to use.

Modeling Is More Than Just The Domain

Yes, I’m a fan of the big blue book and I have taken a significant amount of influence and direction from it over the years. But when I say modeling, I mean much more than just the domain. There are models all throughout your system that need to be accounted for and modeled correctly and there are different architectures and patterns that will create more or fewer modeling layers for you to work with.

Look at the MV* architectures, for example: model view controller, model view presenter, model view view-model, etc. There are several components within each of these variations that each need to be modeled correctly. Each of them has some sort of model to represent and work with the view, and it’s very easy to extend all of them to say that you should have a separate domain model that runs things behind the scenes.

Context, Context, Context

There are still more opportunities for modeling in your software and domain driven design and MV* architectures are not the only way to build systems. I tend to gravitate toward these solutions because the software systems that I build tend to benefit from them. I know that there are languages and systems out there that would not benefit from the approaches that I take with modeling, though.

What About You?

I also know that not everyone considers modeling enjoyable or critical. I’d love to hear about your favorite part(s) of software development. What do you enjoy the most, and why? In what challenges and conquests do you find the most enjoyment and satisfying results? Drop a comment here or post your thoughts on your own blog and link back to this one.

Keep Your Demo Data Separate From Your Seed Data