Editing your Software

The crew over at 37signals makes a great breakthrough in terminology by declaring that software needs editors. That’s a wonderfully succinct definition of a role that has not been talked about a lot in the past. The general process is “business owner” comes up with ideas, analysts distill those to requirements, and finally developers implement requirements.

That leaves the “business person” responsible for editing the features, and completely in charge of the process. I suspect this works reasonably well in software for sale markets, because the business people are really just proxies for customer demand. Presumably they are looking at all sorts of marketing data, customer surveys, customer behavior, etc. to determine what features should go in. Their core competency should be this editing role.

In “enterprise” development, who performs the editing role though? The business people should be experts in their domain, be it stock trading, banking, auto manufacturing, health care, or whatever other domains we can dream up. They are the authors and the writers, and I think it’s the business analysts’ role to act as that editor figure. Not authoring, but shaping, directing, and molding the raw ideas.

I think that’s the analysts’ role because the BA works closely with the developers too. And unlike editing a piece of writing, there are technical concerns around what goes in or out. The complexity and maintenance costs of implementing a feature one way or another, or of leaving it out entirely aren’t up to the whims of the analyst (or the original business owner). It’s really a team effort, but the analysts need to feel empowered to guide the process, and provide data and hard justifications for why something does or doesn’t make sense to be included.

The important thing, like the 37 signals guys said, is that software isn’t just a bunch of checkboxes. When company websites are rated by third parties in terms of checkboxes on a feature matrix, it can be easy to forget that what’s good for your rating might not be best for the customers.

Do we want scientists or engineers? Neither.

Alex Hung asks Do we want scientists or engineers? for developers. If you’re talking about the current output of computer science vs. software engineering curriculums, I don’t think it matters much. Neither has the skill set straight out of college to be effective, and if the person has the potential, both are equally as likely to grow into good developers.

The activity of software development (in a business context that I’m used to dealing with) is not computer science or software engineering although it contains shades of both. It also contains a lot of written and oral communication, a little bit of aesthetics, some history, and a lot of information about whatever domain the software lives in. The most valuable people in a business software development environment consistently seem to be those that bring those extra skills to the table.

I rarely find it to be the case that the smartest developer, or the best coder, or the most educated is looked upon as the best developer on the team. How to identify and teach the extra skills that make up the discipline is still I think and open question.

What does a business analyst do?

I noticed a while ago that if you go to the International Institute of Business Analysis web page, click on “About”, and then go to What is a Business Analyst? you get a blank page.Okay, so you if then actually click on the “What is a business Analyst” on the blank page, you then find out:

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

I think if you boil that down to it’s essence you get a good starting point, but it doesn’t really get to the core value. “enable the organization to achieve its goals” is the core value proposition in that definition, but that’s every employee’s goal, so it doesn’t seem that interesting. So I’m setting that one aside and making my own (it wouldn’t be deconstructing the role if I didn’t start with an alternate position).

A business analyst facilitates turning ideas into working software, and evaluates the success or failure of that software against the business goals.

You could tweak the “working software” part depending on exactly what sort of business the BA was working in, but that’s the one that’s right for us (we build the customer-facing website for a financial institution). It’s a wide open definition, because I see the BA role as the glue that brings teams and ideas together. Modern software development teams should understand the business, the domain, the problems, and should be perfectly capable of sitting next to an actual business person to define requirements or stories. But in a large organization, just finding and keeping track of the real business owners who deeply understand the business model can be a full time job.

So my working theory is that the modern BA is a coach, relationship builder, secretary, gopher, project manager, etc.. It’s a broad skill set, and one that’s challenging to find or develop in people. The other option is to retreat into documents. Talk to the business people, turn what they say into written requirements, and hand them over to developers. I think that’s not the way to go. The BA role sits in what I think is the best place to manage the end to end life-cycle of a system.

Review: Behind Closed Doors

I just read and finished Behind Closed Doors over the weekend. It’s a very quick, very good primer on how to be a good manager. I’m spoiled because I’ve worked for an absolutely fabulous manager for three and a half years now that does everything in this book and more. I’ve done a lot of reading on management (for a developer), and I recognize lots of bits and pieces from other books in this book (yes, they are properly attributed).

So this book is a great, simple place to start for new managers. My one criticism is that it almost makes it look too easy. The difference between bad, average, and good is fairly subtle, and I don’t know that if you haven’t been studying under a good manager that it would quite as obvious how to proceed.

For me it’s a great start though; a quick retelling in a practical sense of a lot that I’ve read over the past year or so, with a lot of restatement and checklist-style presentment of things you can use to remind yourself of what you should be doing. And then you have all the references to follow up on, which you’ll need to because there is very little discussion of the theories behind these ideas.

Still, very fast read, very practical and useful immediately for beginning managers.

I’m here on purpose.

I’ve been writing software to support businesses for 10 years or so. First as a system administrator then as a full time developer. I’ve worked on systems large and small, for many platforms and on many languages, and solved many thorny technical problems.

 So now, somewhat to the surprise of my friends and co-workers, I’m switching gears. I’m moving into business analysis. The idea was first posed to me by a friend of mine who wanted me to work for him. It didn’t take long to decide that this was the direction I wanted to go, and now here I am, starting in a new direction as a business analyst.

The why in “why do you want to do change roles” is simple. I know what I’ve seen with my own eyes on projects; those with good to great BA’s deliver better software without burning out the team. When the BA role goes missing, as it so often can, you tend to end up with software that just doesn’t do what you want. So I want to see if it’s a role I can develop, institutionalize, and make a bigger difference in the quality and quantity of what we deliver to customers at the end of the process.

I’ll be sharing more thoughts about the role as I have them, and tips, tricks, or whatever else makes the job easier. Wish me luck.