Alex Papadimoulis' .NET Blog

"A client has asked me to build and install a custom shelving system. I'm at the point where I need to nail it, but I'm not sure what to use to pound the nails in. Should I use an old shoe or a glass bottle?

How would you answer the question?

a) It depends. If you are looking to pound a small (20lb) nail in something like drywall, you'll find it much easier to use the bottle, especially if the shoe is dirty. However, if you are trying to drive a heavy nail into some wood, go with the shoe: the bottle with shatter in your hand.

b) There is something fundamentally wrong with the way you are building; you need to use real tools. Yes, it may involve a trip to the toolbox (or even to the hardware store), but doing it the right way is going to save a lot of time, money, and aggravation through the lifecycle of your product. You need to stop building things for money until you understand the basics of construction.

I would hope that just about any sane person would choose something close to (b). Sure, it may seem a bit harsh, but think about it from the customer prospective: how would you feel if your carpenter asked such a question?

I find it a bit disturbing, however, that this attitude is not prevalent in software development. In fact, from what I can tell, it seems to be discouraged. 

I've been participating in Usenet/forums/lists for a decade now, asking programming questions and helping out others who have questions of their own. If some one asks a question that demonstrates the complete absurdity of their design, I'll generally reply with my (quite candid) opinion on their design. To give you an idea what I'm talking about, here's something I remember seeing a while back (from memory).

Subject: Aggregates Help
I have a table that stores test results for milling machines. Each test consists of N-runs conducted by a measurer going M-trials each. I have this information represented in a varchar column in the following format: "44:1,5,4;23:2,4,9;14:1,4,3".  When the column is read into the class, it is converted into a jagged array: ( (44,(1,5,4)), (23,(2,4,9)), (14,(1,4,3)) ) of runs (3 of them) and measurers(Ids of 44,23,14) and trials (1,5,4 and 2,4,9 and 1,4,3).

One of the reports I have is a deficiency report, which predicts which machines may fail. To run this, I have a report class that loads up the appropriate tests and processes the information. However, this is taking longer and longer to run. I'm thinking that running it in a stored procedure will be quicker.

I can figure out how to get an "array" in SQL with a table variable, but how do I make a jagged array? Any ideas?

Some of the folks on in the list took it as a fun challenge, going back and forth with how deficiencies are calculated, and providing some incredibly brilliant ways of solving this problem.

Not I, though. My response was something to the effect of …

This is quite possibly the worst way you could store this data in a database. No, seriously. They had better ways of doing this over thirty years ago. You have created a horrible problem that is only starting to rear its ugly head. It will only continue to get horribly worse, costing your company more and more money to maintain.

You need to drop everything your doing right now and take a trip to your bookstore to get a database book. I recommend INTRODUCTION TO DATABASE SYSTEMS by DATE, but at this point anything should do. For the sake of everyone who will maintain your future code, don't touch a database until you understand how big of a mess you've created.

How do you think you would have responded to that post? Would you have taken the challenge to think about how to solve the problem or just take the opportunity to school the poster?

If you say the former, then you probably think I'm a grumpy curmudgeon (more likely, less family-friendly words though). My appeal to you is to think back to the carpenter. How is this any different? How fair is this to person paying him to develop software, or, more importantly, the poor sap that will have to come in and not only understand the mess, but maintain it. That poor sap could be you one day!

If you say you'd go with the latter, harsher reply, then I ask, why aren't you out there participating in the newsgroups/forums/lists? We need more people like you out there: there are too many of the people who tell people exactly how to apply the duct tape without giving the poster a firm scolding. 

But I think the problem is worse than not having enough grumpy curmudgeons: in my experience, forum moderators actively delete critical posts that don't solve the problem, keeping only the hacks that solve the hacks. When new users come to read the posts in the future, they may actually think, "hey, I could use this to solve my problem."

Am I on the wrong side in this? Should we actively be encouraging new programmers to use their horrific techniques? Or am I just looking at this the totally wrong way?

I've come across a truly revolutionary software development methodology called Front Ahead Design (FAD). Essentially, it's a fundamental paradigm shift over "traditional" and "neo" ways of building software. Not only does it surpass every software development methodology out there, it solves every problem there is to building software (and then some). But don't take my word for it, here are the Top Five fundamentals ...

I. Front Ahead Design
The essence of FAD is conveyed directly in its name: design your front-end/user-interface first, ahead of everything else. The customer could care less what's behind the scenes, so long as it looks good and does what its supposed to. Deliver a working front-end first and then Do What It Takes to fill in the functionality gaps.

II. Do What It Takes
Other methodologies are great at delivering excuses. How many times have you heard (or have been told) "we can't do that here because it could throw off the whole design?"  In FAD, you just do it (that would have been the bullet point, but Nike has it trademarked). To get it done, you Do What It Takes. Your customer will love you.

III. Code Light, Not "Right"
A traditional methodology calls a complex framework with layer after layer of objects. In those ways, adding a simple value to a form can be a monumental task, requiring it to be added to every single layer. Does that sound right? Proponents of the other methodologies will tell you it is, but what about your customer? With FAD, you just Do What It Takes to add the functionality to your interface. No more.

IV. "Throw Away" Diagrams
Think of all the Visio diagrams you've drawn over the years. Sequence diagrams, context diagrams, flow charts, and so on. Was that really productive? Did your customer ever see any of those? Were those diagrams even relevant after the system was finally developed? Didn't think so.

In FAD, all diagrams are made on a disposable medium. Whiteboards, napkins, even your forearms work. And there is no formal modeling language to battle with: just Do What It Takes to draw and explain your design to other developers.

