Friday, November 15, 2013

Software Engineering Basics

Note: The target readers of this post are people who are first heading into the software industry. I wrote it because these are what I did not know when I entered my first job.

I have worked at Orion Health for just shy of two years, and here are a list of things that I find to be useful knowledge. Some of these concepts are trivial and are understood in minutes, but I hadn't heard of them in university so I'm noting them down here.

Code Reviews

Unlike university, at work, after you write code and want to check it in, you should get it reviewed (where I work this is a must). This is where someone else looks over the code you have changed, decides whether or not it is alright, and then allows or denies you the commit. This lets you have a second pair of eyes look over your code to check if what you have done is:
  • well designed/written (clean code is really valuable)
  • correct (you should have tests, but you may also have missed certain cases)
  • does not contain anything malicious

Build Server

When working on a project, source artifacts have to be transformed into their built artifacts before they are used. Your source artifacts may be code, rich graphic formats, and so on. The built artifacts may be jars, static/shared libraries, executables, rendered graphics. A build server is a server dedicated to run builds.

A build is an automated process that is configured to retrieve the source artifacts (typically from a repository), run commands to build the relevant artifacts, and potentially run tests against them. Larger builds may deploy the built artifacts into a deployment environment. Builds can be scheduled to run periodically, whenever there is a change in the source artifacts (perhaps through repository polling), or manually.

Deployment Environment

A deployment environment is somewhere you put the output artifacts as they would be in the real world. This is just a computer that is set up as you would expect it to be on anyone's computer when they are using the software. For application developers, you may have multiple computers set up - each with a different version of an operating system (windows xp, vista, 7, 8; mac os; ubuntu), and you would try out your application to see if it works on each environment. For web developers, you may use multiple browsers of different versions to see if things look and behave correctly.


Tests are extremely useful. In university it seems pointless writing the expected output of your code given some input, but at that level, things are much easier than at work.

The faster a test can run, the quicker you get feedback, and fast feedback is highly valued. Tests may be unit tests which run against small sections of code, integration tests which test the interaction between modules, or system integration tests, which test the functionality of a fully deployed system.

Dependency Management

Software has versions. That's why there are software updates. If you are an application developer, you may be writing version A of your application, and you may be depending on version X of a library. After you release version A of your application, you start working on version B, C, D and so on.

One day someone discovers that there is a bug in library version X. Suppose in application version C you start depending on version Y of the library. This means that anyone with version A or B of your application must update to at least version C in order to have the bugfix.

This of course gets complicated when your software is made up of 10 layers of libraries depending on other libraries.


Support is the part of work where you help someone turn on their computer. This role may also include:

  • helping someone configure the software correctly
  • figure out why the software isn't working
  • telling someone your software doesn't do what they want

Typically this is the part of work that lets you experience how the users of your software are actually using it.

Issue Tracking

Issue tracking is a system which lets you track work. This may track bugs in your software, new features, documentation requests, and so on. See this eclipse bug for an example of a bug ticket using the Bugzilla issue tracking software.

There's more, but judging from my own attention span, a second post is more useful.