Programming Resources

I’ve been watching the conversations recently about failed video game launches. When people see bugs in software, they are rightfully annoyed; especially if they’ve spent a lot of money on whatever it is they’re using.

Even if there’s a workaround it’s annoying. When these things happen En Masse, like with the Arkham Knight video game released by Warner Bros. in July, everyone becomes an armchair programmer on how to fix issues.  They also become armchair managers, with ideas on how to resolve the problem.

Invariably, the comment comes up, (as it does with most projects) that there are a finite number of developers who can do a finite number of things, so of course some things aren’t ready to go by launch. There are ways to minimize the impact of bugs, (ie Unit Testing) – but for the most part you’re going to have them, and you just have to deal with them as they arise.

When that argument is presented, though, the response is: Hire more developers. Like taking a handful of people and tossing them into a room with a computer will solve your problems. A team of 5 individuals, (4 good programmers and 1 good architect/manager) can easily do the work of 10 people. There’s a reason lots of developers work fast on their own projects, but slower in group projects. They don’t have to take time to understand what someone else has done.

Integrating a new developer into a team dynamic is difficult. One developer will have to spend time mentoring the new developer on standards, practices, and what everyone else’s code is doing. This in turn hurts that developer’s output, and puts more strain on the team. Eventually this new developer will be a huge asset to the team, able to write code that is of similar quality and usability as the rest of the team, and the overall balance of what the team can accomplish will increase.

But that can take months, and when you’re programming on a deadline, you might not have the time to bring new resources on in a way that makes them beneficial for your company, or your project. I am not sure why this is so hard for people to understand: it happens in every job. I guess the learning curve might not be so steep, or the impact so severe, when you’re hiring a new construction worker to swing a hammer or a cashier to run a checkout stand.

Both of those are great examples, however, of a small team working effectively when there’s a good architect/manager. If someone were, for example, directing traffic for the checkout stands, the customers would flow significantly faster than if they queued themselves up. (Taking into account number of items, payment method, and various other variables.) The same is true for a construction crew. Design and plan things well, breaking them up into smaller, manageable chunks, and the crew will build it faster, stronger, and more securely.

That’s just my two cents, though. What do you think?


Leave a reply