Wednesday, February 25, 2009

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 --
, , ,
HTTP

Tuesday, February 24, 2009

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 --
, , ,
HTTP

Monday, February 23, 2009

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 --
, , ,
HTTP

Sunday, February 22, 2009

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 --
, , ,
HTTP

Saturday, February 21, 2009

What's In A Name?

One of the big issues for code clarity is determining the intent of a function from its name.  One of the tricks that I've taken to doing is to name the function such that when I read the code out loud, it sounds like I'm speaking normally, or nearly so.

For example, if I'm testing a file for various criteria, I'll have this:

if(fileIsRightSize() && fileIsNotWritable())
{
         saveFile()
}

The cognitive benefit from this is immense.  It's not a new idea, but I'm not seeing it get traction in code today.


Technorati Tags --
, , ,
HTTP

Friday, February 20, 2009

Ooooooh, Shiny!

What are the three primary symptoms of ADD?

1) lack of focus
2) easily distracted,
3) hey, look! a squirrel!

Jeff Atwood discusses the magpie tendencies of the industry.  Over a decade ago, I used "magpie" to describe a cow-orker who was too enamored of changing technology for its own sake.  Sometimes it seems that there's another new language every week, and a new web framework every month.  We spend too much time learning Yet Another New Language and not enough time mastering the ones we already know.

Sometimes it's the customer that has this trait.  I once heard a competitor's UI praised because it had oval buttons with drop shadows, while ours was vanilla Motif.  Their system lacked a number of features we had, but because they looked cooler, they were getting the good vibes; and this was not a mass-market system - it was for a specific industry, where the number of systems would be in the few hundreds.



Technorati Tags --
, , ,
HTTP

Thursday, February 19, 2009

Deja Vu, All Over Again

Just over a month ago, this list was published, the top 25 errors made in software.  It's somewhat web-centric, given that most non-web software does not taken input from the great unwashed of the WWWeb.  However, it is a good one to review, to see if your stuff could use a brush up.


Like Alex Wolfe says, it's a little troubling that so many systems are still plagued with these errors, given that there are monthly incidents of the web-based issues (CSS, usually), and more so that some of them are positively ancient (running off the end of a buffer).  And like him, I'm somewhat inclined to blame the current disparagement of the industries' past.  Nobody looks to the pillars of the discipline to see what they are saying.


Now, to some extent this is the typical "youth ignores elders" schtick, but a lot of it is more malignant - it's the rejection of all the collected wisdom because it doesn't have the pizzazz of Ruby, or the Cloud.  And while there are a lot of new things necessary, like the new database features needed for massive scaling, having your server cracked because you let arbitrary SQL commands to be executed is epic fail.




Technorati Tags --
, , ,
HTTP