Monday, January 26, 2009

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.

Thursday, January 22, 2009

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.

Wednesday, January 21, 2009

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

Friday, January 16, 2009

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.

Tuesday, January 06, 2009

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.

Thursday, January 01, 2009

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 !

Monday, December 22, 2008

Wanted: Software Development Leader

One thing led to another and there I was contemplating the job req for what I would look for in (and what I strive to be as) a software development leader.

Experience:
- Development experience - preferably within the last decade

Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application

Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate

Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team

Ah... it's late. that's as far as I got. I felt like the integrity section was short, but many of the integrity issues bled into attitude. What did I miss? What do you disagree with?

Sunday, December 21, 2008

Dysphemism and cross register synonyms

I love learning new words. During a conversation in our open-space collaborative software development team environment last week, I used the term euphemism incorrectly. Thanks to Steve Moyer for pointing out the error of my ways.

Apparently, the subtlety is that a euphemism substitutes a less harsh term for another term. I can't remember what I said, but it was akin to saying "The head" was a euphemism for a restroom. Since "The Head" is harsher, it was not a euphemism, but a dysphemism.

Had I said that "Powder Room" was a euphemism for "The Head", I would have been correct in my usage.

By the way, these two terms are considered cross-register synonyms. Cross-register synonyms vary across some orthogonal degree on their subject. For example - dysphemism and euphemism are cross-register synonyms that vary in their degree of harshness. I found a good description of this particular cross register synonym and cross register synonyms in general here: http://www.linguistics.ucsb.edu/faculty/cumming/ling50/euphemism+dysphemism.htm.

Saturday, December 13, 2008

Agile Pants

I found these "Puma Agile Pants" when doing a search on Amazon for agile literature:



Agile Pants... don't pair without a pair.

Friday, December 12, 2008

Test Lookup

Kris Kemper has a nice blog entry on finding tests related to code you are changing that lines up well with a concept I've been pondering today.

I have a colleague who asked me to look over a rather large C# software system, made up of many (>20) .NET projects. In the best agile way, he is relying on his elegant structure and well-named/concise tests to serve as the documentation for anyone who might try to understand the code.

Being self-aware, my colleague understands that he is too close to the subject to be able to determine "understandability" of the code by others. So he asked me - an outsider - to take a look. I think he was also hoping that if I - as a supposedly post-technical project manager - could understand it then he could brag that his code was so understandable that "even a PM can understand it". (Reminds me of those old Life cereal commercial where Mikey, who never likes anything, likes the cereal and his siblings declare "Even Mikey likes it !")

So I picked a class at random. Nice short methods, but reading the code didn't give me as much insight as I hoped. Then I thought... ah the tests. I'll read the tests. So I right clicked, searched for usages, and navigated to the location that had "unittests" in the name. Then I thought - wouldn't it be nice if I could right click on a method name, or a class name, and - instead of asking for usages - I could ask for tests.

That got me to thinking - what would constitute a test? A unit test that simply invokes a method or instantiates a class may just be using it for setup or for supporting scaffolding. But then wouldn't that be a smell? Shouldn't that irrelevant setup junk be in a setup, or injected or...

Anyway, Kris gets to much of these points... my main extending thought is simply - wouldn't it be nice if the tools could help us navigate to tests and sniff out those smells (rather than force them by removing the method, as Kris's technique suggests)?

Monday, December 08, 2008

Halftime

In American football, the game is divided into four 15-minute quarters. There's a short break between the first/second quarters and then between the third/fourth quarters, but the middle transition is longer. It's called halftime.

During halftime, teams return to their locker rooms for respite, but more importantly, coaches use it as an opportunity to adjust the game plan and motivate the team.

Much is made of the halftime break in football. I think the concept is equally useful in ... agile software development.

I introduced halftime on a couple of agile software development teams to step back and look at iteration (or sprint) goals at the midpoint of the iteration, to see where we stand, and adjust our approach. It has been a good opportunity to refocus, adjust sprint content, and address issues.

In a recent halftime, I pointed out that the scope for the iteration was 63, and that we had burned up 20 points. I used the analogy that our opponents had 63 points and we had 20 and that we need to figure out how to make up the difference. We adjusted our approach, removed some scope and went on.

If you're stuck in a project where the iterations are too long (e.g. four weeks), suggest introducing a short halftime (30 minutes) to refocus the team and adjust. Even if you're in 2-week sprints, doing a checkpoint/halftime at mid-iteration can be useful. It's also a good segue into shorter iterations.

Tuesday, October 28, 2008

Is it ever NOT what it is?

