#designhell

I thought for my first post I would pick a topic that is both dear to me and causes me to go crazy with anger.

In the community of Software Development there are three main types of practitioners the programmer, the developer and the software engineer. What is the difference between all these people you may say? Well the answer to that question polarizes our community.

I like a number of people identify as a software engineer but why do I? What is software engineering and how am I different to the other practitioners? Well I would argue firstly that I’m really not, you should never judge people on their title. A lot of worst practitioners I’ve ever meet or worked with claimed to be expert software engineers but really they were just title chasers.

So lets knock that off the top first, software engineers are not in anyway better programmers than anyone else. A lot of very vocal software engineers will claim this and it’s normally the first sign that they really aren’t. Software engineering isn’t about being better than anyone; in fact I would say it’s the opposite almost. There is no all mighty hierarchy of software development that places software engineers at the feet of Zeus.

You also don’t need to have a degree in software engineering to claim the all mighty title of software engineer. Some of the greatest software engineer’s I have meet have a degree in economics and some of the worst a PHD in software engineering. Degrees will only give you what you choose to take from them; don’t judge someone based on their formal education. It’s often a poor metric.

That leads us into my favorite pet hate, software metrics. Yes these too have nothing to do with software engineering. Please never ask me in a sprint planning meeting the cyclomatic complexity of a method I wrote, I won’t know it and I’ll throw my craziest look at you. While these metrics can be helpful to refine the performance of programs after they have been written doing this in the planning/design stages of development leads to what I like to call “Over Design Hell”.

Over Design Hell is a huge topic that I’ll cover in another post but lets touch on it here. Design is important but it’s also something that you really can’t nail down at the start of a project. It takes time, it takes a deep understanding of the problem at hand and it requires very well developed requirements. Design evolves and good software engineers understand this. If you try to spend weeks designing your software at the start of your project you will most likely throw out 90% of it or have a product that isn’t fit for purpose.