Monthly Archives: February 2009

See, dictators aren’t all bad

Thanks to Uncle Bob’s twittering…

This is pretty much how critical I consider completely automated builds 😉

you should be sure to watch this at home if you can’t get youtube at work!

Truth Hurts

Check this out…

A Better Team

and take the quiz!

My current team and I need to work to improve ourselves :-

But that was just my assessment… I’ll try to get the whole team to collaborate on the “team” answers and see how that compares.

Lactic Acid?

Jason Gorman has an interesting take on a team’s technical debt being similar to a build-up of lactic acid. That is, if you are in a team that is “unfit” and normally not used to delivering quickly, then running fast, as in sprinting through the initial iterations, will undoubtedly be painful. Much like in athletics, where you can build up “lactic acid” and experience pain and be unable to continue. Jason equates this human sort of feeling to “technical debt” building up in the development project.

While I can appreciate the analogy, avoiding technical debt in a software project is a lot more difficult than becoming more fit and increasing your lactose threshold.

Also, a team can work at a sustainable pace just by coming in at 8:30am, going home at 5pm, not checking emails on the weekend or at night, and plodding through the features and fixing bugs as they come up. Such a “sustainable-paced” team could simultaneously be building up US deficit-sized technical debt (well, okay, nobody could achieve that measure of stupidity ).

But, I *know* what Jason means. I just think that sustainability is not *the* foundation of Agile. On the contrary, I would surmise that sustainability is a side effect of having a lot of the “right things” going on in your organization, and something to strive for as part of the recipe for success.

To Prefix, or Not to Prefix

Today I had a little “tiff” with a developer about something very trivial by most accounts. Maybe I was having an off-hormone day, or my biorhythms are off.

A simple table was proposed to hold the text name behind a status property. Something as simple as:

ID STATE
1 DRAFT
2 REFERRED
n STATEn

The developer suggested “status_description” as a field name. That was all it took to chew up 25 minutes.

The IRC conversation goes something like this:

11:16 <jon> what do you propose for state name?

11:16 <sam> status_description

11:17 <jon> that’s too long of a field name

11:17 <sam> status_name then

11:17 <jon> i want to say s.name

11:17 <jon> no status_

11:18 <jon> i hate that 😉

11:18 <sam> nope, no go homey

11:18 <jon> the table tells me what it is

11:18 <sam> name is too generic

11:18 <sam> you’ll have 50 tables with “name” field

11:18 <jon> but how can it ever appear out of context?

11:18 <jon> i love 50 tables with name, it forces table aliases and context (like classes and properties)

11:21 <jon> if you repeat the table name on every field… it makes for more fun typing things like that over and over when you are writing sql

11:23 <mac> we do have xxx_id everywhere… for the primary key field

11:23 <mac> i hate it, but it *is* consistent. however, status_name is not necessary, i agree, jon

11:24 <jon> i abhor useless prefixes, it leads to lousy coding, makes the human the compiler

11:24 <jon> but that’s just me

11:25 <jon> i’m going to hibernate for a while, head back to doing C coding and structured crap so i stop thinking in OO

11:27 <sam> not that it matters but prefix has been an Oracle paradigm

11:27 <jon> it doesn’t matter. microsoft used “m_” prefixes on class members (IIRC) and i hated that too. just because a BIG company does something doesn’t mean it is a good idea. IMHO, it is a horrid paradigm to add extra stuff on everything

11:27 <sam> not really, it’s just preference

11:28 <jon> yeah, and my preference is for clean code 😉

11:28 <sam> btw: the object model doesn’t have to match the sql model

11:28 <mac> but prefixes make the SQL read poorly and is extra typing with no benefit

11:28 <sam> for instance the underscore thing I hate with oracle

11:28 <jon> why on the table Person would i want to see every field prefixed? For example, person_first, person_last, person_birthday…

11:28 <jon> of course the FIELDS IN PERSON ARE FOR PERSON

11:29 <jon> who would think otherwise if they are staring at columns like First, Last, Birthday in a table (or class) called Person?

11:29 <mac> where q.section_id = s.id is fine. i preferred “q.fk_section = s.id”

11:29 <sam> just the common id and name… that could be on 100 tables. name is very generic

11:29 <jon> yea, the beauty of tables… THEY PROVIDE CONTEXT to things like id and name

11:29 <sam> you don’t have to prefix though

11:29 <mac> p2_question.name if you avoid aliases for some reason.

11:30 <sam> it’s a DBA thing guys

11:30 <jon> Really? it is better practice, imho, to have context via table alias not prefixes. Maybe I don’t always buy all DBA rules

11:30 <jon> if there was only id,name, across 5 tables, you can’t make a mistake because you HAVE to put it in context (i.e., add a table alias)

11:31 <sam> guys this helps

11:31 <sam> what happens when I create a datawarehouse with a bunch of “name” fields

11:32 <sam> it kind of becomes a redesign effort where prefixes are then needed regardless

11:32 <sam> make sense?

11:32 <mac> use good aliases in your queries?

11:33 <jon> no, it makes *no* sense to me… when u create a datawarehouse you name things properly instead of demanding prefixes.

11:33 <jon> but don’t screw up every table with prefixes for all other use for the someday nicety to not have to make the datawarehouse column names clear

11:34 <jon> why pay the penalty in all coding all the time? please don’t spread the pain 🙂

11:34 <jon> i like to keep the crap in a small part of the app

11:34 <jon> if the dw has to have field names like person_name, agency_name… so be it

11:35 <jon> but i’d rather everybody did this consistently with no prefixes

11:36 <sam> Jon, there are countless whitepapers on proper db design, one google yields this

11:36 <sam> http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/

11:36 <sam> speaks to my concern

11:37 <jon> gee where are the prefixes?

11:37 <jon> NOWHERE

11:37 <sam> CustomerName

11:37 <sam> don’t see that?

11:37 <jon> That’s one tiny example in a sea of non-examples. Not to mention this:

11:39 <jon> “Along these same lines, resist the temptation to include “metadata” in an object’s name. A name such as tblCustomer or colVarcharAddress might seem useful from a development perspective, but to the end user it is just confusing. As a developer, you should rely on being able to determine that a table name is a table name by context in the code or tool, and present to the users clear, simple, descriptive names, such as Customer and Address”

11:40 <jon> FWIW you will never sway me to the dark side of name prefixes for everything 😐

I had to go outside and toss the Jolly Ball in the snow, wind, and 5 deg F (wind chill), with my Yorkie…