Personal vs Professional Software Development

by Krishna on May 20, 2007

Hacknot is back after two months with another hard-hitting article on what is really important in software development, namely Requirements Management. One of the significant points made in the post is the fact that requirements management is given so little press when compared to all the coding and design issues. Here are a couple of important factors behind this:

  1. Requirements Management is hard: To collect requirements, you have to spend significant effort in discussions with end users with all sorts of personalities and pre-conceived notions. Users sometimes have irrational needs and have very little idea of how much a particular feature will cost in money or effort. It is not a glamorous task.
  2. It is only the beginning: When you collect requirements, the output is a document or some technical artifact that end users cannot use. The construction of the final product has still not begun. In fact, many customers unfamiliar with software development balk at the effort taken in requirements gathering because no “real work” gets done during this process. You may think that people don’t say the same thing about a building blueprint, but unfortunately that is the reality — so we have to deal with it.

But here I want to talk about something that is often overlooked: There is a huge difference between the software development that programmers do individually and how they should be doing it in a project team.

Let us take the first case: developing a software program alone. There are many possible situations where this can happen. You may be learning a new language or environment. You may be developing a program or website as a hobby. You may be the only software developer to build the program.

The common factor in these situations is that the program you are building is relatively simple. You usually know everything that has to be built. The program is not large enough to be complex. You can be intensely familiar with every line that you write and know every dependency in the code. If you want to fix something, you can usually do it in minutes.

What this means is that your primary overhead is coding. You don’t have to spend much time understanding the requirements. Your design needs are very simple. Testing and maintenance needs are relatively low. If there is some bug, you pull up the code, fix it quickly and run it. Performance requirements don’t even enter into the picture. If it is a data processing program, you can always go and get a snack while it runs.

So, your focus is on coding-related issues. First of all, anything that allows you to write less code for the same output quickly becomes your choice. Perl for string processing and Ruby on Rails for web development come to mind. An important aspect of choosing a language, IDE, framework or control to solve a problem is that you don’t have any need to customize it. This is usually the case in personal coding. The out-of-the-box functionality is usually sufficient for personal programming needs. In a previous post on such frameworks, I wrote about several considerations for real-life programming; such issues are not valid when doing personal software development.

What about design issues? Most personal programs are too small to really use many important design considerations — both at the code level as well as the user interface level. You could really violate every coding or design guideline and still get your program working correctly and being useful. While design patterns make it easy to maintain a program, smaller programs can be easily fixed by brute effort. As for user interface problems, the small user base (sometimes just you) can learn how to use round-about means to use a particular functionality.

Now, let us look at professional software development. Here you work in a larger team for creating a solution for many users. The project effort can be calculated in thousands of man hours of development effort. Here, communication is very important. The team members need to know what has to be built. They have to understand the user needs and how different parts of the system relate to each other. Building something that the user does not want means project failure.

An important thing to remember is that requirements are non-trivial. People cannot remember all the details and the long period of development means that even if people remember some detail today, they may forget at a later time. Hence, requirements must not exist in memory or hear-say, but instead in a tangible format like documents, use cases, prototypes, etc.

Design and architecture also become important. Without establishing common standards, guidelines and interfaces, it becomes tough to bolt the application pieces together to solve all the user needs. Inconsistent user interfaces and behavior can confuse the user and lead to low adoption or high rework. Poor design also has implications for performance, security, concurrency, etc.

Testing, which had low significance in personal software development, assumes a vital role in building real-life products. Practically speaking, it is impossible to document and design for all user needs. End users, being less technical, have great difficulty in expressing what they need and only truly understand what they want when they start using the system. The one truth about software development is that it never ends when you think you have developed everything users need.

Also, user requirements are never static. If you write a spec, you are only capturing a snapshot in time of what the users need. While you are busy coding, their business needs evolve, government regulations change, employee turnover happens. So your final product will go through significant changes from your previous documented requirements. Hence testing occupies a real part of software development.

Let us take some of the important activities in a real-life project and give them a percentage for development effort

  • a% effort for Requirements
  • b% effort for Design
  • c% effort for Coding
  • d% effort for Testing
  • e% effort for Maintenance

The value for c% would be much higher for personal software development when compared to the effort in a real-life project team. What does this mean? This means that even if you use a technology or tool that makes for great savings in coding time, you still have to deal with the other aspects of project development.

Let us take a project that lasts 6 months and assume that coding takes 3 months (50% of the effort). Even if you have a magic technology that instantly converts your requirements into code in a minute, you have only saved 50% of effort or calendar time.

In practice, of course, using the best tool doesn’t yield quite the savings you think it would. For example, here are some of time-consuming activities during coding:

  • Tackling technical challenges and risks: It is not a matter of writing code. It is a question of whether you can even do a specific requirement in software.
  • Knowing how to interface with third party hardware or software: You have to learn about the API’s, web services or device drivers, as the case may be.
  • Debugging silly errors in logic: Did you ever have an “I cannot believe I wrote that” moment after you found the error? Then you know what I mean.
  • Extending an inbuilt functionality: The data grid or calendar control has 95% of what you need, but that last piece of functionality is missing and you have to now write code to circumvent that problem. A coder’s life is filled with such frustrations.

A very important word of caution: Do not take “a good programming environment does not significantly reduce overall development effort” to mean “bad programming environments does not increase programming effort.” In fact, when a programmer does not get to use the language or tool he likes, his productivity dips as he takes time to understand the details and idiosyncrasies of the new environment. Good compilers and source control systems can reduce human errors in software development.

Buy the best software development tools you can afford. But understand that it can only reduce development effort to a certain degree. There is no getting away from other important demands like understanding what users need (Requirements), building the necessary architecture (Design) and getting user acceptance (Testing). The more software developers understand these needs, the more successful their final products will be.


Software Developer May 21, 2007 at 4:09 am

Also I couldn't stress the importance of code versioning using systems like SVN and backups

Yuvi May 21, 2007 at 5:33 am

Right on the Money. My Statbot code contains so many hacks and hardcoded paths and whatnot that I'm quite sure it won't run on any other PC than mine. Also, a lot of hacks and ugly, non-performant, rebundant code that I wouldn't even consider writing in any type of production code is now being written at this instant for my Engadget Statbot....

As I said, Right on the money dude!

Krishna May 23, 2007 at 12:29 pm

@software developer

Yes, code versioning systems are much more important in professional development


thanks for your comments. I have many code snippets that I would never run in real production.

Comments on this entry are closed.

Previous post:

Next post: