Software developers can make everything

March 28th, 2019 Software Engineer 'old hand tool collection' by Hunter Haley on Unsplash

Software development is a very creative profession. After gaining a few years of experience you will have a tool belt to create about anything people ask you. Where classical engineering leaves less room for creativity, because of rules on material properties and gravity, software engineering has endless ways to achieve a solution. For a large part that's why I love development work.

Can we really make anything?

I think we can. Of course there are things I can't make yet. This is about not being trained on the particular subject. Even for some of these subjects, I might not even be able to get trained because my head can't grasp the complexity in it. But that would be things like: Building software for a nuclear powerplant or quantum computing. For everyone those limits are different.

My point though, there's really a lot of things we can make as a developer. Sometimes we need to train ourselves to understand new technology, but having some basic experience makes any learning new language or library just a matter of time till until you will grasp it.

Very recently I bought a Fitbit Ionic, a smartwatch which allowed me to create my own watch face and apps. At Fitbit they created a nice developer experience with a combination of JavaScript or Typescript with a subset of SVG. After starting with some hello world examples, I was able to create the below watch face in a roughly 4 hours. On the other hand I'm working with Vue.js at my current customer, something I didn't have any knowledge of. But with the help of a bit self study I now can build a working Vue.js application. We all must admit that being able to create a watch face with a roughly 4 hours of work doesn't necessarily make you a Fitbit Dev legend. But building the watch face really was a lot of fun. And that's one of the reasons developers quite often choose to build something ourselves and if possible we use the newest set of technologies. If our hobby is about developing software this is actually a good thing to do this while practicing our hobby. It will build on the 10.000 hours of practice to achieve mastery.

And if you want to exercise to build creativity in solving problems, you can try to do some kata's. If you're good in building programs in C#, but your TypeScript isn't fluent yet, do a couple of kata's in TypeScript to improve your skills.

Should we really make everything ourselves?

I still recall, the ages where we did .NET Framework 1.1, no I'm not talking about .NET Core, I'm really talking about 1.1. It must have been in 2007. I was assigned a project at an insurance company, we were going to build a insurance policy administration system. The project, being of the waterfall-type, actually got cancelled after about a year. But during the initial phase of the project we were looking for solutions for some technical challenges. One of them actually was logging.

How do you do logging today? You either choose the build-in logging framework in .NET Core, or use the build-in abstractions together with a well known framework, like serilog or NLog or even use the cloud with products like Azure Monitor or Stackify Retrace. During the before mentioned project however, there wasn't that much choice, there was log4net as a port of log4j and there was the Microsoft Enterprise Library which contained Logging and Instrumentation. When talking to the IT-architect, actually he wasn't much of a software architect at that time, but had more knowledge on infrastructure, he didn't like the Enterprise library because it was too slow (it actually was slow). The option to go with Open Source, log4net wasn't an option either. Wow, I was quite disappointed, the option we had to go for, was build-it-yourself. And even though it seems like the requirements to log towards both flat file and the EventLog sounds like an easy task. Wait for the incoming requirements where you'll have to add things like rolling log files, support for logging from multiple threads, and more. Actually at that moment I already told the architect we shouldn't do this ourselves, because it would be both hard and not our specialization. So we ended up creating a faulty log framework which luckily never ended up in production because the project got cancelled. Even though Open Source might not always be allowed as a choice, building it ourselves was a very bad choice. Don't build your own logging framework!

Some companies, like to hide every framework behind an abstraction of their own. I've seen a company write an abstraction in front of the Dynamics CRM Web Services, which leaned heavily on reflection, it prevented the need to generate a Web Service stub. End result? A mall-functioning abstraction which was overly slow and lost Integrated Security. I have also worked with remote team who abstracted everything, from logging to database persistence. I agree that there is some value in hiding the database access behind a properly implemented Repository and UnitOfWork pattern, however this was not the case. The team also wanted to do CQS but ended up with Commands returning query results. After lot's of talking we ended up removing those patterns and went with Entity Framework without further abstractions. This team, was not competent enough yet to add value with the before mentioned design patterns. Of course it's not always the case that abstractions are mall-functioning, but it still happens quite often that features are hidden which are actually very useful. Be always careful with abstractions. Ask yourself: Do they add value? Sometimes the insights about too much abstraction comes really late. I'm not sure if removing the too much from abstractions will be a wise business decision.

One of the other things I see every now and then, "We created a CMS ourselves, the options out there don't have the features we want.". I know some of the CMS solutions like Sitecore are quite expensive, but don't compare this with a scrum team of 5 which are building an inferior CMS solution for half a year: roughly € 50k each month, makes € 300k. How expensive was Sitecore again? If you actually purchased some parts of the software your time to market would be much faster. Make sure the teams are actually adding value to your processes within your company. Unless you're actually a supplier of software that is going to sell the CMS, don't build one yourself. Choose a solution and customize it instead.

Side note: This site is actually running on a custom build CMS. It's inferior to every existing free and paid alternative. Why do I build a CMS? I need a playground which I can use to gain experience and knowledge around certain architectural and design patterns, frameworks and tools. Besides that, I think it's fun to build it. However it's not a wise business decision when not counting the gained experience and knowledge which helps me sell myself to my customers.