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…
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.
Pomodoro
Following on a tip from Uncle Bob Martin, I am going to try this out
Pomodoro Technique in 5 minutes
While I already use a timer for activity tracking, the method is not as nearly as refined and intriguing as Staffan’s
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…
Cognitive Surplus
This is a very interesting take…
The IT Albatross
Steve Gordon posited the following in response to the original poster thinking about
Original Post:
I explained in a simple words as possible the competitive advantage they could get if they give agile a chance, so I hope they will agree on a pilot project. Otherwise, how can they tell if they like chocolate cake without tasting it?
Steve replies:
With no measurable problems, what would be the success criteria of a pilot project anyway? Do you really expect them to adopt agile just because they liked a taste of it, even though it did not measurably improve anything?
IMHO, lack of “measurement” is the albatross around IT’s neck…
heck, i can’t even prove why my design is better than the next guy’s with anything other than a damn sure guarantee that his design will be worse. I base this solely on experience. Yeah, I suppose I could throw out a few metrics… but tying those to “success” or cost is hard to do. One of the problems is that BOTH solutions will work. I know he could get his solution to work, but I am also pretty sure it would be overkill, a nightmare to maintain, and difficult to extend.
I am tempted to put up the two competing examples and get folks to comment… one of these days.
This is generally not so difficult to do in a “hard” engineering discipline. One can usually compute costs of two solutions, roll forward estimates of how each design will cover future scenarios, determine the value proposition going forward, and choose which solution is best for business.
Until we get to this point in Software Engineering, it will forever be a fool’s challenge to “prove” one solution/process is the right way to go. (Not to mention the excessive variability to software that is inherent in its very nature.)
Management By Magazine
Agile Project Management forum got this post:
While on a business trip overseas last week I had an in-promptu meeting with a potential customer during which I explained to them the benefits of Agile. As result the excutives[sic] asked me to send them more info and a proposal. Upon my return to the USA I did so and got a reply from them this morning indicating that they are currently using the “Fast Track” approach to software development. That term is entirely new to me in the context of sw dev.
Before I reply to them with the big question mark, and potentially sounding stupid, I wanted to check if any of you know about it and if so I will highly appreciate a pointer to more information.
Hi,
I think it is some project management software…
So… might be a bad sign.
You: “We specialize in agile development and find it really helps meet business needs… What type of s/w development processes do you use?”
Potential Client: “Oh, we use The Microsoft Project SDLC Process.”
You: “Oh, I feel my phone buzzing, I gotta take this call. It might be my ‘Management By Magazine’ book editor.”
An Agile Parable
This is a great parable about agile development.
Share it with your “management” or clients that might need a boost to their understanding of what agile could become… if people embrace the concepts.
Track Hours?
From Alan (a thread on agile project management forum):
Now as to the why-bother:
1. Government reports require (a) a summary and explanation of R&D activities, and (b) an auditable tally of hours spent doing this.
2. To develop some basis for estimation, I need to know how much effort goes into development. My time is very irregular, and I honestly have no idea how many hours are put into programming on any task. I don’t know if it varies from week to week. I don’t know how long it will take to finish a project AT ALL.
I am suggesting that tracking hours is but one small wee part of estimation… and it must be combined with other, larger pieces of the puzzle to impact estimates. Unless of course, your work is repetitive and non-thinking. Like stamping out license plates.
Though you can certainly have everyone track hours & tasks to the minutest detail… what is the other unit of measure? Lines of code? Features? Story Points? That is, will you strive to be able to predict Lines of Code per hour? Hours per feature? Days per Story Point?
See rest of post here: