Automated Testing^2

Man, some people have all the luck.

I ran across this the other day, describing an automated test environment that, if it really is as he says, is truly amazing.  The part that really stands out, to me, is that they're running their test suite on a pool of "30-40 machines"

I really envy that.  My current employer does not have enough test machines for developers to run their own development tests, let alone run a test suite for load testing like that.

Of course, it's a lot easier if you're writing web-based systems.  Then your scaling is conceptually trivial - all you need is a few tens of PCs hitting the server.  If you're developing software for systems that live in a world of other specialized servers, many developed by other companies, then you are hard pressed to replicate more than a handful of systems to run tests on.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Making It Harder To Fail

I ran across this post and I was taken with the idea of making it harder to do bad things.  I especially agree with the color coding of hardcoded values to be ugly and harsh.  Using a larger font is probably an issue of personal taste and programming language choice.

Adopting a coding standard that encourages short, meaningful method names is also good.

Some people really like Hungarian notation, but I've found that using longer variable names is better - you do not need to remember the cryptic abbreviations.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Wheels Within Wheels

Jeff Atwood wrote a post earlier this month about Reinventing the Wheel, where he advocates it as a learning experience, or to make a better wheel.

The problem is that he mistakes the reason people say "Don't reinvent the wheel" - it's almost never because  You can't come up with a better wheel - it's because you don't need a better wheel.

Unless your business is about compilers, or has a need for really tweaked compilers, you don't need to be writing compilers.  Unless your business is about encryption, you don't need to be writing encryption routines.  Unless your business is about email, you don't need to be writing an email client.

Given the breadth of computer science and programming, the odds are very high that you are not as well-versed in the topic as someone who specialized in the topic.  Bruce Schneier has a "Doghouse" classification for companies that badly re-implement cryptography in their products.

Jeff does note that reinventing the wheel can be a good learning process, and gives a nod to Charles Moore rewriting drivers himself for use in Forth, but those are not common cases, and Moore's business was the language, so it was germane to him to make it as solid as possible.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Good Enough is Good Enough!

Given the detail-orientation of many of us, it's not unusual to run across a situation where someone is striving for perfection. The correct thing to do (in most cases) is to stop them.

Perfection is bad from 2 aspects:

1) perfect means it solves every single problem the user has
      This is bad because it means that the system is either brittle, or too malleable
2) the incremental cost of perfection is almost always much higher than the cost of small bugs


One way that a Ninja combats these tendencies is to prototype.  Make a first version that covers the known issues in some way, and have a test run with the end user.  I use this for documents all the time - I'll set out a view of the problem and distribute it for comments.  I find that I get many more responses than if I ask for input before I present something.  If I have no idea about what to write, I make a known-wrong example to insure that all the editors will leap to the occasion to show how much they know about the process and correct me.

The prototype allows you to concentrate on the most important issues first, and to no sweat the small issues until later, when the end user may be satisfied with the prototype, or one of its successors.  Besides, if you prototype, you'll know what works when it comes time to do the inevitable rewrite

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Some Thoughts On The Zone

Most of us developing software have spent some time in "The Zone"; that quasi-mythical mental state called flow that allows us to almost instinctively create good code.  My last extended run in the Zone was a number of years back*, but I was able to spend a number of weeks diving deep into the code and data structures to revamp a major portion of functionality in a system.  I don't know if there are any studies that support the correctness of code written in the Zone, but it is at least strong folklore in the profession. And it's a good feeling, being in the Zone, and makes the development go faster.

So when I read about a development technique that helps you stay in the Zone, I'm interested.  I'm going to try this over the next few weeks and see if it works.

*one of the perils of developing software for a company that does not sell software - you spend a lot of time out of the software process

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP