My 5 Laws of Software Engineering
So now that I have recovered from the attacks of the last post. Now let me present you with my 5 Laws of Software Engineering.
Software Engineering is about applying solid engineering principles to software development. No I'm not talking about calculating the thrust to weight ratio of a rocket. I'm talking about understanding how to structure software in a way that it's both fit for purpose and easy to maintain. This is a key part of software engineering, structure. Programmers tend to care less about this, which is fine computers don't care how neat your classpaths are but humans do. If you structure your software well things like testing and maintenance become a non-issue. Software should be easy to work with, clear and clean.
2. Clean Code Is Sexy Code
How do we make software clear and clean? Well we document it but maybe not the way you think. Yes Java Doc is awesome but you know what's even more awesome? Clearly naming your variables and methods. I can hear the cry of "But everyone should know what i or e is" now but I can tell you right now at 4am when I'm trying to debug your code I don't. Never take the chance that the person after you is a mind reader or thinks like you. Use real descriptive words that have meaning in the context of the code. This is a core concept in making code structurally sound.
3. Be Kind, Document And Uphold Your Contracts
Java Doc and other types of software documentation are designed for API documentation. This doesn't mean we can't use them for method documentation but you should still treat it like API documentation. It should be a contract with the consumer of your method, which you should uphold and you should design for reusability as your method evolves. We should understand this as software engineers and use documentation to our advantage, "there is always time for doco" is our mantra. There is also no point in spending a month writing an extremely complex word document that explains every single aspect of your program to a technically ordinance. The first thing I do when I get handed a piece of software to work with is read the code not a word document. Code should be self-describing, easy to understand and follow the standards of your work place. Doing stuff differently is fun sometimes but it makes other peoples lives harder if you don't do this the right way.
4. New Tech Is Cool But Only If Done Right
Every developer is guilty of trying to introduce new tech into a project at one point or another. This is a great thing, we should all hold onto this spark that makes us try new things. However as software engineers we need to understand when it's appropriate to introduce a new component to our tech stack. For example if you're writing a new REST web service that just does CRUD operations, then you most likely don't need a giant application server running JEE latest just use plain Java or Perl. However if you have data store that is spread across a number of data centres then you may see benefits from trying Apache Cassandra. If you introduce new tech when it's needed with the right training and with the right attitude then it will be a hit. Coming off this never hide your cool new project from your fellow software engineers, always share and listen to their advice.
5. Pick Your Battles, CPUs Are Cheap You Are Not
Software engineers, well all the good ones I've meet understand where their time is best spent on a project. For example you have a complex algorithm that’s working but could be better and a database query that isn't returning the data you want causing rework. The software engineers would tend towards fixing the easy problem first that is likely causing the most harm. They understand that premature optimization is the devil and spend their time instead making the software better. I personally have the goal to always leave a project in a better state than I found it. That may mean that I write some documentation or I write some more tests to test the problem I'm fixing. It normally never means I rewrite code or fix someone’s algorithm; the gains on adventures like these are normally only personal. CPUs and memory is cheap these days, while we shouldn't use that as an excuse to be lazy. We should remember it and make a judgement call based how valuable our time is.
I've always personally felt that software engineering is a mindset and attitude more than a field of engineering. It's about understanding how software and humans meet to achieve a desired goal. These laws come from the people that taught me and helped me grow as an engineer. I don't try to pretend that they encompass everything that is software engineering but I feel that they capture the essence of it.
