告诉我的经理，有一个计划是很重要的[英] Telling my manager that having a plan is important

问题描述

The question:
My manager currently believes that design is important, but not crucial for all but the most ambitious projects. It is my opinion that he thinks it is important to design, but not necessary and that big ball of mud programming can 'get the job done.'

What are some methods of discussing (topics, examples, etc) the importance of planning and design? I'm looking for things to do, say, or change that are within my power as 'code peon', so answers such as, hire another senior, fire weak members, etc. aren't very helpful to me.

Alternatively, is he right and I'm the one who should rethink my approach to development?

Some background:
Essentially, our team consists of three strong developers, a few weak developers, and some people who, in my opinion, shouldn't even be in the field.

We have no dedicated architect, so the three strongest developers who act as unofficial team leads are somewhat looked to in order to design all but the most trivial of projects, unless the manager decides that 'ball of mud' is good enough. They are also responsible for their own (some times multiple) ongoing projects while mentoring and helping others. This leads to an acceptable, but full work-load from week to week on these individuals.

My point of describing the background is three-fold for this team:

1. There is little time to peer-program, give training sessions, and code reviews have fallen off the map. In other words, the weak must learn on their own.
2. When the weaker members are given a project and allowed to simply start coding without thought, the development takes longer, spends way more time in QA, and is such a maintenance headache later, the senior three are scared to even touch it.
3. The weak team members generally have the attitude but not the aptitude, or vice versa, but no one among them seems to have both.

To summarize:
The manager is an intelligent, though stubborn man who will listen to reason, but you must convince him thoroughly of the 'why'.
There is not enough time currently to inject any training methods that take away from daily duties of development and no one is likely to be hired anytime soon to alleviate some burden.
The only current method of creating better code with the individuals that are available on the team is by designing their projects for them and guiding them through the process of implementation, thus, we have this question.

Edit

I wanted to consolidate what I've taken from the answers so far; Some of these are intuitive, but not something most think about from day-to-day (imo):

Managers like metrics. True, but as M. Fowler believes (and I agree) productivity and quality is immeasurable. Besides, I don't have the means to accumulate the metrics as 'peon'. (thanks Novelocrat & duffymo).

There will always be a mix of talent, you must present a learning environment We are supportive in this in attitude, but I think other tools are needed to create this environment. (thanks duffymo).

Engage the weak, alleviate the workload of the strong In addition (as a result of?) to presenting the learning environment, engage the weaker developers in strengthening their design skills by giving them small, atomic parts of the project to design (with approval) themselves. This removes responsibility from the stronger devs, teaches the weaker, and may be an acceptable solution for the manager as it doesn't take time from his higher paid employees. (thanks duffymo & Tom Anderson)

推荐答案

2 words: Notepad Architecture

You can't change the bosses way of thinking, unless you become the boss, in most cases.

You say there is no "time" for design, and thinking about the projects that are assigned, for in depth design meetings and code reviews, etc... I would agree.

The first step you need to do is get your "leads" more approachable. The biggest part of being a lead is being a leader, which means they have to be trusted and respected in order to successfully lead anything.

The next step is to start getting the jr. developers thinking before acting. It is quite common for most developers to just want to dive into code, but taking a few extra even minutes can spell a success over a failure. I would assume you get "something" whether verbal or written about what work to get done, with that assumption, try the following.

In Notepad:

Write down the task that needs to be done (program, feature, whatever).

Write what things need to be done in order to accomplish this task at a component level.

• "Add new fields to table"
• "update existing objects with new field"
• "Add new service call for getting cheese from grater"

After they have finished pointing out what they think will need to be done, have them goto one of the leads and ask him what they think, the lead would then take just a few moments and either agree with their notes or suggest different ways of handling things and check to see if anything might be missing by asking the jr. developer questions about the domain they are working in, not by looking through and doing it for them.

Now you have a semi-detailed project task list as well as a basic design for the system.

Next have your leads take a coffee breaks worth of time to go in the morning and ask the jr how there project is going, and show him some of the design. If the design could use some improvement, take an additional 5-10 minutes to explain the better way and suggest an implementation of it, don't do it for them, guide them to be successful.

So, in conclusion if your leads can take an extra say 20 minutes a day, and your jr. developers take an extra 30 minutes before diving in, you should save tons on the after end in nightmare maintenance and QA cycles.