An interesting subject came up at the post-presentation hangout of this evening’s CharmCityJS Meetup. I was talking with a fellow attendee about the fact that I’d rather be an analyst, requirements engineer, and architect than a full-time coder (not that I don’t want to be deeply involved with said code, even to the point of helping write and automate it) while he had transitioned back to being a full-time developer from being an analyst and architect.
For him the sweet spot was in the implementation, and he never liked the push and pull of his charges and his bosses providing their inputs into and feedback about his designs. He felt that the inputs coming up and down to him conflicted often enough that he could rarely make everyone happy.
My thought is that I want to be analyzing and engineering requirements to address the needs of the customers (external and internal), and meet the needs of the bosses. My thought about making the developers happy, and this came up in a conversation I had with another insightful individual last week, is based on writing the requirements in such a way that the developers have maximum leeway (subject to company policy, tooling, and so on) to give me what I want in the way they want. The way to do that is to write the requirements at a high enough level of abstraction that they can use a lot of different hows but I can’t help but get my what.
I can comment almost endlessly here. To begin, how does one describe this level of abstraction ahead of time? The answer, of course, is that one can’t, really. You just have to have a feel for it on a case by case basis. I know what you can’t do, though.
At the last Baltimore chapter IIBA meeting someone gave a presentation on a requirements authoring tool. It was a flowcharting program with a lot of automated analysis and testing functionality that could be used to represent a design at any level of abstraction. The speaker worked through the demo at a level of detail that was very close to writing the code. I suppose some organizations may want to work that way (bigger companies may have the mindset that they want to pre-specify as much as possible so each part of the value-added chain has the least leeway and can thus make the fewest mistakes), but that methodology didn’t sit right with me. I’ve never written requirements that way unless I’ve been asked to write out specific algorithms or calculations.
Remember that the analyst/engineer/architect is going to be working with the developers in an iterative, cooperative way so they can both provide their best inputs into the solution. I have some pretty strong ideas about things sometimes but I’m not going to just fling work requests over the transom to the next group and expect my wishes to be fulfilled exactly without interaction. Not only is the interaction better for the product and project at hand in the short term, but it’s better for understanding, camaraderie, respect, education, and — dare I say it — fun, in the longer term. Working this way with customers should be a given, and one always hopes to be able to work with bosses in the same way.
The insight from the conversation was that everyone has a boss. Richard Branson and Bill Gates have bosses. They’re called customers, and they’re ultimately the most demanding bosses of all. The question is about how you like to receive and process your “orders” (from all directions, and again, internally and externally) and how much leeway you have to fulfill them.
The fellow I talked with didn’t like to receive his orders the way they came in his role as an analyst and architect, but he does like receiving them as a developer. I can go either way, given the right style of communication and the right environment, but at this point my passion is to make things easier at the sweet spot where I think I can do the most good. I think serving in the analyst/engineer/architect role allows me to shape the interactions in all directions to provide the most effective, cooperative, productive environment possible. This is based on my experience serving in many roles in the SDLC and as a manager/mentor and subordinate/mentee, and the success I’ve had in identifying, implementing, and delivering effective solutions.
Now I wonder if my companion might have preferred his original role if the communication or environment had been different. I’ll try to remember to ask him next month. Until then I’ll be thinking about how I can create the best communication and environment I can no matter what I’m doing, which has been my true mission for the last few years, if not longer. Getting the technical part right is usually much easier than getting the people part right.