Strategies for Successful Development

Process and technology for small teams building real software

Archive for the ‘Opinion’ Category

Quick glance at Seesmic

Posted by S4SD (Seth Morris) on 2009/06/28

I’ve been told I’m too grumpy-pants lately 🙂 So here’s a quick non-rant with what is, I hope, constructive feedback for an app I think I might wind up liking in a few revs.

I asked @dariusdunlap what he was using to follow hashtag searches on Twitter, since Twitter itself is so horribly broken about them and he was so well on top of the Community Management Unconference happenings a few weeks ago. He recommended Seesmic Desktop (@askseesmic). So, I’ve been giving it a quick glance-over.

As always, I’m just hoping the developer (who seems far too nice and with-it to do this) comes back and says, indignantly, "That feature is is the product!" because I love quoting the lesson my friend Sarah taught me with an off-hand comment once that changed my whole understanding of product design, especially from my end of it with the coders: "If the user can’t find a feature, it isn’t in the product." But I suspect Team Seesmic is ahead of that already.


+ It’s worth a look if you need to follow search results regularly or if you want to separate people you follow into subsets for viewing purposes, both quite reasonable use cases most Twitter apps don’t support.

No thought to the interaction metaphor or user flow means you’ll be learning to work around how the designer thinks instead of how to get your job done and the technology it’s built on (Adobe AIR) is a famously least-common-denominator platform that will leave you reaching for common, everyday conveniences Windows added in the 90s.

= Integrates Facebook viewing into Twitter, but only for one Facebook account and it doesn’t really "get" the difference in Facebook use. It’s really just a view of some Facebook stuff in your Twitter feed, so it’s a nice-but-not-important feature in the current implementation


  • Great for watching one or two of N things at a time and switching which one or two at will
  • Bad for grazing content
  • Badly needs some help text. I think this is what I needed to know when I started, but nothing actually tells you how to use the app unless you want to spend time watching videos:
    • The nav bar and the column immediately to the right are the whole of the basic UI. Some columns will be pulled out and stacked to the right of the nav bar’s column; these are called "detached," but they are still attached.
    • The "Home" view is what all of your accounts can see, in one timeline
    • The @Replies view is a search on Twitter for all of your accounts (but does nothing for Facebook)
    • When you send a tweet, check which of the accounts it will send it through: you may be very surprised (and embarrassed!)
    • Searching via the search box makes a saved Twitter content search. Searching via the search tab of an account searches for a Twitter username.
    • Make a userlist and add people to it. Then exit the app and check that you did it the way it expected. When you have it right, it will begin aggregating new status updates from those people into that list. It is not a search function: it is a new, special bin for new items to be copied to.

Some nice stuff
  • Love the handling of text over the length limit (graying out text after the line and changing the chrome UI)
  • Userlists are quite nice. Well, they would be if they worked (if they worked as expected, but they’re pretty nice so far)
But, some major, major problems

(These are probably showstoppers for using Seesmic in any non-toy capacity at this stage, but it’s still very much in development)

  • No app should change what a user writes without explicit authorization: the default install converts urls via some url-hiding company. This needs to be opt-in.
  • If you have Facebook enabled, scrolling down the timeline is unusable. As you scroll, it downloads images which cause it to resize the cells you’ve scrolled past, making things on-screen jump down, off-screen. Basically, if you have Facebook installed, you shouldn’t try to scroll the timeline unless you scroll it all the way (by paging, not by jumping the thumb) and then walking away until every picture it passed has been loaded, then heading back up. It’s amazing to me how unusable this is. I wouldn’t have expected it (and clearly Seesmic’s creator didn’t either, although s/he could have tested it)
  • Adobe AIR is easy to code for and can be a lot of fun, but it really isn’t ready for end-user apps: AIR eschews interaction standards on the OS; instead it behaves like Adobe’s former Macromedia people think the universe should.

    Even if you agree with them, having Seesmic be the one app on your system where control-right takes you to the end of the word, rather than the beginning of the next word, means you have exactly one app where all text editing takes all of your attention and breaks all of your habits. Sadly, I can’t recommend using any AIR app that hasn’t been custom-built to your needs, since it’s going to be so broken in little ways you won’t feel until after you’ve paid for it.

Some details

Bad UI

(Some of these might be AIR’s fault, but I don’t think so. I haven’t written for AIR in about a year, though)

  • Can’t resize columns. Hope they’re at a size you like(they aren’t for me)
  • Can’t stack columns. Horrible for splitting out several things to watch at once
  • Can’t fill people into a userlist unless you have content from them
  • Creating a userlist doesn’t do back-searches, even if the content is already present. I made a userlist on Friday and it doesn’t aggregate content until people start tweeting on Monday. Stupid.
  • Scrolling is horrible as images get pulled in, moving what you’re reading around while you’re reading it

Definitely AIR problems:

(Seesmic touts AIR’s ability to run on multiple platforms, which is kind of nice, but it means, at least in this case, that the UI implementation sucks on them all—it’s the same reason any UI in Java1. Consistency with the platform is why we don’t have to spend all of our time remembering what keys do what and can instead complain about what happened when they did it. If it works exactly the same on a Mac, then those users are just as unhappy in different ways.)

  • Whole-word selection is inconsistent with the platform
  • Control-arrow behavior is inconsistent with the platform
  • Can’t resize window except at lower-right thumb
  • Context menu behavior odd and inconsistent
  • Mis-reports its frame size. Maximize it and it will spill over onto the next monitor
  • AIRs drop-down lists don’t behave much like Windows lists (well, they behave similarly, but they try not to look like it, leading to user confusion).

Broken Bits

  • I cannot find a single link to the Seesmic web site anywhere in the app
  • Defaulted to editing my tweet text and using without my approval. Editing my words should be opt-in!
    Note that I believe url hiding services are an evil that is rarely necessary.
  • No way to indicate that there new items in a search (this may be a feature request at some level, but it begs an interesting question: are searches polled or are they pulled on demand? the configuration UI implies that they are refreshed on demand…)
  • Need context menus on items in the left nav bar
  • Why does clicking a hashtag launch the web site instead of searching in the app?
  • Need to be able to size or hide the nav bar
  • YouTube videos are not a replacement for documentation. Ignore your ego, be willing to spend some actual effort writing words instead of code, and pen a few lines people can read (without devoting blocks of time and without needing audio) to decide whether to use your app and to learn how.
  • Sending a tweet seemed to send from two accounts at once when I didn’t expect it to. That’s an advanced use of the app, don’t make it so easy to blunder in to. Now that I know about it, I’m reasonably safe
    • As an aside, it says something that I assume the checkboxes on the account selector were a mistake and were meant to be radio buttons. The rest of the app is pretty clean, but that seemed like a likely mistake given the limitations of AIR, the stage of the product, and the general level of attention to detail in the interactions throughout the app.
  • Use of the X (standard meaning when on bar of icons affecting a window: close this window) to mean "delete the item that launched this window" is horrible. That it follows up with a task-interrupting modal dialog should be the clue that it’s bad design

    Let’s be more specific: here are the buttons on the title bar of a search frame:
    After the "refresh" button, we have 1) a trash can, 2) an X, and 3) a "go back (through the door)." Which one means "reset the data", which means "delete the search", and which means "close the window"? I’m betting on 99% of people getting it wrong the first time.

    And remember, every search frame will have all of those buttons forever, no matter how tired you are. Don’t ever click that X thinking it shuts the window…

  • Userlists remember that they are in "edit" mode far too much. Make editing a task, not a state.
  • Similarly, having "search for a person" be a state of an account means I can’t return to that account without cancelling the search and I can’t search for two accounts at once. This interaction model needs some thinking,
  • Button to enter edit mode on a userlist is nowhere near the buttons to end it. Very confusing, especially with the current bad IA around what editing means. Very easy to think you’ve renamed a list, but be wrong.
  • No feedback when refreshing
  • Adding a search us completely unlike adding anything else, but shouldn’t be. It’s one line of text, just like a new userlist, so it should have a plus sign on the nav bar

Missing features

  • Multiple Facebook accounts
  • Drag and drop to userlists (actually, dnd is missing everywhere)
  • # of new items by userlist and search (in the nav… the popup notification is nice but it doesn’t work well for "what’s new over lunch?") At least bold out the search if there have been new items since it was last active (showing in the special, left-most columns or showing in a detached column that has the focus)
  • Context menu on an unselected hyperlink should refer to the link, not the whole text of the item
  • Context menu on an unselected user id should refer to the user, not the whole text of the item
  • Export to some local format. Given the passable search handling and the very nice userlist feature, this would be essential to use this for actual business purposes
  • Let me separate the detached frames to a different top-level window or to the desktop. They are fundamentally different from the one, magic frame tied to the nav bar. This UI metaphor is pretty broken, but it isn’t easy to see what would be better, so give me a stopgap. I spent 10 minutes just trying to figure out why I couldn’t rearrange and resize the detached columns, since they are still completely attached, just not "leftmost"
  • Minimize to Tray
  • View list of people I’m following (and friends on Facebook) and apply to userlists from there

Wrapping up

It’s an interesting product and fun to use. I recommended that my gf use it to track some work with a client and I may make it my preferred "search watch" interface (at least until Trillian Astra gets one). Take a gander.

And if you’re on the Seesmic team, nice job for a 0.3 app! I’m happy to expand on my gripes if you want, I’m happy to shut up (at least to you) if you want, and I promise you: I only write this much about apps I think have promise and I it’s all intended to be constructive.

Technorati Tags: ,

1) Well, Java UI is also doomed because the client implementations leak memory, the Windows implementations crash, and new Java features aren’t free anymore, so the garbage collector fixes that would help most are only available to enterprise customers who buy the "non-free java" license. AIR’s way ahead of that. And it has scroll-wheel support, which means it’s at least caught up to 1998 user-side technology.

Listening to: Lou Reed – New York – Busload Of Faith



Posted in Opinion | 2 Comments »

re: Opera Will Reinvent The Internet On June 16

Posted by S4SD (Seth Morris) on 2009/06/13

I saw this via @da_lind, somehow: Opera has a teaser campaign for some new product releasing on June 16th (at 9:01 AM, no less). predicts it will be a "browser in the cloud," based on the image they’re using as a logo:

Seems reasonable. The buzzword traffic alone should generate loads of subscriptions. (Opera is a pay-to-play web browser1.)

I commented on the ghacks story:

Great. More important software with personal information moving to remote servers I can’t control at home and my IT department can’t manage. I can’t imagine what my end-user benefit might be, but at least Opera doesn’t have to worry about handling addons or extensions, since it’s still purely a networking/HTTP-and-rendering/javascript tool instead of a productivity platform.

At least I’ll get to pay for the privilege of letting them control my updates and mine my personal and corporate click-trails, usage habits, and bookmark data, which sounds great.

And some people think Alexa, an opt-in service with a no charges, a privacy mode, clear pro-privacy policies, is evil! But Opera is the browser we geeks love to extol–as long as we don’t have to use it!

(Posted from Opera Mobile; yes, I *do* like the browser, even if I hate the hypothetical cloud-browser
idea and I don’t think Opera is quite worth what they charge.)

(Disclosure: I used to work for Alexa, I trust the policies I have seen there, I still have friends there, and I am slightly bitter at having to tell every major anti-malware product not to remove the opt-in service–with code *I* wrote–shouldn’t be removed just to artificially up their statistics.)

[Note: I cleaned up typos and inserted hyperlinks. My editing on my phone isn’t always the best.]

My quick takes:

  • "Cloud Computing" means distributing data and processing across fungible, remote, and anonymous computers
  • "The Cloud" means doing this over the internet via some corporation’s computers
  • A browser is a piece of code that
    1. Downloads data from a remote server
    2. Renders it appropriately for your client computer (screen resolution, bit depth, window size, input method, accessibility tools)
    3. Renders some extensions such as Flash, music, and video players what both assume they are running locally and wouldn’t be reliably useable if run remotely (they’d have to push down screen-scrapes at a furious and consistent rate)
  • By their nature, browsers know—and often remember—everything you browse:
    • This user made POST requests to the purchase page of these 3 gardening sites this month, but did not make POST requests to this other
    • After visiting LocalBookstore’s web site, this user went to and did not return to LocalBookstore
    • This user just started visiting job sites
    • Between 9 and 5 local time, this user visited 20 shopping sites, 15 comedy sites, and 3 public utilities

          Of course, your ISP and IT department already have this browsing information, even if you haven’t set a proxy server. You don’t think all that traffic on port 80 is secret, do you?

  • Anonymized and in aggregated, this is extremely valuable:
    • These 3 gardening sites are the most popular in terms of purchase-visits. Would YourGardeningSite like to know this? Do you have cash and a service contract2?
    • LocalBookstore gets hits, but users head to to purchase (would LocalBookstore like to know what pages they left the site on? Does LocalBookstore have cash and a service contract?
    • Would JobAnalysisGroup like to buy a monthly report of aggregate job site visits across multiple sites? Would they also like to know how many users just started visiting job sites? How many stopped? Does JobAnalysisGroup have cash, a service contract, and a promise to report the data as "supplied by"?
    • Would JournalistPerson like to report on business-hour site usage? Would JournalismUser like the source broken down by home DSL/cable (telecommuting) versus corporate networks (reverse telecommuting)? Will JournalistPerson use our name prominently in the article, the statistics graphic, and any search tags?
  • Web browsers also need to record bookmarks, which is more potentially minable data
  • Many web browsers offer to store account and password information for users, often including corporate accounts for users at work

I’m not seeing what a "cloud browser" would add for the user, but I do see what it could do for Opera. There are some plusses and minuses that do look interesting, though:

  • Cloud applications are upgraded and maintained by the service company, which relieves end users of the patch/update burden but also removes IT department control of upgrades, preventing them from vetting updates and managing security configuration
  • Cloud applications carry your preferences to wherever you logon. Whether you want the same bookmarks, cookies, and security settings at work and home is an interesting question. If you do, Opera’s hypothetical "Cloud Browser" would compete with many services that already move some of your data (I like IE7Pro, personally).

Of course, a "cloud browser" is speculation at this point, but even if Opera doesn’t do it it does seem like a reasonable direction for Yahoo! or Google to go.

We’ll know on Tuesday.

1) Well, Opera has always been a pay product in my experience, and I know the mobile version is (I’m still evaluating if I want to pay $24 for a web browser on my phone). I can’t find a link for the price of the desktop version (although they do tout that their beta version is free, which is usually a sign that the stable version isn’t); of course, many products online try to hide their costs until after you have them installed.

2) Of course, we don’t want Our Cloud Browser to look like an evil data miner. I don’t know why so many net pundits like to say that anonymous data mining is evil, even as they quote it, and I love how so many claim the supposed openness of the web means it can adapt to user needs, without mentioning that you can’t adapt to information unless you collect the data. So some other company, owned by Our Cloud Browser or its parent company, gets to sell the data. It buys the usage trails from Our Cloud Browser as a way to launder the money.

Listening to: Donald Fagen – The Nightfly – New Frontier


Posted in Opinion | Leave a Comment »

Re John Feux: “Programmers: Before you turn 40, get a plan B”

Posted by S4SD (Seth Morris) on 2009/06/12

Several friends recently sent this to me, which (given that it was written almost a month ago) probably means they know my birthday is coming up…