V. Life Is Short (a.k.a. Patchwork)
The average software system has a life expectancy of seven years. No matter how "properly" the system is designed from the start, within the first year of its life, maintenance programmers unfamiliar with the complex architecture (and having no help from out-of-date documentation) will turn the system into a complete mess with bug fixes and change requests.

In FAD, this isn't even a concern. We know the short life span of a system and develop every feature (from the interface) as a patch. Maintenance programmers can come in and Do What It Takes to add their patches. In FAD, we don't even try to stop the aging process. We encourage it.

There's quite a few more fundamentals, but that's all I've got time for today. I'm incredibly busy trying to finish a book on the topic (halfway through it!!). Hopefully, it'll make it as the first FAD book. I hear some other big names are in the first FAD book race, too.

I also came across some community sites:
  FADblogs.com - .TEXT blogging site, open for anyone to blog about FAD
  FADisIn.com - general informational site with articles, help, discussion, and tools
  ItsAFAD.com - gallery of successful projects (from small business to enterprise) that have successfully used FAD

They're all under construction, but I'm helping a lot with the FADblogs.com, so let me know if you'd like to be one of the FAD bloggers.

Next article: a comparison of the FAD design tools, including H/YPe and nFAD.

 My post the other day (Computer Programmer Inflation) got me thinking of another type of inflation that I've observed over the years: Comicality Inflation. Like other types of inflation, it's not as if things have gotten funnier, it’s just the terms we use to describe them.

Back in the day (and I'm talking the day; as in, before electricity and all that), if a friend sent us a letter that we found entertaining, we would simply compliment it when we penned our reply: Archibald, I must concede your quip about poor Rutherford’s embarrassing gaffe was quite witty and remarkably entertaining.

Thankfully, those days are long gone, replaced by the ever-so-simple (though dreadfully less elegant) onomatopoeic interjection "haha" (and it's cousins, "hehe", "hoho", etc). One of the great features of "haha" is that it is an expandojective: the intensity of its meaning is proportional to its length.

• ha - mildly amusing, possibly causing a very soft chuckle
• haha - funny, causing at a minimum a chuckle, but most likely a snort
• ...
• a-hahahahahaha - busting out in full-blown laughter requiring a pre-laughter breath (hence, the "a-")

By the way, if anyone knows the proper term for such a word, please advise. It's not as if "haha" is the only expandojective. There’s "aaagh", "aarrg", "reeeaaaaly", "zzz", and so on. These magical fantastic words truly need their own category.

Anyway, it would seem that "haha" would be the perfect way of indicating the comicality of something you read.  After all, it expands as things get funnier and it even has lots of room for personalization ("ho-ha-ha","teehehe",etc). Alas, it is not; some one had to come along and create the acronym "LOL".

On its own, I don't think that LOL (Laugh Out Loud) is a terrible thing. After all, there's no official "ha" scale and it's quite hard to tell if "hahaha" means "I laughed out loud" or "I had a series of snickers."  It's the abuse and extension of LOL that really offends me.

First, let’s consider the abuse. How many times have you seen people reply with "LOL" and you know, for a fact, that what you wrote wasn’t possibly that funny? And if you think exaggerative flattery is excusable, consider the typical teenage instant message conversation:

princessGurl1924: heya becca, hows it goin, lol
angelKitty77: omg, lol it's goin pretty good lol. u??
princessGurl1924: lol good good!~!!

If I knew anyone who laughed that much in real life, I would suggest that they have some serious mental disorder. Or that they are high on some cocktail of illicit narcotics.

I know that I'm not alone in this observation. I've noticed that quite a few people have started to differentiate between LOL-funny and Laugh-Out-Loud-funny by replacing the latter with the absurdly redundant "LLOL" (Literally Laugh Out Loud). I swear, if we ever begin to figuratively LLOL, I will have no choice but to become a Luddite.

I’d have to say that the extensions of LOL offend me the most. Let's consider the most prevalent:

ROFL (Rolling On the Floor Laughing) - I've seen a lot of funny stuff in my day, and, let me tell you, I'm a laugher. But I have never seen anything that was so funny that I dropped to the floor in a fit of uncontrollable laughter. And if you ever have, it certainly wasn’t while reading something on the internet.

 

LMAO (Laughing My Ass Off) - Some might say that this is not fair game because the colloquialism "laughing my ass off" had existed prior to the Internet. No less, I still consider the acronymization to be a direct result of LOL.

 

ROFLMAO (Rolling On the Floor Laughing My Ass Off) - A total unnecessary expansion of an expansion. Since when was an uncontrollable fit of laughter causing one to drop to the floor *not* the most extreme reaction to humor possible? And what, precisely, is the difference between laughing while rolling on the floor and laughing your ass off while rolling on the floor? How possibly could one distinguish between the two?

 

ROFLOL (Rolling On the Floor Laughing Out Loud) - I'm guessing this falls somewhere between ROFL and ROLFMAO. But it’s just another pointless expansion. We already know that there is no difference between ROFL and ROFLMAO, but think about what ROFLOL implies. Someone who is rolling on the floor in laughter isn't doing so audibly, just quietly rolling around on the floor, laughing to themselves.

 

LOLOLOL (???) - I don't even know what this is. Laugh Out Loud Out Loud Out Loud? Laugh Out Laugh Out Loud Out Loud? How exactly did an acronym become an expandojective? It's "words" like this that make me long the good-ole-days before "haha" was created.

I know we've all used these new-aged acronyms (except LOLOLOL, I hope). And I know we probably won't stop. But, at least consider this rant next time you reply with ROFLMAO; it just may just enhance your fits of laughter while you're rolling around on the floor.