|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 3
4. Deliver to production without a branch
A 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.
It can be embarrassing and troublesome to show your software in a "rough state," but if you don't, whether or not you meet user expectations will be left to chance.
8. Try to buy your way out of software development
The buy-vs.-build question is one of the most basic conundrums in IT. Obviously, commercial apps make more sense than internal
app dev in some cases, as do commercial or open source programs that maybe woven into some larger project. But it's also possible
to license, say, the entire Oracle or WebSphere stack and deliver absolutely nothing. There's a limit to how much stuff your
development team can actually absorb and use before the complexity of the stack outweighs any supposed technical benefits.