Research: Software development roles and responsibilities

Trying to answer the elusive questions of:

What is a Software engineer?

What is a Lead Programmer?

What is a Tech Lead?

What is a Principal Engineer?

What is a Software Architect?

What is a Technical Project Manger?

What is a Scrum Master?


Wikipedia: Lead programmer

Wikipedia: Software engineer

Wikipedia: Software architect

IBM developerWorks: Characteristics of a software architect

Magpie Brain: A Tech Lead Manifesto Project Roles and Responsibilities (Word .doc!)

it’s a delivery thing: Agile Project Roles and Responsibilities

Stack Overflow: Does a software architect have a role in agile, esp. Scrum?

Wikipedia: Scrum Roles

InfoQ: Mapping Traditional Software Development Roles to Scrum

Code Better:Classic Technical Lead Blunder

Atlassian: Tech Leads Talk

Two comparisons of different programming languages worth reading

Normally these kinds of pieces are worthless, but these two recently stood out to me:

Dennis M. Ritchie: Five Little Languages and How They Grew: Talk at HOPL* March 19, 2002

Michael Tsai: Perl vs. Python vs. Ruby – distinguished for the thoughtful replies in the discussion thread.

SVN Branch Management Link-a-rama

Coding Horror: Software Branching and Parallel Universes

Perforce: Laura Wingerd & Christopher Seiwald: High-level Best Practices in Software Configuration Management

InfoQ: Version Control for Multiple Agile Teams

BetterExplained: A Visual Guide to Version Control

Branch Maintenance: Chapter 4. Common Branching Patterns

Submerged: CollabNet’s Subversion Blog: Branching Strategy Questioned

CMCrossroads: Robert Cowham: Branching and Merging – An Agile Perspective

CMCrossroads: Steve Berczuk. Robert Cowham, Brad Appleton: An Agile Approach to Release Management

Related Background Links:

Version Control with Subversion: Branch Maintenance: Chapter 4. Branching and Merging

Version Control with Subversion: Strategies for Repository Deployment: Chapter 5. Repository Administration

Version Control with Subversion: Repository Maintenance: Chapter 5. Repository Administration

JavaWorld: Merging and branching in Subversion 1.5

RubyRobot: Subversion With Mac OS X Tutorial

Unit Testing Python Links Jason Diamond: Test-Driven Development in Python Jason Diamond: More Test-Driven Development in Python

AgileTesting: Python Unit Testing Part 1

AgileTesting: Python Unit Testing Part 2

StackOverflow: Python Doctest vs Unittest

Ian Bicking: Behavior Driven Programming

Thinking About Flow

If you make a living programming, you know how productive, how creative, how enjoyable this state is: you + the task at hand – any other thought in the world. Focus, flow, mindfulness only of the moment you are in.

Flow can be found in the most mundane moments (there are no mundane moments if you become aware of this): from playing a game of basketball, to playing your guitar, to a late night World of Warcraft session, to gazing at your wife, or laughing with your daughter.

Time slows when you are in flow. Anxiety about the future transforms into passion about the now. Thoughts about the past do not get a chance to play on your conscious mind.

Flow is an extreme form of the feedback I’d give my Mom, when she was falling into a bad state, and concentrating too much on mistakes made or horrors visited upon her in the past.

“All that matters is the here and now. You, right here, are safe and well. We are doing well. All of us are blessed. Don’t let what happened 20 years ago defeat you. It doesn’t matter. Besides – its kinda insulting to your current circumstances to think anything more of the past other than it helped you get to here. Now is all that matters.”

(I need to tell myself this more often!)

This doesn’t jibe so well with a lot of psychological talk about how people need to face their pasts to over come them. That’s true in many cases. In many cases we *do* need to deal with the demons in our hearts in order to achieve our potential. But Mom had already faced her past. In countless therapy sessions, with countless doctors. She had a condition. And her doctors had, at one time wrote her off as hopeless – doomed to a downward spiral of psychotic episodes.

Becoming mindful of her own thoughts was part of a larger set of solutions that helped her be very “with it” the last few years of her life before leaving us. She succeeded to the point of being aware of threatening ‘bad thoughts’ and seeking out help before cycling and requiring hospitalization. Before this, once you saw the signs, you knew it was a hospitalization that would be the result.

Its funny, when you think about it. Because while we find flow in a great many positive things, the state of flow is just as likely found in the neutral or even the negative.

We spend millions of dollars, our time and attention, following gurus of various ideologies, taking up crazy religious practices, pursuing sex and drugs, creation and destruction, creating drama upon ourselves and our fellow man – just to be in it.

Flow is so primal a force in our adult lives because its something we literally swam in 100% of the time as children.

Our schools and our parents barked it out of us as they taught us to ‘pay attention’ for the *next* moment. We shaked it out of our own hearts as we let ourselves become more and abiding to scheduling. Most of all, as we get older, time simply seems to speed up as we become aware of our looming mortality.

