Crew bags in the bulkhead overhead

<pet peeve>

This has happened to me on several recent flights. I am seated in the bulkhead of the airplane - sometimes in first class. I open the overhead bins and airline crew bags are taking up that precious space.

As frequent travelers know, bulkhead travelers must put *all* baggage in the overhead, which increases their overhead space requirements. Flight attendants putting their luggage into that limited overhead space is inexcusable, particularly since there is no need for them to gather their luggage until everyone else is off the plane. When they use this space, bulkhead passengers must place their bags several rows back, making the deplaning process much more difficult (swimming upstream to retrieve bags).

</pet peeve>

Kudos to the Airtran flight attendants on my most recent trip, who spaced their bags out over several different rows beyond the bulkhead.

www

Listening to the radio - folks talking about words. One problematic pronunciation is for folks pronouncing website names.

double-you, double-you, double-you ... 9 syllables, awkward

dub dub dub .... 3 syllables - better

Three-Dub ... OK - maybe this one isn't used - just throwin' it out for consideration.

Politics at work

I just read The Five Dysfunctions of a Team on the plane this week.

I saw an interesting interpretation of the term "politics" which intrigues me:

"Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think."

Threshold Anxiety

"Kierkegaard, the nineteenth-century Danish philosopher, first described what has come to be known as 'threshold anxiety'. He describes the feelings of a young man who is about to leave home to go out into the world to seek his fortune. As he stands on the threshold of the house, about to leave, he feels that he's turning his back on everything that is warm, familiar, and secure -- what he has known all his life. Beyond the threshold lies the world, filled with all that is unknown and strange. If the young man turns back at this point, he is lost. If, however, he can take the fear of the unknown and turn it into the excitement of the unlimited possibilities which are open before him, he grows in the moment and is alive, as never before."

- Mildred Newmand and Dr. Bernard Berkowitz
How to Take Charge of Your Life

Squirrel Agile

A client shared this term a few weeks ago that I really liked: Squirrel Agile. Thanks Steve.

I'm sure you've seen a squirrel trying to cross a street. The squirrel starts off on one side of the street, looks, darts out, then sees something scary and retreats. Sometimes he retreats all the way... sometimes he just stops in his tracks. When he starts again, he may continue trying to cross, or may high-tail it back to the original side of the street.

In agile adoption, we sometimes see fits and starts... and retreats - just like the squirrel.

One aspect of agile adoption - self directed teams - seem to me to suffer a great deal from this behavior. Management agrees to self-directed teams in principle, but as soon as the manager fears loss of control, or loses confidence in the team's ability to deliver, the agile squirrel darts back towards the original side of the street. The command-and-control tendencies return.

Other fits and starts occur when you start taking shortcuts in your approach. "We don't need to do a showcase this iteration; we don't have much to show". Or "We're 98% complete with this story - let's take credit for the story in our burn-up, since we'll finish it quickly at the beginning of the next sprint." I'm sure you can come up with other examples.

These behaviors mirror the squirrel's fear. These short-cuts and adaptations are typically not to improve effectiveness or efficiency, but reactions to fear of judgment. My suggestion: rather than darting back and forth as you cross the road, take a deliberate approach with courage.

agileshout

I just recently discovered this StackOverflow implementation focused on Agile issues: http://agileshout.com. Seems to be low traffic at the moment, but perhaps my agile friends can find some value there.

I'm not quite sure why it's necessary to have a separate site from StackOverflow, since the tagging mechanism in StackOverflow permits differentiation of topics (e.g. "agile") and cross tagging of topics (e.g. "agile" and "BI") that might not otherwise find a specific home on a specific site.

Task breakdown - To do or not to do

I've had this conversation with agile folks over the years. It's about task breakdown. This is not entirely fair, but I'll say it anyway: I consider it one of the "thou shalt" approaches of agile by the numbers... or by the tools.

Assume a master story list with estimates based on points.

The iteration planning meeting (IPM) looks like this:

Foreach Story in Candidate list:

• Product owner: Describe the story
• Team: break the story down into tasks
• Team: estimate the effort for each task in hours
• Iteration Manager: Increment the task hours counter by the amount of the task hours for this new story
• Iteration Manager: Measure the task hours against the team's ideal capacity and report how full
• Team: If iteration is full (based on ideal/actual capacity) leave foreach

