Cut and Paste

Any software architect that promotes cut-and-paste as anything other than a last option needs to abdicate her/his job title immediately. 

"Backspace" Browser Boneheadedness

What idiot decided that backspace should, in ANY mode, be equated to the same functionality as the browser's "Back" button?!!    Hangin' is too good for him/her.


I can't count how many times I've been putting information into a webform, when I hit backspace to clear something I've typed.   Somehow, the magic of user interface takes me back to the previous page (and because I'll usually hit the backspace key a number of times, there's no telling how far back in the history I'll end up.)   Sometimes, the form will still be populated when I come back, but that is rare.  

I've run into this problem in IE and in Firefox for years.  I hope someday, that "feature" is removed.

In the meantime, I'll try to make less mistakes ;)

The Fromagier's Commandments for Development

There are any number of these lists out there - these are just the ones that come to mind right now. I imagine this list will grow over time as I find more pain to reduce. Generally these commandments come about because some fool has caused pain in such fashion.

• Thou shalt not ever check in code that does not compile.
• If thou shouldst check in code that does not compile, thou shalt fix the error while forsaking all other tasks.
• Thou shalt never consider "It works on my machine" a valid defense of errors.
• Thou shalt document thine code with real descriptions.
• Thou shalt use descriptive method and attribute names.
• Thou shalt always use full descriptions of changes when checking in code - "some changes" or "" shall incur wrath.
• Thou shalt avoid the use of constants-only classes or interfaces as thou wouldst avoid a plague of locusts.
• Thou shalt read Effective Java http://java.sun.com/docs/books/effective/ thoroughly and use as a reference.
• Thou shalt always unit test
• Thou shalt never underestimate the value of quick peer code reviews.
• Thou shalt always favor the interface over the class implementation in method names especially in external interfaces.
  For example, the method ArrayList getObjects() should, instead, be coded as List getObjects() or Collection getObjects in most cases.

The Inherent Narcissism of Software Architects

I am Mark, and I'm a software architect.

[Hi, Mark]

Software Architects think that our ideas of design and architecture are important (otherwise, we probably wouldn't do what we do), and often, we allow our personal passions and convictions rule our designs, rather than have principles of good design guide us to our convictions. When we stop questioning and revalidating our mental code base, we start hurtling down the path of irrelevance.

I've noticed that I, like many of by brethren/sistren, tend to prattle on at times about various things that I feel are best practices and requirements for a good software design and development mind. Mostly, they're things that other people have said before, but occasionally, I come up with something interesting all on my own. In the interest of re-use and posterity, I thought I would capture some of these thoughts, along with my inimitable charm and wit, here, primarily so that when I move from project to project and team to team, I can refer folks to this weblog.

So, if you're interested in what I've thought about various issues in the past and present (which, for the purposes of this medium is just a more recent past), feel free to follow along. I have gained in my 13 years of software development experience a very zen approach to software development that sometimes gets me into trouble in a debate - I will often say that something just doesn't look or feel right about a particular set of code, but, I wouldn't have been in this business this long if my nose wasn't right more often than not. I love what I do - and the people I get to work with solving the kinds of problems we get to solve are the main reason why.

So, onward into the sphere o' weblog...