Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

10 practices of highly ineffective software developers

Andrew Oliver | Aug. 10, 2012
Some are bad habits to overcome; some are poor decisions forced by managers who don't know what they're doing. Read 'em ... and weep

A pessimistic locking revision control system isn't just a disaster in the sense of "oops, forgot to check in and went on vacation." It's a continual drain on the project. I find it incredible that there are still people who believe it's useful to have half the team waiting for a file to unlock than potentially having two people working on the same file (and probably different parts that will merge automatically anyhow).

4. Deliver to production without a branchA vast number of organizations have not yet figured out how to create a branch. Branching is the magic bullet that allows you to deliver a release, fix bugs in that release, but not release any half-developed new code to production. Branching is not actually difficult. There are several effective strategies for it. In fact, every revision control system I've encountered in the past few years supports it. However, branching requires that developers familiarize themselves with their revision control system.

5. Wait until the end to load-test

Even some of the most effective organizations I've seen who've embraced test-first, pair programming, and all of that still think load testing is something to do at the end of the project.

Justification is provided in the axiom "early optimization is the root of all evil." There is some truth to that -- for a microcosm. But you need to know if you are making fundamental decisions that will not allow your project to meet your performance or scalability requirements. The cheapest time to catch those decisions is early in the project.

We're not talking iterators vs. loops or monads. We're talking the wrong data store, wrong algorithm, wrong rules engine, and horrible concurrency issues. Those issues can incur a huge amount of rewriting if caught too late.

6. Develop without capacity/performance requirements

The first question I ask when helping people with performance or scalability problems: How many users does the business expect? Regardless of the technical roots of the problem, the shrug I often get in response to this question is the real cause. A successful project has at least a vague estimate.

This isn't just good software; this is basic business forecasting. To develop a reasonable load test, you need performance expectations. You need to know how many users the system should be expected to handle.

7. Wait until the end to engage users

Marketing professionals have used focus groups for decades. Someone has to validate that the product development group has hit the mark and someone is going to buy it. The same goes for software development. Whether it is an internal or an external customer, someone needs to make sure the end product will pass muster with users as early as possible.

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.