(From John Feux) Programmers: Before you turn 40, get a plan B1

Interesting stuff and well worth considering. I don’t know that I agree with Mr. Feux’ interpretations, but I certainly don’t take the rosy view some of the comments on his blog propose.

As I read it, Feux’ general points are

  1. Experienced developers cost more than inexperienced developers but can’t have more experience on any new technology.
  2. As a developer, you need to base a career plan on the assumption of age discrimination. He lists some options:
    • Consult, with the assumption that the experience:cost ratios are treated differently for consultants
    • Advance out of programming. He gives a variety of reasons he finds this distasteful; these are presented as caveats, not as definitive arguments. He also lists some elements of management he finds positive. You may find his opinions backwards at times, but the points are worth reading.
    • Pick some technology and stay with it as it becomes less "cool" and more rare. Feux describes this as inherently unpalatable (a clear indication of his values and his assumption that all programmers share them), but it certainly can be lucrative and stable.

As usual, I’d like to look at presuppositions and their implied values and beliefs. This is one of my favorite parts of reading anyone’s comments, and blogs are especially good places look.

He says, regarding a 1998 study

The use of dubious sampling of only computer science graduates to support its conclusion undermines its credibility…. It completely ignores the significant number of working programmers who either earned their degree in another discipline or never finished college.

It’s a great criticism, but I don’t know that his unsupported follow-up comment, that "the Government has been very slow to grok the software engineering trade" is either true or relevant.

1. "The Government2" used CS grads as a measure because they thought it was especially relevant, rather than, say, because no other rubric came to mind

2. The "software engineering trade" comprises one thing to be grokked—or not—as a whole. I suspect, from reading Feux’ blog, that he has considered that "the Government" has a good, deep understanding of some aspects of some kinds software development, but they are the kinds of development which Feux doesn’t care about and doesn’t usually consider.

Mr. Feux makes a clear—and interesting—belief statement:

The software engineer depreciates only slightly more slowly than the machine he or she toils behind

3. Software engineering is "toil," at least in the corporate or professional world.

4. Software engineers lose value over time—they "depreciate."

5. (Included for completeness.) Development hardware depreciates at a rapid rate. Most of us would agree with this immediately; using it to support the other beliefs is less universal, however.

Feux supports this belief with a 13-year old statement by a former President at Intel who had himself moved from the world of technology to the executive world on his path to multi-millionaire-dom. It isn’t clear if Dr. Barrett, the executive quoted, considered himself, a materials scientist, to be governed by his own statement, which was about hardware and software engineers. At any rate, he had been out of engineering directly for 22 years and does not appear to have ever been an engineer at the company3.

In describing Dr. Barret’s quote, Mr. Feux takes pains to defend the value of the statement even though it was made by "a suit," so let’s add:

6. The opinion of a manager or executive is suspect when it regards engineers or engineering.

Mr Feux makes an interesting comparison: in conventional wisdom, "a programming career is roughly the same [length] as a professional basketball player’s"

The article then moves into the issue of age discrimination, which isn’t the only possible way to interpret the data or the quotes. So the presupposition is:

7. The small number of software engineers over 40 is the result of age discrimination


Those 10 years of C++ experience made the veteran candidate progressively more expensive as they leveraged the value of that experience in jobs requiring C++. The problem is that the marginal utility of that extra experience must exceed the marginal cost of hiring the veteran to justify paying the premium.
[emphasis mine]

Note that confusion around the word "marginal" might mislead some people:

"Marginal" has two meanings here. In "marginal utility" it seems to both mean and imply a small amount of utility. In "marginal cost" it connotes small, but the word seems to mean (denote) "incremental."

This leads the reader to a confused comparison: is the utility of the experience small (as Feux seems to imply) and if so, is the cost also small (favoring the veteran) or simply "incremental"? I read is as: the cost is incremental, but Feux would like us to assume or believe it’s small. I don’t think it was intended to mislead, but it’s a pitfall worth calling.

Let’s take the misleading word "marginal" out of the quote and see how it reads:

…the utility of that extra experience must exceed the cost of hiring the veteran to justify paying the premium.

Clearer and less likely to introduce bias. It’s also a good statement of hiring ethics

Feux weighs in on whether the extra experience a veteran developer has is relevant:

Herein is the source of the problem. The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes….

8. As an engineer ages, (large?) portions of their experience becomes irrelevant. (I suspect that his belief goes on to state that this is monotonic, but it is possible Mr. Feux would disagree.)

I am sure that Mr. Feux would agree that which portions of a candidate’s experience are relevant is highly contextual. Given his bias for switching to new technology, however, I also suspect he would describe certain experience as inherently irrelevant.

The unfortunate truth is that unlike other forms of discrimination that are more arbitrary and capricious, age discrimination can often be a result of objective and sound business justifications

I have worked with many, many managers and senior engineers who considered their discriminations—whether based on age, sex, medical conditions, personality traits, clothing, or attractiveness—to be the result of objective and sound business justifications4.

In fact, I have never worked with someone who both described their prejudices as irrational and suggested using them as a basis for hiring.

In every case, the sound and objective business justifications seem good until you look at them.

I’m not trying to justify it as an acceptable practice, but just trying to describe the pickle it puts the manager in trying to make a sound business decision without compromising the ethical and legal obligations of the company.

This is one of those areas where engineers and technical managers need to call on outside expertise. A good, trained, and experienced HR person is your safety net. They are there to recognize your biases and tell you whether they are reasonable or not.5

…a little gray hair and a smattering of experience in different technologies can create a beneficial bias for companies when they are renting brains instead of buying them outright. It may have something to do with the tendency for consultants to be vetted from higher up in the management chain where the silver foxes live.

9. Like calls to like: It takes older managers to hire older engineers.

Let’s ignore the slipped-in insult. It’s beneath Mr. Feux and I doubt he was aware of it when he wrote it.

…management thinks that everyone including technologists harbors a deep longing to “graduate” into their ranks. I think it a fallacy that no one would continue to design and build software for 20 years unless they had no ambition or growth potential. However, people like me that respect such dedication to the craft are in the minority.

This one’s a straightforward belief statement, and one well worth looking at in the context of this article.

10. Staying in development is a sign of dedication and craftsmanship.

11. (All/most) managers consider engineering nothing more than a stepping-stone.

12. Management roles are a step up in prestige from engineering.

A couple of quickies from his notes about management:

[If you become a manager] Meetings, politics and dealing with unrealistic requests will pretty much become your life.

13. Engineers don’t have to deal with meetings, politics, and unreasonable requests (or not as often as managers)

14. (All?) Engineers want to avoid meetings and politics (and unreasonable requests)

[If you become a manager] You may try to avoid it, but management-speak will creep into your vocabulary

15. There is such a thing as management-speak, and it has no or little value. (All?) engineers want to avoid it and will spend energy avoiding it.

[As a manager] even when you make it succeed, your team should get the credit. [Emphasis mine]

16. Engineers take (and prefer) individual credit as opposed to passing credit on to their team.

[As a manager] you’ll have to check your ego at the door

17. Engineers are not asked to check their egos, nor should they be.

I know you love programming because you like technology, so this may go against your very nature, but no one says you’ve got to jump every time….

18. (All?) Programmers (always?) want to jump to new technologies.

And a corollary, which I suspect is very true of Mr. Feux:
19. Developers prefer wide-if-shallow experience to narrow-but-deep.

It is highly likely that you will still be able to earn some decent coin in the technology you know and love even after a few decades

20. Even though developers prefer to jump to new technologies, working with an old technology can be personally rewarding if it’s one you love.
This is a nice complementary belief to #18 and #19.

There are some interesting beliefs here, some of which I agree with entirely and some I think are good descriptions of the industry’s beliefs as a whole.