The phrase "It is what it is" bugs me. It falls into the category that includes phrases/clauses like "Going forward..." (as if you could go backward) or "To be honest" (an admission that what you're about to say is a departure from the norm).

I just heard a new one in the concierge lounge at a Marriott: "It'll be what it'll be". I think it was related to sports.

So, here are some suggested enhancements to the dialect:

* It won't be what it won't be
* It will never be what it never could become
* What wasn't, wasn't
* To be or to be, that is the [rhetorical] question
* It probably wasn't meant to be because it wasn't meant to be

I'm sure there are more clever opportunities here.

Saturday, October 04, 2008

Agile adoption by geography

I wonder if there is a geographical distribution to the adoption of agile philosophies. To find out, I used Dice's job listings as a proxy to determine percent of postings that matched the word "agile" by City.

Suprising to me, Salt Lake City seemed to take the honors @ 12%. Next tier: Richmond, Seattle, Portland, OR, San Fran, Denver, Austin, Raleigh, all between 5% and 9%. The remainder can be seen on the graph. It's probably a bit too small to see, but if you display it individually, you should be able to clearly see the list of cities and the rough placing of the cities within the distribution.

Results:

Thursday, September 11, 2008

Open Command Window Here

I spend a great deal of time at a command prompt on my Windows system. I recently found a a nice little Windows XP PowerToy that allows you to right click on a folder within windows explorer and then click a menu item to open a command prompt with the directory set to the folder you right-clicked on. How did I live without this for so many years?

Go to http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx and download the "Open Command Window Here" power toy. (I actually did it by hacking the registry, but avoiding regedit is good practice).

Thursday, September 04, 2008

Linked In Recommendations

To what extent do you think your Linked In recommendations of others, and others' recommendations of you reflects on you?

An old colleague requests a recommendation - you kind of know him/her, but not well. Or maybe you know him/her, but don't respect his/her work. Do you recommend? An incompetent ex-colleague offers a well-articulated recommendation for you. Do you accept?

NO !

Don't do it.

Maintain a high bar for your recommendations so that they mean something. Turn down requests for recommendations for anyone who you wouldn't hire yourself - into your own department, or, better, into your own company. I think the latter is a pretty good rule of thumb.

Don't accept recommendations from people who you would not recommend yourself. The volume of recommendations is not important; it's the quality - both from how well they are articulated and from the standards of the source of the recommendation.

I was thinking at one point of asking someone for a recommendation. This person has a title that would have made for an impressive recommendation. Then I saw that she recommended a person for whom I did not have high regard. I decided against asking. Why? My recommendation would have been devalued by the other recommendation. Granted - not many others would have known or understood... but... I would have known. And others' may have learned.

I want to be recommended only by people for whom I have the highest regard and who I would have no hesitation recommending.

And I want to be recommended by folks who have recommended others who have achieved a high bar of performance.

And I insist on only recommending those who I feel I can honestly promote - based on my interactions and experience.

You too, should maintain high standards in your approach to recommendations.

Thursday, June 19, 2008

Interesting question on LinkedIn:

What is the difference between an approach and a methodology?

What is the difference between an approach and a methodology?
Is it true that approach is just an idea and is less proven while methodology would normally start as an approach but is eventually time tested and proven? What takes an approach to convert into a methodology?


Here was my response:

I think of an approach as the foundation, or underlying principles that guide you in how you get your work done. I'm an agile software development proponent, and I strongly support the approach/philosophy expressed in the agile manifesto (http://www.agilemanifesto.org).

Methodologies, to me, prescribe more detailed steps to take to accomplish goals. Scrum is, in essence, an agile approach (the mantra is "inspect and adapt"), but it gets applied in many instances as a methodology (Though shalt provide a burn-down chart).

Methodologies excuse people from thinking about underlying principles. If you follow the rules for making a burndown chart, your methodology has been followed, but if you are avoiding opportunities to gain greater insight by taking a different tack, you are avoiding the approach/principles.

An analogy to cooking - using a methodology is like following a recipe - with your measuring spoons/cups at hand, precise temperature measurements, etc. Using an approach/principle requires more understanding of the ideas... the fact that sauteeing onions releases liquid gives you some information that allows you to adjust to other aspects of your cooking (like don't try to brown your meat while sweating your onions, because the released liquid will cause your meat to steam instead of brown).

In sum, I would say an approach requires more thinking and adapting, while a methodology provides more training wheels to give you procedures that you may not be able to link to the underlying approach/principles. I think that beginners require methodologies (like beginning cooks require recipes) while experienced folks can apply fundamental principles based on sound judgment (like experienced cooks simply press down on the steak to assess doneness instead of measuring the time).

Tuesday, June 17, 2008

XP Game in Fort Lauderdale

I facilitated a lego XP game for the Agile SIG of the Florida .Net user group at the Microsoft campus in Fort Lauderdale tonight - great fun ! Thanks to two of my colleagues from Bayview for playing the customer roles: Howard Sims (project manager/iteration manager) and Samir Patel (development manager).

Dave Noderer blogged in real time and took a video.

It's fun to watch adults get so engaged with legos.

Wednesday, May 28, 2008

28nd of the month

Received from Linked In at 12:10 am EST on May 29 (9:10pm May 28 in PT terms)

LinkedIn is currently unavailable while we make upgrades to improve our service to you. We’ll return around 9:30pm (PT) May 28nd, 2008.

We apologize for the inconvenience and appreciate your patience. Thank you for using LinkedIn!


The 28nd?

9:30 PT update: new message:

We’ll return around 9:45pm (PT) May 28th, 2008.


I like the noncommittal "Around" as a qualifier...

Thursday, May 15, 2008

A semi-clean, well-lit, open-place

These are a few pictures of my team room. I love this place - high ceilings (with plenty of space for information radiators), lots of card walls, lots of white boards, movable filing cabinets, and a few cubes for the stationary folks. This is really a retail space the size of which you could probably house a basketball court.

We had an open space in the front that isn't pictured with a couch, some beanbag chairs, a conference table, a projection screen with a projector. We almost never had to schedule meetings in the limited conference space in the main building again.



A good view of most of the card wall. This is fairly old - we now have flipcharts with our historic burnup charts posted over the card wall so we can see our trends.



This gives a good view of the dimensions of our space.



The little white box area in the back is a portable office - 10x10, with privacy for personal phone calls, personnel meetings, etc.