After being in the software development space for a while you start to notice a relationship between software design quality and software development speed. Software design here doesn’t just mean UI/UX design, it refers to the structure and relationship of software components as well as software development paradigms.

“Size was the single most important factor in the resolution of project outcome.” — CHAOS Report 2015, Standish Group.

The larger a software project is, the higher the chances it’ll fail. Let’s define what makes a software project large. Any project with more than 1M source lines of code (SLOC) is considered a large project. 100k to 1M SLOC would fall into the medium category, while any software project with 10k to 100k SLOC can be considered small. A software project with less than 10k SLOC is tiny.

The information age has brought a lot of pressure on people’s attention. You are not immune to it and your software development team definitely isn’t either. The nature of software development requires long uninterrupted blocks of time to focus on problem solving. The longer you focus on a problem without interruptions the deeper you get into a state of flow, commonly referred to as being “in the zone”. Where everything is fluid, and smooth, and… until someone taps you on the shoulder just to tell you that they sent you an email 3 seconds ago.

The word communication gets thrown around a lot in the software development space but what does it really mean? Why is it even important to start with?

I recently downloaded a software tool to help me complete a task but upon executing it, it failed to run. Initially I thought it was due to the poor internet connection. I fixed the network but it still won’t run. No error messages, nothing. After a few minutes of trying different things I realised that the software won’t run because a library it relied on was no longer supported by the operating system I was using. Software deterioration is the phrase used to describe this type of situation.

“The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.” — Steve McConnell, Software Estimation Book (2006).

People use software estimates as predictions anyway, and this leads to numerous issues.