My take, as an almost-40 programmer and consultant

I was fortunate enough to have the first time I was daunted by someone’s age be with a guy named Dave (I’ll add his last name if he is OK with that). He was quite a bit older than we were (the whole team was under 25 at the time and the team lead had just turned 21) and, we quickly learned once we hired him, relatively conservative and highly religious, in a conservative protestant sort of way. We had the hung-ho, 1995, startup mentality. We worked 60 hour weeks at a minimum, we played loud heavy metal in the darkened dev pit, and we took breaks for six-player games of Descent and Doom.

When he started, we made a few changes:

  • We stopped playing any music over the speakers unless we were in a serious crunch mode. Even then, we avoided Nine Inch Nails, which had been our favorite. Dave got jumpy when we played Closer on a loop.
  • We moderated our swearing. We had been a foul-mouthed group that liked to shout obscenities at our code. He wouldn’t complain, but we realized something pretty mature for our age: making him uncomfortable just wasn’t good teamwork.
  • We learned that he was even more excited about new technologies than we were: he had been around enough that he could quickly explain pros and cons and apply old patterns to new problems. We learned from him and he tolerated our naivety with apparent amusement.
  • When he left at 6 or 7 (and came in ridiculously early, given our late nights), we started out kind of "making allowances for his age and lifestyle," but that couldn’t last. He was contributing as much as we were and he was learning as fast as we were and he didn’t have as many bugs to fix because he was careful and experienced; instead, we realized that his coming in on a Saturday—or, when the chips were really down, a Sunday—meant he was showing as much or more dedication than we were at 3 AM.

I’m still learning from Dave, even though I haven’t seen him since 1995.

I’ve given a lot of thought to the age discrimination I felt when I first met Dave. I know what it was for me and I strongly believe it was the same for my teammates. There were two issues:

  1. We had convinced ourselves we were better than other people because we were doing what we were doing so young. When we got pulled on to special projects and advanced work ahead of older programmers, we decided it meant we were better6. Seeing someone in his 40s doing the same work we were threatened us by making him seem as "good as us," with added expertise.
  2. None of us were sure we could be doing what we were—what he was—when we got to his age. We thought we would slow down and we would want to go home and sleep instead of coding all night and we would calcify and stop being able to learn as fast. We projected those insecurities on him and when he defied them he both reassured and scared us: what if he could do it, but we couldn’t?

All poppycock, of course. Research shows we stop learning if we stop learning, sleep is good for thinking at any age, and deep knowledge in any area of technology transfers to sudden insight and intuition when learning another.

But we were just kids. We didn’t know that yet.

On the hiring side I’ve seen age discrimination in action and I’ve seen people try to justify it several ways:

  • "He’s too young to hire as a senior engineer"
    This is the most recent one I saw. The manager saying it also liked to talk about whether female candidates were attractive enough, whether a candidate with a lazy eye was going to be too "creepy" to work around, and so forth. When challenged on this, he stopped letting HR into the debriefings and complained that it was allowed in his country7.
  • "He won’t fit in with the culture"
    This is the dodge I see most often. If it’s used about people regardless of age, it may be a valid opinion, but look around: are they describing a culture that presupposes everyone is under 35, is single, is using drugs, or meets other ridiculously narrow criteria?
  • "He has lots of bad habits from COBOL/C/JAVA/RPL/whatever that he can’t unlearn"
    Check this for ageism versus technical religion. Squash it either way, but know which one it is.
  • "I’m not sure he has the energy"
    This is practically a code phrase for "too old." If you hear it, slap the person around and then demand to know what they mean.

In every case, your response, as a responsible, ethical, law-abiding, and generally human engineer or manager, has to nip it in the bud. The response is the same as with any discrimination.

  1. Stop the person right then, right there, even if it’s in a group debrief. This is not the time to "praise in public, punish in private." You aren’t correcting the behavior for that person’s benefit. You are showing the team as a whole that a) discrimination is not part of the culture, and 2) you are aware of it and will do something about it. It is bad for a team to have one openly-discriminating member, but it is far worse to have that and the feeling that people in charge are clueless.
  2. When they defend their actions, don’t attack their defense. You don’t explain why fundamentally unacceptable behavior is not allowed, just like you don’t explain why they have to wear clothes and refrain from murdering coworkers.
  3. When they claim they are making sound and objective business judgments, reduce the objections to observable behavior:
    • When you say "energy," what do you see or hear from your coworkers that you don’t believe he can do and why is it essential to the job?
    • What duties of a senior engineer at this company, performed by other seniors will he fail at and what experience would a different candidate have to have to succeed?
    • What would happen on an average day with the team that he would be excluded from and how, specifically, would it leave him or someone else unable to do their job?
    • When you did your in-depth technical interview, what specific habits did he exhibit and how would they compromise the project at this company, at the level of this position? When you challenged these habits, how did he react?

      You may get reasonable responses to some of these questions. Take those responses seriously and do not let them off the hook for the discriminatory bias. If you were willing to accept prejudice, you wouldn’t need interviews.

  4. Record the event and get it to HR. They need to know.
    Some people feel this is disloyal to their coworker. It is. It is also loyal to yourself, your company, every candidate who will ever apply to a team the coworker is on, to every junior programmer who will ever learn from that coworker, and to the industry and every programmer in it.

On the candidate side, I’m pushing 40. My hair started salting in high school. I’m still using C++ regularly, both for clients with legacy code8 and on some of my personal projects. When asked to solve a problem, I’m as likely to use a batch file9, greppipsedpipeawk, or a quick VBA macro inside Outlook/Word/Visual Studio as I am to pull out a .NET 3.5 trick or mashup some twitter feeds10.

So, do I have to counter my age? Yes. I know some of these 21-year-old wunderkind are less excited to work with me than with some other whippersnapperyoungin’. I remember when I was 24 and we Dave; I had the same concerns and biases and prejudices.

My response is to meet it head-on. I ask interviewers if they think my age is a detriment. This has two good effects. Most programmers don’t want to be prejudiced; if they become aware of their biases, they’re happy to adjust for them. Most managers recognize that my awareness of the issue is a) a sign that I’ll work around it, and b) a sign that overt discrimination could lead to legal trouble. Item (b) isn’t really a good thing, but I don’t want to work with teams that care overmuch about avoiding people they may abuse to the point of a lawsuit11.