Psychology Today: Finding flow:

…A deprived childhood, abusive parents, poverty, and a host of other external reasons may make it difficult for a person to find joy in everyday life. On the other hand, there are so many examples of individuals who overcame such obstacles that the belief that the quality of life is determined from the outside is hardly tenable. How much stress we experience depends more on how well we control attention than on what happens to us. The effect of physical pain, a monetary loss, or a social snub depends on how much attention we pay to it. To deny, repress, or misinterpret such events is no solution either, because the information will keep smoldering in the recesses of the mind. It is better to look suffering straight in the eye, acknowledge and respect its presence, and then get busy as soon as possible focusing on things we choose to focus on.

To learn to control attention, any skill or discipline one can master on one’s own will serve: meditation and prayer, exercise, aerobics, martial arts. The important thing is to enjoy the activity for its own sake, and to know that what matters is not the result, but the control one is acquiring over one’s attention.

It is also important to develop the habit of doing whatever needs to be done with concentrated attention. Even the most routine tasks, like washing dishes, dressing, or mowing the lawn, become more rewarding if we approach them with the care it would take to make a work of art.

…Flow is a source of mental energy in that it focuses attention and motivates action. Like other forms of energy, it can be used for constructive or destructive purposes. Teenagers arrested for vandalism or robbery often have no other motivation than the excitement they experience stealing a car or breaking into a house. War veterans say that they never felt such intense flow as when they were behind a machine gun on the front lines. Thus, it is not enough to strive for enjoyable goals, but one must also choose goals that will reduce the sum total of entropy in the world.

Find your flow and you slow down time. Find your flow and time has no meaning. Find your flow and find your love.

These are things I am saying as much to myself as I am you.

Related Links:

On “Make It Work Make It Right Make It Fast”

Ward’s wiki: “Make It Work Make It Right Make It Fast”

If you never make it Right – you will fail.

If you never make it Work – you never ship. You have failed.

The tension between these frames the art of software development.

There are no golden hammers to navigate these waters. Don’t let anyone fool you.

Chris Dixon: “What carries you up will also bring you down”

Chris Dixon explains how the attributes and qualities that explain an organization or person’s success, also lead to their downfall.

On Quality, Speed, Practice: Software Development links for October 18th, 2009

Microsoft Research: Janie Chang: Exploding Software-Engineering Myths:

…there is one point that gives this software-engineering myth buster a great deal of satisfaction.

“I feel that we’ve closed the loop,” Nagappan says. “It started with Conway’s Law, which Brooks cited in The Mythical Man-Month; now, we can show that, yes, the design of the organization building the software system is as crucial as the system itself.”

Bruce Eckel: 5-2-03 Strong Typing vs. Strong Testing

Random Thoughts: TDD is not test-first. TDD is specify-first and test-last.

97 Things Every Programmer Should Know: Uncle Bob: Speed Kills:

If you want to be a professional, if you want to be a craftsman, then you must not rush. You must keep your code clean. So clean it barely needs comments.

Coding Horror: The Xanadu Dream:

Consider the reality of what’s actually possible, what people can understand, and what us all too human programmers can practically implement. It might not be the Xanadu you dreamed of — heck, it might even suck — but it’ll at least have a fighting chance of existing in reality rather than fantasy.

Dare Obasanjo: Duct Tape Programmers and the Culture of Complexity in Software Projects:

The urge the reduce the complexity of the tools used to solve software problems is one that every software developer should share. However even more important is reducing the complexity of the actual solutions that are delivered to your customers at the end of the day. End users can’t tell if you used complicated C++ techniques like template metaprogramming and mixins to build the application. They can tell when your application fails to solve their actual problems in a straightforward way or is so late to ship due to project delays that they lose interest in waiting for you to solve their problems.

Old classic essay on software artistry/craftmanship: “Hackers and Painters”, by Paul Graham

Paul Graham: Hackers and Painters:

When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work– that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

I’ve never liked the term “computer science.” The main reason I don’t like it is that there’s no such thing.

…For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you’re writing them, just as writers and painters and architects do.

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

Make sure to read the whole thing.

I’ve disagreed with Graham on a number of things over the years. In particular his assertion that “good hackers prefer Python to Java” (note that ‘hacker’ in this context refers to a software artisan, not the caricature you see on TV), but as I get older… well I’m appreciating Python more and more and my realize just how right he probably is.

Programming (software artisan/craftsman?) Links for October 7th, 2009 – Don’t be an engineer – be a craftsman, be an artisan

Andrew Hunt and David Thomas: The Art in Computer Programming

Design By Gravity: Don’t be a Coder, Engineer, or Developer: be a Software Artisan!

Linux Journal: Everything Your Professor Failed to Tell You About Functional Programming

Peter Seibel: Unit testing in Coders at Work