As the iteration progresses, we see this:

Foreach Day in iteration:

• Team member: update the remaining task hours for each of his/her tasks
• Iteration manager: udpate/publish burn-down
• Iteration manager: interrogate team members whose tasks are moving "slowly"

There are some benefits to breaking work down into tasks:

• Intra-story progress can be measured by the iteration manager who can address slowness ("John: you reported 2 hours left yesterday morning and today you're still not done... what's up?"
• The aggregate burn-down should show you how close you are to your target on a daily basis

My issues with this approach:

• Tasks become the center of the reporting universe within the sprint and so progress against task completion may mask poor progress against story completion (e.g. due to undiscovered tasks)
• Team "feels" progress based on completed tasks, rather than on the real objective: completed stories
• Weird reward structures get created ("John - yesterday you said you had 12 hours remaining on the task, yet you finished it. Great job!")
• Weird negative feedback is inferred ("John - yesterday you said you had 2 hours left and you're not done yet": inference - you're not working hard enough)
• Daily reporting requirements implies distrust of the team to raise issues or problem: "If I don't keep an eye on the task level reporting, I can't hold them responsible on a daily basis"
• Estimating iteration capacity based on ideal task hours may conflict with iteration capacity planning based on historical velocity. What happens if my hour capacity is reached in the IPM, yet my booked story point total is below my historical velocity? (I'll save the tendency for re-estimation for another blog entry). Reminds me of the old adage - experienced sailors never go to sea with two compasses. They go with one or with three, because if the two disagree, you have no idea which one is right.
  

I feel that task breakdown should be done only in limited circumstances and only to the degree where the benefit outweighs the admin cost:

• if the team feels that the benefit outweighs the cost
• if a developer or pair needs to break the story down into tasks in order to understand the work to be done, go for it (but don't worry about tracking all the details in a tool)
• Perhaps if your team is not mature enough to understand how to break down a story into tasks, and so you must spoon feed them with tasks (even then, I think it better to have them pair with experienced developers to learn how to become self-sufficient.)
• If the tasks to implement a story can be parallelized (different developers or pairs can be working on different tasks for the same story in parallel)
• If your team has "silo dysfunction" that requires choosing stories that don't overload a skill or domain area on the team

Example: let's say you have a project with equal parts C++, Java, and Fortran code and you have C++, Java, and Fortran programmers who can't span technologies. In order to keep from overloading one technology group, you must choose stories that balance the work across those silos. Sometimes, the only way to create this balance is to task out the work across technologies, to ensure you're not overloading one camp.
By the way - removal of this dysfunction over time is recommended.

My feeling: Using the whole team's time in the IPM doing task breakdown and estimating tasks is usually wasteful. I recommend that task breakdown be undertaken, if necessary, at the last responsible moment... when the story moves from "ready" to "in development", rather than at the IPM. The developer or pair picking up the story should do the breakdown.

Task breakdown smells (and yes, I've seen them all):

• The tasks look like this:

Design the code
Write the code
Write the unit tests
QA the code

Why is this an issue? You're probably doing mini-waterfalls, not simple, evolutionary design

• The "remaining work" for a given task is reduced by 8 hours (or perhaps 6) each day

Why is this an issue? Team members are not providing real data, they're telling the iteration manager what he/she wants to hear

• The hour-based iteration burn-down (or, as I prefer, burn-up) is practically a straight line.

Why is this an issue? In reality, many things take more or less time than imagined. Straight lines are an indicator of "cooking the books"

• The iteration manager asks people throughout the day... "How many hours do you have left on this task? When will you be done?"

Why is this an issue? It's command and control leadership and dilutes the power of the self-directed team.

• Iteration Planning Meetings (IPM's) take more than an hour and are more about numbers than about story understanding

Why is this an issue? You spend more time taking swags at hour estimates than you do actually thinking about the functionality to deliver

• The iteration manager applauds the team for accomplishing "400 hours" when their calculated capacity was only "350".

Why is this an issue? It's focused on task hour accounting and doesn't imply anything about how successful the team was at completing stories

I've worked on projects with both approaches - task breakdown with hour-based burn charts and no-breakdown with point-based burn charts. My suggestion is to avoid speculation about the superiority of doing it the only way you've ever done it and at least give each approach a fair shot.

I remember my elevated caffeine intake as a developer at interminable IPM's where I just wanted to get on with the work.

I remember debating minutia about whether a task belongs or not, and whether it's 8 hours (by Kurman) or 16 hours (by someone else). Yes - all those issues that the point-level estimating deigns to abstract by using relative estimates can rear their ugly heads in hour-based estimating. (By the way - if your solution is to assign the tasks at IPM time, you'll suffer from other problems).

I remember being the first to pick up a story as a developer and finding a better approach that implied a totally different task breakdown. Yes, I used the new approach, and yes I had to fix the accounting (XPlanner) to reflect my new approach. (Umm... on second thought - I just left the existing task list in place and fudged the actual hours into the old list. You might think this was wrong. I knew, however, in my heart of hearts, that the micro-accounting really didn't matter).

I've also worked with teams that have eliminated task breakdown/estimates and felt freed by the defenestration of the bureaucracy.

This tends to become a heated topic of conversation. In the end, the best answer, I think, is to let the team choose the approach that's right for them. Mandating task breakdown or mandating against it is almost always wrong. Drive the questioning to determine if task breakdown adds value or not, and try it both ways. If you have an agile management tool that requires tasks in order to do reporting, and you want to avoid defining tasks, just create one task per story that says "Do it". (In parallel, find a different tool that provides more flexibility).

scrum terminology decoder:
iteration = sprint
iteration planning meeting or IPM = sprint planning meeting
iteration manager = scrum master
iteration showcase = sprint review = sprint demo
master story list = product backlog (or possibly release backlog)

PMO vs. PPM

I have a visceral negative reaction to the PMO initialism; it stands for Project Management Office. I recently pounced (in an overreacting sort of way) on a colleague who was using this term. Sorry Carl.

I need to explain a bit. It's really all about the "O" - for Office.

"Project Management Office" screams bureaucracy to me. I've never seen an efficient and effective PMO. This is perhaps because most of them seem to be mired in "SDLC" - an oft-used euphemism for "waterfall" (despite it's innocuous spelled out translation: software development life cycle).

I once had to sign off on a 19-page document provided by the PMO to justify the acquisition of two load balancers for a test environment. This document had to be signed by 25 people in a 2000-person company. It was a stunning example of the need to feed the process beast. Some project manager in the PMO - who probably thought this process was necessary - filled out this template. My favorite section of the doc was "Metrics". Ostensibly this section existed to establish the metrics upon which the success of this project would be measured. The PM filling it out, indicated that 2 load balancers would be acquired - as if the number "2" satisfied whatever the template providers had in mind for metrics.

If we want to revamp the bureaucratic, inefficient, ineffective approach currently used for managing software project portfolios (the PMO), I think we need a departure from the term.

I'd love for us to agree to focus on the verb - not the noun. A brief digression:

I see many agile teams who use the iteration planning meeting - IPM - or the "sprint planning meeting" if you subscribe to that religion - as the only time in which the development team is exposed to upcoming work (other than, perhaps, estimation efforts that occurred months ago). I coach teams to treat iteration planning as a "verb": planning - rather than a noun: meeting. The "planning" should occur fluidly - some done in meetings before the IPM (e.g. estimation), some after (e.g. task breakdown).

Project portfolio management (the PPM in the title of this post) implies active engagement in assessing the health of the portfolio. The estimated release date or feature list should be adjusted after every iteration, and approaches need to be introduced to raise awareness of the new projections at least this often.

Let's please talk of project portfolio management, rather than project management offices.

97 Things Every Project Manager Should Know

The book "97 Things Every Project Manager Should Know" has just been published. I have two contributions: "Use a wiki" and "It's the People Stupid". Get 30% off by entering the code ABF09 on the oreilly.com site.

Linked-In grammar issues

John Doe "has added new links and updated their profile"

John Doe is an individual. "Their" is plural. I understand they're trying to avoid "his or her", but I'd prefer it.

Another example... when someone requests an endorsement, the message comes across as "Can you endorse me?".

The word "can" implies ability to do something, not willingness. I'd much prefer to see "Would you endorse me".

There. It's off my chest now.

Why Blog?

I recently had an extended conversation with a group of about 10 folks who lamented the poor understanding of the value their particular functional role brings to a software development team.

One question I posed: how many of you blog on the topic of your profession? The answer was zero.

Why don't they blog? Here is my interpretation of the reasons for not blogging:

• Not enough time - working 40 to 50 hours per week leaves little extra time to spend composing and presenting ideas in a professional manner, much less having a reasonable social life.
  
• Lack of original ideas - there's not much I can think of to write about that hasn't already been addressed somewhere - whether in another blog, in a book, or in conference presentations.
  
• Confidentiality - many of the examples from my work are proprietary; obfuscating the details takes time and can cause loss of message fidelity.
  
• Low readership - the effort to reach a small number of readers, given the size of the blogosphere, has a low RROI (readership return on investment?)
  

My blogging is sporadic. I understand the effort required to wrap ideas in a digestable format. I also edit articles for an online IT journal (alphaITJournal.com). Editing is hard work. Blogging doesn't require the depth of perfection that articles do.

Sometimes you're better off taking a stab at it and clarifying the concept through further blog entries than simply waiting to start.

Who reads my blog? According to Google Analytics - about 15 - 30 people. That's the volume of hits I generally get with a new post. It's not much, but size isn't everything. Every once in a while a link to your post will get posted to an aggregate someplace (digg, reddit, Developer Zone, etc.) and will generate more traffic and conversation.

The benefits to blogging:

• Personal brand promotion. As your blog is read by others, your personal brand improves.
  
• Clarifying thoughts. Organizing and writing about a topic forces you to develop clarity on your topic.
  
• An idea portfolio. When you apply for new jobs or try to sell to new clients, your blog serves as a portfolio of your ideas and promotes your depth of thinking on your profession. It also serves to show off your communication skills.
  
• Writing skills. Most of us need to communicate through the written word in our lives. Blogging is great practice.
  

Here's a technique I use to generate blog entries. Whenever I get an insight or a flash, I start a blog entry in a text file. Sometimes it's just a thought (one file - pragmatism.txt - has the following: "Pragmatism vs. agile").

When I have down time (waiting in the airport, sitting on a plane), I take a look at my partials and figure out what I'm in the mood to explore. I happen to be on a plane as I type this.

Your topics will rarely be entirely original. What will be original, however, is how you shape your message with your unique perspective and background. Combining this uniqueness with the topic at hand is what renders insight.

Low readership is not an issue. The benefits of clarifying your thoughts, having an idea portfolio, and improving writing skills are all independent of the size of readership.

So go ahead and start. Create a blog and type "Hello World". You may be surprised at how the ideas start flowing. Start recording things you want to explore ... and start blogging !

Uncle Sam Industrial Average

With GM and Citigroup being removed from the Dow Jones Industrial Average stock index, it occurs to me that we need a new index to track the health of government owned/quasi-owned companies. We should be able to come up with 30 by now, no?

I propose the Uncle Sam Industrial Average (USIA).

Jump in

“It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood, who strives valiantly; who errs and comes short again and again; because there is not effort without error and shortcomings; but who does actually strive to do the deed; who knows the great enthusiasm, the great devotion, who spends himself in a worthy cause, who at the best knows in the end the triumph of high achievement and who at the worst, if he fails, at least he fails while daring greatly. So that his place shall never be with those cold and timid souls who know neither victory nor defeat.”

- Teddy Roosevelt

XP Game redux

I assisted in another XP game with legos last Tuesday - led by my ThoughtWorks colleague Conrad Benham. Several other ThoughtWorks folks helped to facilitate. We did this at the Atlanta Agile User Group meeting. Kris Kemper captured some of the activity in his blog post. Another participant captured his perspective here. I particularly like his comment "I was stunned at how many real world challenges our team of 5 mirrored". I'm always pleasantly surprised at how effective these games are at conveying agile concepts

I facilitated one of these last year at a Florida .NET user group meeting which was captured in the Apress website in their content area that brings attention to various user groups.

If you have a desire to introduce agile concepts to an audience in a fun setting, you can't go wrong with an XP Game with Legos.

Euphemism in Podictionary

I previously posted a blog entry on Dysphemism and cross-register synonyms. I sent an email to the guy who runs Podictionary - the podcast for word lovers, suggesting he use dysphemism in one of his podcasts.

Well, he did. Kind of. He used euphemism and mentioned dsyphemism. Check out the post here.

ThoughtWorks is seeking developers

From Dice:

Title: Experienced Java, .NET, Ruby Developers with Agile exp. - Chicago
Skills: Strong technical skills and Agile best practices
Date: 3-11-2009

Description:
Isn't it about time you joined a company that really values your contribution? A company that is synonymous with innovation in the technical world? A company that is passionate about collaboration? Add to this our focus on Agile delivery and you'll start to see why working here is refreshingly different.

Welcome to ThoughtWorks!

We're looking for experienced Java, .NET and Ruby Developers

If you would like to:
* Use the latest tools and techniques (currently Ruby, Java, .NET, Agile Methodologies, Web Services...)
* Drive the design and construction of a client's complex business problems into innovative technology solutions
* Be a hands-on coder and proactively mentor developers and client (including pair programming)
* Travel to work at client sites Monday through Friday

And you have...
* At least 6 years of experience combining design, development and implementation of large-scale systems and large web applications
* Strong development experience with OO languages such as Java and .NET
* Strong knowledge of design patterns, refactoring and unit testing
* Working experience in Agile development best practices
* Excellent written and oral communication skills


80% domestic travel is required.

Our US offices are located in Atlanta, Chicago, New York, and San Francisco. Relocation is necessary if you do not live in one of these cities.

ThoughtWorks values aptitude, attitude and integrity.

We invite full participation from all of our people through a non-hierarchical organizational structure and open, honest and transparent work environment.

If you thrive on challenge, unlimited possibilities and unparalleled learning send your resume to work@thoughtworks.com or apply online now.

Thoughtworks, Inc.
200 East Randolph St
25th Floor
Chicago, IL 60601
Phone: (312) 373-1000
Fax: (312) 373-1001
Web: http://www.thoughtworks.com

Iron Chef Retrospectives

I like cooking analogies to software. Lachlan Heasman recently posted a comparison between Iron Chef and scrum iterations. One missing component was the retrospective. It occurred to me that the chefs must do some sort of retrospective and that it would be interesting to see on TV. So I penned the following to Food Network this morning:

I'm a software engineer and a die-hard Food Network fan. I often use cooking analogies when coaching other software professionals on how to improve their approach to software development. Mise en place is one of my favorites.

I recently encountered a comparison of the Iron Chef competition to software development. One of the components of our approach in software is to use "retrospectives" to look back upon the iteration of software development we have completed to improve how we do things. We revisit what went well, what didn't go well and adapt our approach to learn from our mistakes

It occurred to me that the Iron Chef competitors must do "retrospectives" as well. I can imagine Cat Cora sitting around a table with her chefs over shots of Ouzo dissecting the completed competition and finding reasons to celebrate and opportunities for improvement.

I think it would be fantastic to have a postscript TV show to film the two teams in their analysis of the competition. You could intersperse clips from the actual competition when chefs refer to certain activities. It would also be interesting to hear what the chefs *really* think about the comments from the judges and how they might change what they did based on those comments.

XP Game

In June of last year, I facilitated an XP Game (using Legos) for the South Florida .NET user group. We had ~30 participants. Dave Noderer captured some of the excitement on video

Iteration Length

What's the right iteration length?

In Scrum, the recommendation is to start with thirty calendar days. From the Schwaber/Beetle book: section 3.6.3 Sprint Mechanics:

"Sprints last for 30 calendar days" and "thirty days is an excellent compromise between competing pressures". Though "Adustments can be made to the duration after everyone has more experience with Scrum".

My first reaction to the number 30 is that this is a nonstarter. What happens when your sprint boundary occurs on a weekend? How do you schedule sprint transition meetings? I know of no calendaring program that schedules meetings "every 30 days". Monthly? Yes. Every n weeks? Yes. But not every 30 days. The organizations I know that have implemented scrum by the book have scheduled n-week sprints, in order to maintain a consistency of scheduling (e.g. Wednesday afternoons are for sprint reviews).

Many novice scrum practioners resort to quoting "the book" when arguing for 30-day, by which they mean quad-weekly (which I will hereafter refer to as monthly for terseness) sprints. Suggestions to shorten sprints (e.g. to 2-weeks) yield objections along the lines of "with twice the meetings, we'll have less time to get work done. We already spend two days in our sprint transition meetings"

First of all, if the team is spending two days on monthly sprint transition activities, something is very seriously wrong. Really.

Sprint reviews (or showcases in the more generally accepted agile lingo) are about showing working software. They should not be about burn-ups and burn-downs and justifying the team's existence. You should never find yourself in a showcase/sprint review talking about the percentage completion of a story. Show the working stuff or sit down.

If you follow this pattern, the showcase/sprint review length should be proportional to the length of the iteration. If your iteration length is cut in half, your showcase should take half the time. After all, you're only showcasing half the functionality! (OK... maybe it's not exactly half. I would argue that two week sprints are more productive than monthly.)

Iteration planning should be a no-brainer. Preparation for the sprint planning meeting is on the business analysts, product owner, scrum master, project manager... everything should be pretty well layed out in advance. It should take no longer than an hour to do an IPM (iteration planning meeting). Unless, of course, you feel that task breakdown is necessary during the IPM (another Scrum approach with which I generally disagree). In any case, the IPM length should be proportional to the length of the iteration.

-begin sarcasm- How 'bout a 3-week iteration? Wouldn't that be a reasonable compromise? -end sarcasm-

Sprintly Retrospectives are another issue. Can you halve the time spent in retrospectives if you halve the iteration length? Probably not. But this, I feel, is not the right question. Are you getting value out of your retrospectives? If not, figure out how to get value. You don't necessarily need all the typical pomp and circumstance of a full-blown retrospective to impart the "adapt" portion of the "Inspect and Adapt" mantra. Too many teams, in my experience, adhere to the scheduling and process of retrospectives without digging deeply into different ways of adapting the team's approach to being effective and efficient.

More advanced teams can consider whether iteration ceremony is even necessary. A more lean approach would be to consider the flow of the work and to simply feed work into the development "machine" at a rate at which it consumes the work. "Inspect and adapt" would be continuous; retrospectives would focus on specific issues or areas of concern (rather than specific time periods across which many different kinds of issues may require attention). Classic iteration planning would yield to on-demand prioritization and estimation exercises - delayed to the last responsible moment. Reviews of completed functionality would be scheduled on demand for individual stories and perhaps with more ceremony when a critical mass of functionality has been completed.

What's the right iteration length for you? My recommendation is 12 days, 6 hours, and 24 minutes. (Oops... forgot the sarcasm tag)

Developing Extreme Talent

Thanks to Jason Yip's blog entry: On chess grandmasters and the expert mind for pointing me to this fascinating article - The Expert Mind: Studies of the mental processes of chess grandmasters have revealed clues to how people become experts in other fields as well - from Scientific American.

From the Scientific American article:

"K. Anders Ericsson of Florida State University argues that what matters [toward improving one's chess playing skill] is not experience per se but "effortful study," which entails continually tackling challenges that lie just beyond one's competence. That is why it is possible for enthusiasts to spend tens of thousands of hours playing chess or golf or a musical instrument without ever advancing beyond the amateur level and why a properly trained student can overtake them in a relatively short time. It is interesting to note that time spent playing chess, even in tournaments, appears to contribute less than such study to a player's progress; the main training value of such games is to point up weaknesses for future study."

The concept of effortful study essentially suggests that you grow only when you push yourself. As a very-practiced and accomplished pool player (before I had a family and other commitments), I know that I only improved when I played better players. Seeing this article expanded my thinking on the topic into other areas... such as programming talent and general education (I have four young children).

"The preponderance of psychological evidence indicates that experts are made, not born. What is more, the demonstrated ability to turn a child quickly into an expert--in chess, music and a host of other subjects--sets a clear challenge before the schools."

This points to difficulties in making our educational system effective: teachers who are responsible for 15 or 20 students cannot possibly tailor the education to push the envelope for each child. Even with five children, a common lesson plan loses the ability to maintain that tension between comfort and discomfort that leads to the kind of discovery that keeps up with a student's need to push forward. This is precisely why parental involvement is necessary ... to maintain that tension and to challenge our children - not just in maintaining the necessarily dictated classroom pace, but in tapping into the wellspring of talent and desire living within our children. I see it so clearly now.

"Laszlo Polgar, an educator in Hungary, homeschooled his three daughters in chess, assigning as much as six hours of work a day, producing one international master and two grandmasters--the strongest chess-playing siblings in history. The youngest Polgar, 30-year-old Judit, is now ranked 14th in the world."

Perhaps Laszlo's ability to adapt the level of effort required for each child helped. I'm interested in learning more about how much of his lesson plans were chess oriented and how much were geared towards general education. There's also the genetics argument; if he was good at chess, perhaps he passed on the chess genes.

"[...] success builds on success, because each accomplishment can strengthen a child's motivation. A 1999 study of professional soccer players from several countries showed that they were much more likely than the general population to have been born at a time of year that would have dictated their enrollment in youth soccer leagues at ages older than the average. In their early years, these children would have enjoyed a substantial advantage in size and strength when playing soccer with their teammates. Because the larger, more agile children would get more opportunities to handle the ball, they would score more often, and their success at the game would motivate them to become even better."

This argument for driving towards early success is somewhat orthogonal to the "effortful study" thesis, but bears import to the parenting issue (and perhaps the programmer development issue as well). Positive reinforcement and successful results early-on can provide the confidence that children and programmers need to continue pushing forward.

If you are a parent, or a mentor of a young programmer (or any other professional I would think), these concepts bear consideration.

Non functional requirements - a tale of two cities

I've been thinking about non-functional requirements lately. Ilities, some might say. It occurred to me that there are two classes of non-functional requirements: those that are visible to the user and those that are hidden.

Performance and usability are examples of non-functional attributes of the application that are visible to the user. I classify these as being "in front of the curtain"... or "part of the performance" (to use theatrical terms). Though attention to these issues is sometimes delayed to the end of the release, they occupy a high level of importance in delivery priorities.

Other non-functional requirements are backstage, and pretty much lead to efficiencies (or inefficiencies) for the development team. Examples include testability, supportability, maintainability and extensibility. These non-visible requirements bleed into visibility in some sense... for example, extensibility problems lead to delays in releases which impact follow-on release timelineness; poor testability leads to gaps in test coverage, which leads to bugs. But the impact of these issues often occurs long after the "current administration" has moved on.

I suggest that the order of priorities can be interpreted as 1) functionality, 2) speed of delivery, 3) visible non-functional requirements, and 97) non-visible non-functional requirements. Speed of delivery takes precedence.

Beware the "speed smell": sacrifices at the alter of speed, to the detriment of long term health of the system. In particular, beware these sacrifices being made by an administration that is poised to move on.

Good programmers: nature or nurture?

From where do good programmers sprout? Do they come from top-notch collegiate computer science programs? Do they stem from a gene correlated with good problem-solving abilities and ability to think in higher level abstractions? Where does the balance lie between nature and nurture?

There's a difference here between good programmers and simply competent programmers. Competent programmers are good at coloring between the lines. Good programmers are good at defining where those lines belong, understanding when the lines need to move and when coloring outside the lines is appropriate. They could be good architects, but choose not to lose their relevancy by moving from code to box diagrams.

I don't know where good programmers come from. I have some observations though.

A college degree is not necessary. I'm not saying it's not useful, just that it's not necessary.

Curiosity is necessary. A BS in Computer Science with on the job training in programming and domain, but with no curiosity, will last a graduate 2-3 years, after which s/he will professionally stagnate. This mode is fine in a stable economy where these programmers can amass domain or technology knowledge with their current employer and become domain-sticky (e.g. the few who know why the business rules are structured as they are) or technology-sticky (the few who have been with the code base so long as to know the nooks and crannies of obtuse design and coding decisions). Lack of curiousity and experimentation - in learning new domains and skills - significantly reduces the shelf life of non-curious developers. In the current economy, this domain and technology stickiness are no longer sufficient safety nets to protect your jobs.

You don't have the time to address your curiosity? Make time. Many licensed professionals (e.g. medical professionals) require continuing education in order to keep their licenses. Software development professionals should have even higher requirements; our profession changes very quickly. Even if your employer doesn't have the budget to send you off to a conference, you should be able to negotiate some set-aside time to focus on sharpening the saw. Or spring for that conference attendance cost yourself if your company is unwilling to invest in you (and update your resume while on the plane). You should also be able to answer the question in an interview - "how do you keep your skills current?".

In the coming technology landscape: meta-programming, crossing-the-chasm from statically typed object-oriented languages to dynamic and functional languages, and solving more and more complex business problems requires more than just a basic understanding of Java and the list of standard Java-based acronyms. Beyond curiosity, the new landscape requires discipline (to understand before coding - and to keep from strangling yourself with the new rope that these new technologies provide). It requires persistence in teasing out the subtleties of the new technologies to fully understand them. It requires an ability to think in more abstract terms... in some ways, it requires returning to the Computer Science textbooks.

In sum - to improve your programming skills, cultivate and follow your curiousity, think more deeply about how to solve the problems at hand, try some of the newer (sic) languages (F#, Haskell, Lisp, Ruby, etc.) and practice thinking in more abstract terms. Be persistent. And find a smart, curious, thoughtful, persistent programmer who takes keeping his/her skills sharp seriously. Pair with him/her. Ask questions. Become a sponge.

John Doe, MBA, PMP, EIEIO

Just ran across a profile of an ex-colleague who had abbreviations following his name on a networking site.

We should all be proud of our educational accomplishments and certifications, and they certainly hold a place in the job-search process. But I find the addition of these attributes to be out of place in many environments (e.g. Linked-In, Facebook, and resume titles).

Joe Schmo, HS Grad, BSCS, MBA, PMP, CSM, MCSP, MCP, NCP

Let's remove the certification crutches and talk about what you're doing and how you add value.

- Cranky

defenestration hotel ads

Looked up defenestration on the web (dictionary.com) in order to provide the link to someone. I found the ads an interesting mix.



I can understand ads for hotels in Prague, given the defenestration of Prague, but I'm curious about any heretofore unreported defenestrations in Orlando.

Peeling potatoes

I had an interesting conversation with an enlightened product manager recently. We love to converse in analogies, and a recent one surrounded the difficulty of completing the required scope of our release plan in the timeframe allotted. So, out sprung the analogy... trying to fit 10 pounds of potatoes into a one-pound [capacity] bag.

The extension to the analogy is that peeling the potatoes to make them fit is an insufficient approach. It may be appealing in the sense that you're making progress, but the order of magnitude difference required to make the potatoes fit will never be satisfied by a peeling approach.

A similar analogy might be suggesting to folks on the Titanic that they pick up a bucket and start bailing.

When great change is needed, great courage is required to make game-changing differences in approach. Otherwise, you're just postponing your date of failure.

Path to Passion

I had an interesting dialog with a colleague recently. He left a long, multi-year consulting stint a few months ago to join a start-up in Silicon Valley. He's absolutely loving it. The excitement and passion are prominently on his sleeve.

Many of us have probably felt this excitement on certain jobs or certain assignments. A year ago I had a job/assignment where, on occasion, I would wake up on a weekend, think about getting ready for work, and feel disappointment upon the realization that it was not a work day. What a wonderful sensation. I've worked on other projects where I've felt similar passion.

Of course, I have also been in jobs where I've been so sapped of energy and enthusiasm that it seems, in hindsight, that I simply marched like a lemming in the proposed direction. I remember trying to change things and meeting more resistance than I could surmount, and then, sad to say, submitting. I was professionally... dead. I can blame it on my youth I suppose. The last time I can recall being severely numb was around '94 or '95. I never wish to experience that again. More to the point, I will never allow that to happen again.

As a consultant, I get to spend time with different companies of different sizes in different industries. I really enjoy the work - particularly in the first month or two as I learn about the client, domain, people, challenges, and ... opportunities. As I spend time in these new places, I find some people who are passionate about what they are trying to achieve. This always gives me hope; it is typically these people to whom I gravitate. But I also see many who seem to be marching or strolling along, without passion, desire, or commitment. I find this frustrating.

Of course, we don't all have to draw deep satisfaction from our work; other priorities can make up for the lack career excitement. But here's the thing... if you have to spend 40 hours a week doing something that doesn't get your motor running, why not find something that does? It doesn't necessarily mean you quit your job for another, but at least make progress towards that other thing that excites you. If you're a musician and would rather be playing in a rock band than doing corporate tax returns, practice, go out and meet other rockers, attend open mike nights, etc. Make some progress.

Don't accept a job you're not passionate about unless you can find a path to passion. And if you're in a job with no path to passion... snap out of it man !