When I’m meeting a company, I want them to know a few things:

  • How does my age affect my energy/esprit/dedication? When I was 22, I was fine working 60 hour weeks. Now I’m not. I like to think it’s because I’m wiser, not older, but that may be self-delusion. In any case, I need them to know that a) I know what the job entails—crunch time happens, demos can’t me moved, and some bugs or last-minute features just take extra hours—and b) I’ll do what it takes. They also need to know that I won’t stay until midnight "just because" or to give "moral support" to someone else working late. Well, not usually.

    Basically, they need to be reassured that I’m focused on shipping the product. If my leaving at 6:00 or 6:30 on most days is a problem then it’s really one with their culture, not with me. Not as long as I’m willing to stay late or work weekends or work from home after hours to meet deadlines when necessary.

    Note that this is a different issue in a large, established software house than in a small startup. A company with a family-first culture (say, Intel) won’t ask me about this as much as the entrepreneurial startups I tend to work with.

    The takeaway:
    Tell them upfront what I will and won’t do. Show them that I know what’s expected. Give examples and be specific.

  • Have I kept learning? This is pretty simple to cover. They’ll think of me as a C dinosaur if I talk about C a lot. If I talk about their technology, they know I know it. If I talk about principles, they recognize that I can apply my expertise no matter where it came from.

    The takeaways:
    1) Show what I can do in their world. Use their language; know the SDKs they use. This isn’t really an old-guy thing, but it’s more important to demonstrate when they worry that I’d prefer to hand them an 8" floppy with some assembly on it12.

    2) Leave the wistful reminiscences for later. Even with an engineer my age, talk about what I can do today and what I know now rather than wax poetic about the Good Old Days.

    3) Talk about principles. Principles are experience reified. Mentioning common closure, dependency inversion, command patterns, etc., and how I’d use them to solve whatever problem we’re talking about goes a long way; mentioning how I’d apply the principles in their technology of choice goes further; but mentioning how I’ve applied them across languages, target environments, and APIs goes furthest.

    4) Tell them about hobby work. I write programs for fun; most of us do. I write programs to solve problems that only I have; many of us do. When an older programmer shows you an actively-developed, open-source project he or she is doing, it goes a long way toward reversing the assumption that they’re "slowing down."

  • Am I relegated to "old person" things13? In other words, am I a management type more than a coder? In my case, I’m firmly in both camps and proud of it. Once I show some coding skill, though, most programmers don’t want to pigeonhole me as a manager even at my advanced age. Most programmers are good people at heart; I have to remind them that I have project management and process improvement skills to offer.

    In fact, managers and executives are far more likely to treat me as having multiple skill-sets than programmers are. They see the value of the "soft" skills even when programmers don’t and they tend to assume the technical skill once they see someone else respecting them.

  • Do I love this? In the end, this is the only one that matters. If they can see that I love what I’m doing, petty assumptions around my age become as irrelevant as they should have started.

    Show them that I love what I do and show them what I love about it. If that’s what they’re doing—if I love coding and they code, if I love games and they write games, if I love databases and they use a database, whatever—they’ll want me to do it with them. Wouldn’t you?

    This isn’t really a takeaway for being an older candidate. It’s a guideline for living and working. Let people know what you’re passionate about; they’ll want to help you do it and they’ll want to do it with you.

And in the end, there is one rule that only an old codger can really have learned: If they don’t want to hire me because I’m older, then they’re not good enough to work with me.

So, summing up: Age discrimination is very real in our youth-oriented industry, it requires vigilance on all of our parts to help show our coworkers when they exhibit it, the common justifications for it are both ridiculous and easy to respond to, and if you’re doing what you’re doing because you love it you’ll be fine.

The "Plan B" options

I really liked Feux’ "Plan B" options, but let me re-state them how I read them:

  1. Take your expertise and teach it to other people. Consulting lets you see a broad selection of projects, work with a wide variety of teams, and pass along your habits, beliefs, and skills everywhere you go.
  2. Manage teams, projects, or companies: Mentor people and apply your expertise across a large swath of the project at once. Make the hard decisions and shield the less-prepared engineers from the confusing world of departments with different values and criteria. Communicate what the engineers need to the rest of your company, translate what the company needs so your engineers can understand it, and build a culture that gives your programmers the learning, success, and chance to have a life that you may not have had.
  3. Find things you love and keep doing them, even when they become un-faddish. You love them for a reason and people still need them. You can still learn new things, both within your older technology and elsewhere, and you can handle working on more than one project at a time. If the one that pays well and keeps your family feeling safe about the mortgage and the college fund, spend your evenings and weekends on the bleeding edge. When you’re not spending that time with your family; finding that your family is a higher priority than you ever expected isn’t "growing up," it’s just "growing."

This, right here, is why I do what I do and why I’m so passionate about it. I consult with startups and small teams doing technology and dev process, but I measure my success by asking two questions: Will the client ship the next project, the one without me, successfully? And will the team’s quality of life be better for it? And I couldn’t have done this at 21.


Just some notes about the beliefs and presuppositions I see in Feux’ post. I grouped them arbitrarily and I’m sure he would disagree with many of my interpretations. I’d love to learn where I’m wrong; I hope he’d love to learn what a reasonably careful reader gets from his writing.

About programmers and programming

2. The "software engineering trade" comprises one thing to be grokked

I don’t think for an instant that Mr. Feux would agree with this consciously. I do suspect, however, that he unconsciously dismisses large swaths of the trade as uninteresting to him. I probably agree on what the interesting bits are, but I need to keep in mind that he may be ignoring something important to me and he is probably unaware of it.

3. Software engineering is "toil,"

Again, I don’t think he would agree with this consciously and it’s quite possibly he was being ironic or sarcastic14 with his poetic turn of phrase.

But I may surprise you: it certainly can be toil. At some point, it is for most people; some people get out of the industry then, some get through it and return to loving what they do, and the rest become the sad, embittered, mediocre developers we all fear turning in to.

10. Staying in development is a sign of dedication and craftsmanship.
14. (All?) Engineers want to avoid meetings and politics (and unreasonable requests)

These are projections, but largely true and useful beliefs. I’m sure they are motivating for many people. Including me 🙂

8. As an engineer ages, (large?) portions of their experience becomes irrelevant

This is really a belief about novelty: that technology is only relevant if it’s new. It’s not a business-focused or results-oriented belief; it’s a belief that learning new things is more important than producing reliable and reproducible results. It’s a good belief for an engineer to help his career. After a certain point, though, I would say that it’s a limiting belief. If I find a developer who is still focused on novelty over reliability and doesn’t find that old knowledge is always relevant, I have found a good, solid engineer, but not one ready to take on what I consider the duties of a senior software engineer.

16. Engineers take (and prefer) individual credit as opposed to passing credit on to their team.
17. Engineers are not asked to check their egos, nor should they be.
18. (All?) Programmers (always?) want to jump to new technologies.

These are core beliefs in the "Cult of the Programmer" belief system. They prize individual effort over results, cleverness over sustainability, and silo, cowboy programming over teamwork. It’s common "Type A" stuff that makes up the backbone of our macho, testosterone-fueled culture where programmers live out our adolescent power fantasies with code instead of capes.

I went through it and I still indulge in it sometimes. I see it destroy non-aggressive programmers, good projects, and good companies on a daily basis, though.

19. Developers prefer wide-if-shallow experience to narrow-but-deep.

This is a common, but not universal, belief and a common, but not universal, preference, in my experience. The "deep guru" is also highly respected, but I suspect that on average, it is true that a wide-but-shallow developer is more respected than a deep-but-narrow one.

I know that a wide-but-shallow developer can easily appear to be more skilled, more experienced, and more generally impressive than one with a narrower skill-set, even when that breadth is irrelevant to the task at hand. To sound smarter and better prepared than we are is an easy skill to master and one most developers learn extremely early (especially the more Type A, Cult of the Programmer-oriented ones).

I should write an article about it. I’ve actually taken classes in acting more intelligent than I am 🙂

20. Working with an old technology can be personally rewarding if it’s one you love.

I love this one. I’d take the word "old" out. Actually, I’d take "an old technology" and replace it with "anything," but that’s outside the scope of Feux’ blog and mine.

About management

  6. The opinion of a manager or executive is suspect when it regards engineers or engineering.
11. (All/most) managers consider engineering nothing more than a stepping-stone.
15. There is such a thing as management-speak, and it has no or little value.

This is related to the Cult of the Programmer belief set, but it’s also a variant of the beliefs that every culture has about other cultures, especially ones it believes have power over them. They’re broad generalizations that break down in practice as often as they stand up, but they are so much a part of our culture that they act as "signifiers" indicating membership in our self-appointed elite.

12. Management roles are a step up in prestige from engineering.

This is an interesting observation and a belief about what other people (people who are not in technology, even) believe. I suspect it’s true, although managers are seen as more accessible and understandable than engineers. Engineers are still viewed as a priesthood with mysteries and as unattainable to the average person, although that is finally changing.

13. Engineers don’t have to deal with meetings, politics, and unreasonable requests (or not as often as managers)

I don’t understand this one. It’s completely untrue in my experience. But it would be nice.

