Practical Programming (part 1)

There are many factors affecting the success of a software project. Amongst them, we have

  • Skill level of individuals (from manager to coder)
  • Time involved
  • Tools involved
  • Project complexity

and probably many more you can add. So how can you successfully complete a project practically? How can you balance customer satisfaction, code quality, time constraints and other factors in the most efficient and practical manner?

I was intrigued to explore this when one person asked how can one prepare for a new project and another person asked about end user testing. For those following this blog, you might know that I’m helping out with two teams in my company. Right now, I’m their only .NET (and front-end) developer. My colleagues deal mainly with the backend programs.

I’ve been involved in a start-up company where there was only one other programmer. I’ve also worked with a team of over 10 programmers, of different nationalities, working on a project involving culture localisation in a language none of us were native in (Japanese). Given my current situation, I’m the only programmer, so I’m really interested in practical stuff.

Coming from a mathematical background (as opposed to a computer science one), I don’t know a lot about software development theories and paradigms and stuff. So from what I understand, there is the extreme, full-on software development life cycle (SDLC), complete with UMLs and class diagrams and process flow diagrams and what-nots. There’s usually a lot of documentation involved (I hate those…). There’s usually platoons of programmers involved. There’s usually expensive software and tools and databases involved. The projects are also usually measured in months or even years.

Being mired up to my nostrils in documentation, bureaucracy and meetings with no motivation from completing significant milestones, is not my idea of a fun time.

In this age where the world is getting flatter, companies need to move faster, teams need to move faster. You need to move faster. What happens is that products and services need to be launched faster, earlier and more frequently. And you know what? I don’t think the method of software management mentioned above is going to cut it.

In an age where there’s less time and resources, and you’re expected to create more value, the full life cycle method will drag you down like a 10-ton anchor into the depths of dwindling profitability. Programming practically in this situation requires you to rethink process flows and cut out the fluff. It requires you to be more flexible, more multilingual, more agile.

The point of programming, of creating software, is to make people’s lives better. The resulting software must be practical (or at least fun). The process of creating the software must also be practical (and definitely be fun). So in the next part, we’ll explore the other extreme, of how agile methodologies fit into practical programming.