Programming vs Planning [closed]

Question

Recently, I have been tasked with more high-level planning assignments due to the lead developer of my team leaving. I hate long-term planning. My brain just doesn't naturally seem wired for it, and I am not interested enough in it to spend the time to learn it (it is hard enough to keep up with the programming side of the picture).

Can one still be a good programmer without being a high-level planner, too?

As a senior programmer, is one expected to be good at planning out the entire product and picking a date of completion?

Answer 1

Detailed long-term project plans are notorious for usually being wildly inaccurate. The functionality of the system will inevitably change before launch, and people usually spend a long time working out the specifics that go into the specification only to have stake-holders give it a cursory glance at best.

You should read more on Agile planning, you might find it fits in more with your mindset. Many Agile methodologies try to find ways to move away from detailed, long-term planning.

Agile methodologies try to minimise detailed technical specifications and documentation in favour of self-documenting code and isolated, atomic user stories and ultimately working software. In an efficient Agile team, there will be a minimum amount of time spent on planning.

Read the Agile Manifesto and look into Scrum. Use Iterative Development and Dynamic systems development method to guide the project.

The main downside with Agile approaches is that you have to admit openly that you don't know the exact scope of your project, and getting management buy-in to this idea can be extremely difficult, and usually takes a while. See this question and answer and this post for some tips on that.

However it is certainly true that as you get to be a more senior programmer you will probably do less coding, but I think that in an Agile team instead of meaning that you write more technical specifications, it would mean you spend more time managing and tutoring the members of your team and making architectural decisions about code.

Answer 2

Yes it is possible. However, if you want to be a good software engineer or software architect that is where your high level planning comes into play. To me, the main difference between a programmer and an engineer has been the ability to see the big picture.

Answer 3

Is it possible to be a good programmer and not a high level planner?

For a while, yes. Is it possible to do this for long? No.

With many employers nowadays it is standard operating procedure to give cost of living industry-competitive raises. If you don't improve yourself, don't try to tackle bigger and harder problems, those industry-competitive raises will price you out of the market in five or ten years. Keep this up and your employer will eventually start to look for a reason to get rid of you, and your employability elsewhere will be drastically diminished as well.

Answer 4

Sure, you can be a good programmer, from a programmer's point of view. From management's point of view is a whole other question. In my experience, being involved in the planning process is the best way to 1) get more interesting programming assignments and 2) get to do them the way you want.

In other words, once it gets down to short term planning, a lot of options are off the table. If your preferred solution would take six weeks but they only budgeted two, you're stuck with what they decided. If you have concerns about something they already discussed in long term planning, they're not going to want to rehash it.

If you're happy with that state of affairs, more power to you. Most people grow less satisfied with that the more experience they get.

The dirty little secret is no one is very good at long term planning and estimation. Better planners are the ones who are aware of their limitations, so believe it or not, you are ahead of the curve. Get some training on accounting for uncertainty in estimation. Look at techniques like evidence based scheduling or scrum, which rely on historical data to show how accurate your estimates are. You will be happier in the long term if you have a larger say in your work.

Answer 5

Is it possible to be a good programmer and not a high level planner?

Short Answer: Yes it is possible.

However, more you get experience with the type of projects that you are involved, the better planning ideas you will have. Ideally, as a programmer we have some approach how to solve the problem or we look for one. Thus, if we know the approach then we may start think about the planning :)

Another possible route is that a programmer who becomes a good planner is also eventually heads toward Project Management. Thus, if you have interest in management of projects you may put some extra effort toward that direction.

Answer 6

Yes and No are your answers.

On the one hand, you're being nudged towards project management. IMO, all good programmers have some degree of project management capability, but they are different skill sets. The ability to plan for the long term improves your ability to communicate with the actual project management. So "no" you can't be a good programmer without the ability to plan long term.

That having been said, project management is a different skill set that appeals to aspects that are related but different than programming. So here's where the "yes" comes into play. You don't have to be a project manager to be a great programmer.

For your specific situation, try to become more objective about what the company needs as well as what you enjoy doing. There a bit too much ego reflected in your question and that's biasing your ability to look at this situation. If you can find ways to contribute more to your employer while still doing the things you enjoy, then you should consider them and talk the matter over with your boss.

Answer 7

Planning and the Bungie-Boss

Dilbert has many strips about the bungie-boss. Our challenges and expectations about planning may be both the cause and effect of leadership curn. My experience at a Fortune 100 company was that in one year, everyone who started the year as a project lead exited. Perhaps this was due to the planning problem. Not sure if your former lead left for this reason, but when your role requires you make a plan with a commitment, if it does not come to pass, often, a deadline related exit is the result.

Organizational Context of Planning

If you are uncomfortable with planning, perhaps you are uncomfortable with being accountable for commitments made to marketing or other stakeholders before the problems to be solved are documented or understood. This is a good instinct.

Planning is an important tool. Don't neglect it. Don't misunderstand it.

Planning is integrally linked to commitments, accountability, and negotiating power. Agile planning has many merits. You should know its techniques, as well as the techniques of planned methodologies. Your organization may have its own approach and getting advice and working with someone who has survived leadership of many projects many be surprisingly helpful.

A Simple Planning Example - Must not be about software...

If a roofing company came to my house to bid on a replacement, if they bid too low, they may lose money on the job, but if they bid too high, they won't get the job at all. Either way, they are out of business. In your new role, if you bit too low, you will run the project until the accountability kicks in, then you will have problems. If you estimate a project with enough padding to insure success by the deadline, they many just pick someone else to lead. The kicker is that you are not like the roofer. He can see how big the roof is, and has historical data about how long that size roof takes.

Becoming a Better Planner

You may wish to consider some kind of training. In Agile methodologies, and most recent planned methodologies, estimation is a team wide activity. Consequently, you should consider getting training for your team as well.

From experience, I can tell you it can be frustrating to get estimates from team members who will put it off, give you estimates they make in two minutes based on the task name without reference to a requirement or feature description or the existing code, or who insist that several of the tasks you list can be done in some fraction of a day even though past projects have spent weeks on similar issues.

There are various project manager training courses and certifications, but I would watch for one that was independently accredited. It might be worth a second thought before choosing to certify with approaches based on planned methodologies if you expect to work with Agile teams (or the other way around).

SLIM is a method invented by Putnam after working at GE and other companies on DoD projects in the 1970's. SLIM is influential, and his company QSM offers a certification that seems to flow out of a tool that they make. Depending on whether your company has adopted their tool, it might have either no value or high value.

Steve McConnell (author of Code Complete) also wrote a book about software estimation, and his company Construx teaches two classes for PDU credits that are accredited through the Project Management Institute. I have his book, and if I wanted to learn about the topic via classroom training, I would probably pick Construx. They also do Scrum training and administer various scrum assessments accredited through Scrum.org.

Another source that could provide great academic training about software project estimation, would be Barry Boehm's group at USC, based on their extensive work on COCOMO and COSYSMO constructive cost modeling which has been used at NASA and other large contractors to estimate very large projects. I am not sure I am a true believer in COCOMO, but I like the empirical work they have done to correlate the effects of scale and cost drivers on schedule duration.

I also found a chapter from a textbook published by O'Reilly that briefly discusses major software estimation methods including Watts Humphreys PROBE and Kent Beck's planning game. PROBE includes a notion that engineers track metrics on their own productivity, then apply them to their assign part on new projects. Planning Game is very highly collaborative between developers and other stakeholders.