About age

  4. Software engineers lose value over time

I know for me, when I held this belief it was a projection of insecurity. I doubt it is for everyone. I know I don’t believe it and I haven’t seen any evidence of it.

I would like to see a reformulation, though: "Software Engineers lose value if they don’t change over time."

9. It takes older managers to hire older engineers.
7. The small number of software engineers over 40 is the result of age discrimination

I need to think about these two. I’m not sure that either is a law of the universe, but they are certainly true in many people’s experience.

I believe that both are changeable, both in the small, through each person doing what they can to work around them, and across the industry as a whole… through each person doing what they can to work around them.

Personal to John Feux:

Thank you for writing such an interesting article! Great post and I’m really excited to see the active discussion it’s provoking.

I hope my comments are taken in the spirit intended: friendly, respectful, and supportive. Your blog has made it to my feed list. You write some great stuff.


1) I just want to say that I really, really thought this was an article about programmers and sex when I saw the title. But that’s probably me; I assume "Plan B" doesn’t bring up the same interpretation for everyone.

2) Gotta watch "The Government." It isn’t really one thing, it doesn’t have one set of goals, and it doesn’t have motives in the abstract.

3) To be fair, the article I read about Dr. Barrett was on Wikipedia, so all I saw was what the last anonymous internet user chose to write.

4) It’s not really a secret that engineering is a sexist, racist, ageist culture that wants to forgive almost anything in the name of intelligence. At one company I vetoed a candidate for saying that he managed two employees, but because they were women he couldn’t give them anything important to work on. He backed that up by saying that they "would just get pregnant and quit" when deadlines approached.

The sad part was that none of my coworkers thought that was a problem in any way. Some even thought he had been prudent.

5) Sadly, the average white, male, American programmer would rather take advice from a 90-year old, female, non-white, foreign programmer in a suit than from the best of HR reps.

6) It never occurred to us that a) we were the people not already assigned to important projects and b) we were the people the CEO liked to hang out with and relive his youthful techie days.

7) What country did you first think of? It was Ireland, btw.

8) "Legacy code" is a code phrase at small companies and startups. It means "anything I didn’t write or anything I wrote using a tool I’m bored of." For many programmers today, that means any C++, even if it’s brand-new and running on the cutting-edge platform.

9) Okay, I’ll name it .cmd instead. Call me avant-garde.

10) If you’re reading this more than a month after it was written, pretend that wasn’t horribly outdated. I’m on to something new, I hope.

11) In general, you don’t want to sue over this kind of thing, unless you want to switch into activism as a lifestyle or career for a few years. You don’t want to imply that you’ll sue. But you can’t prevent a good HR rep from considering it.

I have a not-so-funny story about a good HR rep, an Irish engineering manager, HIPPA, and me not suing, but this isn’t the place for it.

12) Actually, I do have some 8" floppies with some assembly code on them, but only because I don’t know how to get rid of them.

13) It’s worth thinking about this: in software, we do have roles we assume older people (i.e., over 35) will take, just like we have rolls that women will take. It’s wrong and wrong-headed in both cases; it’s dangerous because it’s out of our awareness and because we don’t talk about it.

Scrum-master, Manager, MS Project, writing specs, … Are these what we think a programmer over 35 does? Does s/he do it as well as code, or instead of? If s/he moved into programming at 30, does that change anything (i.e., is it based on age or experience)?

UI design, community management, running focus groups, HR, coding the "easy" pieces with user interaction instead of the "hard" pieces with data mining: Are these what we expect a woman hired into the team to be doing?

Sure, we all know of counter-examples. The ageism Feux is talking about is a great, and more acceptable to challenge, entry to recognize other prejudices that permeate software.

14) According to the definitive linguistic analysis in the book Lamb, "Sarcastic" is what "ironic" becomes if you know you’re doing it.

Listening to: Fairport Convention – Old-New-Borrowed-Blue – Matty Groves/Dirty Linen


Posted in Opinion | 1 Comment »

Urls, References, Shallow Copies, Deep Linking, and Wikipedia

Posted by S4SD (Seth Morris) on 2009/04/19


I have a friend who’s a relatively junior programmer; the other day he was asking me about copying reference objects in .NET. References, pointers, value/stack objects, and the difference between deep and shallow copy semantics is something no language has really done right and it’s the source of bugs, performance and memory hits, and time lost writing test code on many, or maybe most, projects.

.NET makes it both easier and harder with the clear distinction between reference types and value types. It’s easier in that the behavior is clear if you know which type you have (although each can contain members of the other type), but harder in that far too many developers don’t really know the difference. Also, the notion of boxing comes up in all the wrong contexts: it isn’t really important as a performance consideration in most real-world applications, but it does hide logic errors that are unlikely to be detected by unit tests, since the developer writing the unit tests didn’t understand the distinction in the first place.

The second-worse language I’ve used for reference vs. value confusion and the need to code review shallow vs. deep copy semantics in every function is JavaScript/ECMAScript. The language works fine, but for some reason even extremely careful developers seem to get lost in the almost-scripting and almost-object-oriented1 language when combined with multiple, almost-stateless frames in a large application.

But it’s the worst language that causes the most concern: HTML. And here we have to go into an issue of overloaded operators: what is a "reference"?

  • In software, a reference is a stand-in name for something. In lower-level languages it’s usually backed by a pointer to memory and in higher level languages it is likely to be an index into an object map, but in either case you can have multiple pieces of code using the reference and all are accessing the same object instance. If one function changes the object, subsequent accesses will get the latest changes.
  • In HTML, a reference is an HREF: a Hypertext REFerence. It is a stand-in name for a document (or a location in a document). HTML makes no assumptions about whether a document’s content is stable. In fact, most pages on the web are assumed to change, with comments added to blogs, forum posts edited, online catalogs updated, etc.
  • In nonfiction or scholarly writing—including encyclopedias—a reference is a stand-in name that identifies not only data, but who takes responsibility for that data and exactly which version of the data is being referenced. This is so important in that context that scholars and journalists have defined standards for representing references consistently.

The Wikipedia Problem

Which brings us to Wikipedia. And to a way to teach references and values that might resonate with "kids these days.2"

It’s common to link to wikis, especially to Wikipedia, when explaining or defining things. Wikis are great: they facilitate communication, collaboration, and community and they are a good way to get the most-wanted content in a reference populated first. They have their limitations, but every tool does.

The problem with linking to Wikipedia (or another wiki, although to a lesser degree with slower-changing wikis) is that HTML links are true, blind references. You get whatever is there right now, and Wikipedia is known for (often transient) spam content and inaccuracies.

In software, the solution is a deep-copy: actually copy the content to your own site and reference that (probably with a link to the current Wikipedia content). It isn’t a bad choice, but it can get tedious. Another solution is to link to the Wikipedia article history. For example: is a link to the Wikipedia article of References (of several kinds). Looking at it now, as I’m writing this, I see several sections I would love to comment on here—and several sections that have tags indicating they are likely to change soon. If I use that link, my comments are likely to be irrelevant later. I’m keeping value data (my text) that doesn’t correspond to the reference data (the content beyond the link). is the link to the version I see while writing this3. If I want to make comments, or if I am worried that the page will be modified in some way I don’t want (say, a page prone to political, religious, or commercial spam), Wikipedia promises that this URL will be stable. In the language of C++, it is a "const reference."

Of particular interest to me, writing blog entries, is the References4 section of the Wikipedia page. This is the section where a Wiki article contains external reference data (the rest of the page is value data and internal references to other Wikipedia pages). I’m likely to want my readers to see the references. Because that section is very likely to change, the purportedly-stable link lets me refer to these references-in-my-reference safely. But notice that I don’t know if those objects (the pages behind links in the Reference and External Links sections of a Wikipedia page, even a stable one) are stable, although in some cases I can make a good guess (links to PDFs of published papers, for example, are likely to be very stable).


"So this is all interesting, but what is the point?" There are two lessons here, one for passing on information (in blog posts, emails, twitters, etc.) and one for programmers, especially of the more-junior sort.

When you’re passing on information:

  • Know if you’re giving someone a reference or a value. Copy information you need stable and available, just as you would in code.
  • Don’t link to Wikipedia’s "current page" unless that’s what you mean.

And for coders, if you understand hyperlinks, you understand references and values:

  • A reference is like a hyperlink: It goes to something else and you don’t own it.
  • A value is like content in a page: It’s owned by the page and no one else can change it unless they can edit the page.
  • A reference copy is copying the URL: it’s still a reference to the same object. If someone edits the page, you will get new data the next time you access it.
  • Remember that a reference may contain references: Pages can contain links to other pages.
  • A shallow copy is copying a page: If the page had references (links) on it, your new copy has those same links.
  • A deep copy is a web spider: You can copy a page and every page it links to (and every page they link to, and so on). If you do that, you have a new, unchanging page and no one can even see it unless you tell them the URL.
  • A const reference is a link to a page that doesn’t change: But it may link to pages that do change!

1) ECMA is an object-oriented language, and whether JavaScript in a web page is "scripting" in the usual sense is an interesting question, but most interesting JavaScript applications are "almost" scripting and "almost" object oriented. And yes, those two are different axes; there are many excellent object-oriented scripting languages.

2) I’m feeling old. I was listening in on a discussion this week between a Senior Architect and an Architect where the Architect didn’t seem to be following some of the more fiddly details; the Senior commented to me later that the Architect may never have written a WNDPROC.

3) You can get this from the History tab, but it’s probably better to click the "Permanent Link" or  "Cite this Page" item in the "Toolbox" section of the navbar.

4) At this time, the relationship between the "External Links" and "References" sections of the Wikipedia page template is unclear and apparently undocumented.

Listening to: The Alan Parson’s Project – Best Of – Damned if I Do


Posted in Opinion | Leave a Comment »

The World > Your Project > Your Process > Your Tools

Posted by S4SD (Seth Morris) on 2008/10/11

This is something I’ve been wanting to write about for a while; I might as well use a short answer I wrote on LinkedIn as a jumping-off point.

In the Scrum Practitioners group, Aqueel Khan asked about baseline implementation before starting an agile project: 

I know there’s no cookie cutter template for every team in every organization. But there has to be "something" which needs to be implemented as the foundation of a Scrum/Agile/XP project.

Gunther Verhyen gave a fabulous description of the raw process requirement for Scrum1, suggesting that the process has no procedural prerequisites.

So I added some comments about beginning any process, with specifics that apply to Scrum:

Gunther’s answer is pretty much definitive, so let me add something outside of the Scrum process that you need for company and team success: know what you aren’t managing with Scrum.

It gets very easy to take a simple and effective process like Scrum and assume it is larger than your project, larger than your product, and larger than your company; the result is to assume Scrum (or UML, or … or …) will solve problems it isn’t designed to address.
Don’t let people try to shoehorn product planning (market research, customer interviews, experimental prototypes, …), engineering R&D (technology evaluation, build/buy analysis, large-scale architecture and refactoring plans, …) into a project Scrum.

It is very easy to take the simplicity and success of Scrum, combine it with the increased day-to-day involvement of groups that are traditionally "above" the implementation phase, and find your organization start to assume that the Scrum process is one never-ending chain of sprints that somehow encompasses all product work. It isn’t intended to be that and trying to use it that way will weigh down your implementation.

Make sure the Scrummaster(s), the heads of technology, the heads of product, and the heads of sales/support/customer-interaction all know what not to try to inject into the Scrum.

If you want to keep this in a Scrum framework, you can do so by creating backlogs for groups, as well as projects/products, by keeping a firm hand on the project backlog to prevent creep-in from larger-than-project items, by ensuring that projects are running with larger sprint lengths to work on larger items (I know, many poorly-trained Scrum fans find this type of "planning" anathema, but successful teams have it whether they recognize it or not), and keeping a sense of humor about the whole process.

Or, just remember that nothing inherent in the Scrum process would lead a company to cancel a project; clearly, something outside the process has to exist to do larger things. Keep that separate from the Scrum so neither interferes with the other.

[LinkedIn Scrum Practitioners Group question thread]

Overall, this is a problem that wheedles its way into every methodology. In fact, it’s one of the measures of when a successful methodology becomes a "religion": when people insist that it solves problems it doesn’t.

Scrum is about software development at the low, development team level. It manages projects by breaking off chunks that meet certain requirements (size, testability, and completeness-to-ship) and managing the day-to-day implementation to finish that chunk on schedule. It does not address anything else.

Scrum can be used to manage other, non-coding projects and is quite successful with any pile of work to be done that can be broken down into linearly-independent units. For what it’s designed to do, Scrum is great.

Unfortunately, Scrum suffers from too much adherence by too many people with too little understanding of how it fits into their overall problem. Scrum doesn’t say anything about what to build, when to build it, or what to build next. It doesn’t address training, delivery, internal or external documentation, or requirements gathering.

Most agile practitioners eschew any kind of overall architectural design (believing it always leads to if "big design up front"), yet senior developers invariably practice a form of it—it is one of the features that makes them senior. Because it isn’t part of the day-to-day development, Scrum doesn’t address larger-scale architecture—or even small-scale design2,3. Because it isn’t part of Scrum, many houses embracing Scrum try to avoid doing it at all, believing that Scrum—a deliberately short-sighted process—somehow replaces future-looking planning.

The Agile Manifesto tried to avoid some of this. It specifically called out that "things on the right"—which includes process, tools, documentation, and planning—have value. It claims that other things have more value when they come into conflict.

This is a process of criteria ordering. It is one of the first pieces of work any team should do and one of the premier jobs of technical management, all the way up to the director or VP level. Criteria ordering is relatively simple and incredibly valuable and the Agile Manifesto authors are to be commended in their work on it and the way they tried to bring it to the forefront.

But given who they are, who the initial signators of the manifesto were, they really should have known the damage they were doing and they should know how little the have done to ameliorate it.

Every major agile process, and especially Scrum, has done a great job trying to bring the left-side criteria into play by a) ignoring the right-side items, or b) diminishing the value the right-side items bring. This isn’t bad with people who know what they’re doing, but it is devastating when people embrace the methodology as larger than their problem.

Let’s set Scrum aside to show the situation. Back in the dark ages (1999 or so), the religion was UML, especially the Rational approach to UML. Agile development was still a guerrilla phenomena and the disdain for "big design" was partially in reaction to UML and it’s more narrow-minded adherents. To make matters worse, UML was usually tied to one of a few big, multidimensional tools that did very good jobs at some things and very poor jobs at others, but integrated them well enough to force some team members to use a poor tool to make other members happy.

Like other methodologies—waterfall planning, OOAD, BRD-as-product design, even the relatively benign CRC—people heavily invested in the process came to believe that the model in the process was somehow able to model the world outside of software development (a kind of reversal of the Conant-Ashby theorem). 

When this happens, you find several fallacies and errors creeping in to daily life:

    • Items that are not explicit in the process are disregarded (design, buy-in from other groups, redesign in the face of change, real measurement instead of believing the schedule, etc.)
    • Work that isn’t part of the process gets shoehorned into the process somewhere ("Well, considering those user requests is really part of bug tracking, so we’ll just have the bug database manage it.")
    • Some data or functionality in a tool is partitioned off and used in a way that doesn’t make sense. Sometimes fields are used to mean something entirely different just because they hold the same kind of data.
    • Business processes that have nothing to do with software are driven in the development process even when it doesn’t work4.

