Telling my manager that having a plan is important

Question

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)

Answer 1

Hi, and welcome to stackoverflow,

This question is very hard to answer IMHO. But it looks like you would need something like SCRUM .(see http://en.wikipedia.org/wiki/SCRUM )

This would help your seniors get the overview over the projects and the tasks the developers are on and problems are catched early.

But honestly, i can't give you an exactly right or wrong answer, there is no: change this and this, and it will work.

Read about Software Development Methodologies (http://en.wikipedia.org/wiki/Software_development_methodologies) and find a method which fits your (or your company's) needs. Often this will be an agile (like SCRUM) or rapid variant.

But be warned, impelemnting such a workflow is not an easy task, you will need much of calm to get it on track.

Answer 2

A couple thoughts:

If you can quantify your statement to your manager that the weaker team members' projects cost him money due to time wasted in unorganized coding practices and lengthy QA cycles, he might listen.

If you take the time to design the code for your junior members, and guide them through the process without explaining your decisions, they will not have a chance to grow into a more senior role.

If you get rid of (or promote ;) ) some of those who don't belong in the profession, you might open up head count for one productive person, whose efforts would far outweigh those of a few non-performers.

Answer 3

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.

Answer 4

This is a very difficult situation.

You'll always have a normal distribution of programmer - there will be a "best" and "worst" on your team. The only thing you can do is to drag the entire bell curve to the right as much as you can so that the "left tail", weakest developers are still good enough compared to the general population.

What's the mindset of the "weaker" developers that always need help? Do they see it that way? How accepting are they of instruction from you? Do they take correction personally, or do they want to learn?

Is there a learning culture on your team? Are members always striving to improve their skills, learn new things?

I think a lack in that area is your real problem. If your team operated in that way the manager wouldn't matter as much.

Have you tried talking to your teammates? Is the lag due to a lack of planning noticeable enough where others might agree?

I don't know how to script a winning argument here. Managers like metrics. Maybe you can start keeping some that would prove your point. The problem there is choosing meaningful ones.

Be careful: Not everyone sees "best practices" the same way. What is apparent to you could be anathema to others. Talk it through with your team first, before you go to the manager. You don't want to alienate them. It'll help your argument if you have a consensus.

Answer 5

Perhaps you could buy him a good book.

E.g. Software Project Survival Guide which I've started to read. It has some nice checklists that might be compelling—e.g. score yourself by this checklist on whether your project has the essentials for success.

Try Googling "software project best practices" and see what you get. E.g. "Best practices for software development projects". Invariably they will support your goal.

Answer 6

Not a full answer to your question, just a thought.

Having a plan is important. Having a too detailed plan is limitative. You must be able to improvise. Plan for the big picture, act on the details according to the goal of the plan. And be prepared to change the plan if there's a compelling need. Adopt, adapt and improve.

Answer 7

There's an article on Technical Debt that I think would help you in presenting the problem to your boss, and would help you boss understand why you hold your position on this matter.

Answer 8

It is important to note that there are counterexamples. Linus Torvalds has stated that Linux was developed without a plan or overall design. But then he had the advantage of constant control/oversight over the entire lifetime of the project.

Answer 9

A manager's job is to ensure that the work gets done in the most effective manner possible, often however politics, ignorance and ego get in the way of cloud the thinking. The most effective approach is to demonstrate the change by introducing it yourself...take just one issue/problem area (design?) and very visually and vocally demonstrate what you think should take place by implementing it, even if its by yourself and for yourself. As others see what you are doing and realize/witness the advantages of doing it they'll follow. Once you get one process in place, firmly, introduce another. Realize that not everything you introduce will be effective or will take hold, the idea is that you need to keep introducing new processes, trying them out and helping others understand them. No one (well almost no one) wants to work harder then they have to and no one (almost) wants to push out crap code...lead by example in this case and if the manager is worth anything he/she will understand and begin to support you.