Buzz Words

Can I bend your ear for a few minutes? If you‘ve never written software, this post may not be all that interesting. Then again, it might!

First, I thought I’d give a few definitions of my own to some of the common “terms” that are used in software development. Buzz words by any other name.

Technical Debt: The “best of breed” 5 years ago.
Best of Breed: The latest “new idea” the software vendor is trying to sell you.
Waterfall: The old way of developing software.
Agile: The new(er) way of developing software.
Waterfall: The new way of developing software in 5 years, using a new name.
The Cloud: Your servers are under someone else’s control and they are thrown in with a whole lot of other folk’s servers. All you data is only available over the Internet.
SaaS (Software As A Service): How many times can we charge you for the same thing you used to be able to buy once?
Spaghetti Code: Anything developed for the web.
Eat Our Own Dog Food: Exactly.
Unit Test: How to double the time it takes to write code just to run meaningless (most of the time) tests.
Bleeding Edge: Technical debt.
Old School: Writing code that isn’t bleeding edge and doesn’t become technical debt. It is just not the new way of doing things (see best of breed).
Any New Catch Phrase: A retread of an old catch phrase.
MVC, MVVM, etc.: How many ways can we split up 50 lines of code?
Write Once, Run Anywhere: Bold faced lie – mostly.
GUI: Why drag and drop controls graphically (old school) when you can write code for all your controls (new school).

I guess my point is, don’t follow the latest and greatest. Let it gel a bit and then use it only if it solves a problem that can’t be solved with the current way of doing things. Having said that, always be mindful of where your tools vendor is headed. Sometimes we are forced into changes that aren’t needed but are required by the tools vendor. Apple comes to mind here…

For me, the number one goal of any software development, in no particular order, are maintainability, minimalism, speed and reliability (MMSR). These can apply to both the process and the code however I’m talking about code in this case. Let’s take a quick look at each one as they are all equally important.

Maintainability: Write code that is easy to understand, easy to follow and well documented. Don’t add complexity due to some new technology and also don’t add it because you think a section of code may be reused. Most code will never be reused.

If the code is something along the lines of database interaction, for example, develop a simple, extendable framework that can be easily added or copied to another project. Always write code with the thought that you will be looking at it again 10 years down the road and adding new functionality to it.

Minimalism: Write the least amount of code possible and do it on the simplest architecture possible. Can it be done in a function vs. a class meaning is there any logical reason it needs to be instantiated? If not, make it a function. Can it be in a native app vs. the web? Do it. Etc.

There are many ways to deliver apps these days including easy delivery of native apps. Native apps tend to be much less complex than a web app, for the same functionality. Unless there is a huge business reason for a web app, lean towards a native app.

Speed: In general, the simpler the code is, the faster it is. The fewer layers it has, the faster it is. When code is located where it is most optimized, the faster it is. Speed is also not just in the code, it is the interface. Design an interface that speeds up the user, fewer clicks, apparent functionality, data presented in as few screens as possible and so on.

Reliability: If you do everything outlined above, you’ve achieved reliability! For example, if an app runs on ten servers scattered over the world or runs locally on the users computer, which is most likely more reliable?

That’s my (high level) two cents on software development. It is probably not a very popular view these days but there it is.

Thanks for listening…