I am as guilty both of doing these and of letting other people do them on my watch. They are seductive and there are times to do the wrong thing in favor of the greater project.

I’ve done them. But you don’t have to.

When things seem amiss, ask yourself some questions:

  1. Is this thing we’re doing something inside the model of development that the process envisions?
  2. Is this process, as we’re implementing it, designed to support this business process?
  3. Is this working for us? Have we reduced work, shortened schedules, increased participation, eliminated political maneuvering, or increased quality?
  4. If we’re responding to something outside the process’ model (a change in the real world, usually, as opposed to something in the virtual world of our plans and hopes), what are the parts that are not about this process and have we made sure they’re being addressed in their own way?

Once you see the problem, it isn’t usually hard to address (although the die-hard adherents of any belief system will require some convincing). Just remember the formula:

The Real World > The Project > Your Process > Your Tools

Items on the right cannot contain items on the left. Models on the right are unlikely to be good models of anything on the left.

1) The minimum view of Scrum:
    3 roles: Scrummaster, Product Owner, and Team Member
    3 ceremonies: Sprint Planning, Daily Scrum, and Sprint Review
    3 artifacts: Product Backlog, Project Backlog, and Burndown

2) Also, any enshrinement of design into Scrum would have made Scrum less applicable to non-coding projects and would have left some people confused over the agile principles to value "working software over comprehensive documentation" and to value "responding to change over following a plan."

3) Unfortunately, the stigma associated with design is felt more strongly by more senior developers, who have more invested in appearing to be closely allied with the current development religion. The people most hurt are the junior developers, who are deprived of the seniors’ intuitive expectations as to how a project will "look" when it is done.

4) When a process works for something, just keep doing it. Change the names of things if you have to.

Listening to: Cat Stevens – Tea for the Tillerman – Hard Headed Woman


Posted in Opinion | Leave a Comment »

Hug a Developer Today

Posted by S4SD (Seth Morris) on 2008/09/23

(I could argue the view that this video trivializes homelessness, but I’m not sure I believe it and this isn’t the blog for that. I will argue the view that this video trivializes the effects of bad project management.)

Watch the video, laugh, and share it with anyone you want to before reading on.

If you don’t want to watch the video (it has sound but does not need it), here are the texts of the signs the developers are holding:

  1. I am in pain
  2. We’re 4 months in to a 5 month schedule and I just received the final requirements yesterday. (And they’ve changed again!)
  3. I spend half my days in meetings about how to get more work done (instead of working)
  4. My boss read in a magazine that developers using "___" programming language are twice as productive. So he bought us a copy and cut our schedule in half.
  5. Every day my boss changes his mind about what we’re building.
  6. (Man) People keep asking me to fix their email, so I have no time to code
    (child sitting next to him) My daddy has no more time for me
  7. Some consultants told my boss they could build our next version in half the time, for half the money. He believed them but now they’ve spent all their budget, used all their time and are still only half finished. Now they’re gone and their code is a disaster. We have to fix it and finish what they started.
  8. (After the credits, in color, small child sitting on park bench) I just finished an intensive 6 week Visual Basic course

Sometimes I’m asked why I want to consult instead of taking a higher-paying W2 job with equity and a stronger career path or why I’m committed to project and process improvement in startups and small teams (which don’t have a budget for that kind of consulting). I’m never sure whether to tell them that it’s because I’ve seen the quality of life improvements for everyone on the team when a project is successful and the process is repeatable and predictable.

Engineering teams want to innovate on ideas, technology, and features, not process, and engineers (and artists, and writers, and managers, and marketers, and ….) want and deserve to have energy and time for their family, their personal and professional growth, and their own projects.

A programmer who sent this to me. I’ve known her for years and have been her team lead or manager at three companies. I know she’s experienced all or most of these and I know it has a real effect on her life (as it has on mine and many of my friends). These are the problems in the life of a programmer.

At the risk of killing the frog1, let’s break these down into some categories:

  • Failed Project management. These are the kinds of thing that developers live with every day but feel powerless over. Sadly, developers are sessile by nature; they will often put up with bad management, hating their job, feeling like they are failing, and feeling powerless over their work environment, for a very long time2. [items 2, 5, 7]
  • People in power who have a poor understanding of what development is3. Programming is invisible. QA is almost as invisible when it finds bugs and more invisible when it doesn’t. Programmers spend their time looking at source code, which is a static representation of an abstract process that will occur invisibly at a microscopic scale, or designs, which are an abstract representation of how poorly source code represents the problem domain. Unfortunately, even former developers fall into the trap of thinking that what isn’t tangible must be fungible. [3, 4]
  • The inherent pain in life of a developer. When you can do something, people expect you to do it. You want to do it. Since developers are able to do what they do anywhere and anytime, it can take over life easily; since developers are the most respected experts on an ubiquitous, increasingly-arcane, and increasingly-powerful technology, they are asked—and expected—to use that knowledge on behalf of their friends, family, and coworkers.
    We start out on this life wanting to play with things and to solve problems; we need training to know how not to do that when it costs us something (like time with our family) that isn’t in our faces while the problem is. [item 6; and arguably item 1]

These aren’t just one class of problem, but they are all real kinds of problems that burn out developers and destroy projects and sink companies. A good manager or lead can solve some of them and ameliorate others, but systemic change to address them all is very difficult. It to easy, and too common, to lump them5 together as "pointy haired bosses and bad planning," but we can’t solve them commingled that way.

That’s why I care about dev process at the leads and line managers level. It’s the fulcrum between failed project manager and poor understanding of development and engineers. It’s also one of the levels that can often remind a developer to step back and re-evaluate personal priorities.

So wait for HR to be looking the other way and go ask a developer if s/he wants a hug. (Don’t just hug them; many developers won’t like it… and some may sue.)

1) "Explaining a joke is like dissecting a frog: you understand it better, but the frog dies in the process." – Mark Twain (attributed, I don’t know if that’s accurate)

2) This is true of all people, really. It’s more visible in developers because of the shorter job cycle (longer times unhappy in shorter job lengths) and the how clear the effects of managers’ decisions are on the developers’ lives (ask a room full of developers how many Thanksgivings or Christmases they’ve been able to be home with their families; then ask then if it was because of things within their control).

3) I worked at a video game company for a while. Independent game developers doing the kind of license work we were (games based on TV shows, movies, etc.—I worked on the game Beethoven’s 2nd, based on the movies with Charles Grodin4) were at the mercy of the license holder, who were media companies and didn’t know what they wanted from a game. When I had been there a few weeks, a fellow developer told me that at the end each project they would give out the "flaming sphincter award" to whoever had been forced to redo the most work through no fault of their own (license holders deciding they wanted to add a bird to the game, that kind of thing).

I was warned that I would never receive this award and I should just let it go because "no amount of programmer pain is visible." My coworker was right; recognizing that helped me get through some tough projects and it helps mediate many difficult situations: no amount of developer pain is visible, even to other developers and certainly not to managers who aren’t around the engineers daily. What seems obvious from the engineering side is not misunderstood or ignored, it is invisible.

If you’re going to try and make that pain visible so management can recognize the problems and work on them, also ask what the developers can’t see and make the engineers aware of that. It’s basic mediation, but it’s especially hard when what each group wants is invisibly obvious to them and simply invisible to the other. Someone outside that chain of command is the best to help.

4) Admitting to having written this game is a big step for me. It is not the thing I’m most proud of. If you’d played it (and no one did), you’d know why. 🙂

5) And other classes, of course. If these two types of problems went away life would be much better, but even taken together they aren’t a silver bullet.

Listening to: Billy Idol – Rebel Yell – Rebel Yell


Posted in Opinion | Leave a Comment »