General discussion


Reforming Software development department

By ammarcs ·
i recently joined an IT company, as a Senior developer / Project Manager in the Software development deparmtent.

most of the developers are junior and each developer is handling projects on his own.

there is no standard way of development and no documentation and the developer handles the project from A - Z.

developers are feeling so stressed because they are facing clients and face the burdern of any mistake and delay.

and recently one developer has resigned and so the department are in a chaos because there is no documentation for the projects he handled.

i am looking for articles or advice about how to reform such a department and set the standards and quality assurance and keep every thing under control.

Thanks in advance

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Keep ?

by Tony Hopkinson In reply to Reforming Software develo ...

Gain is the word you are looking for.

The 'on his own bit' is killing you.
Standards, get together and come up with a framework jointly, apply and evolve them for new developments. Try and assign two people to a task, one very familiar to review and help, the other to do.

Applying them to existing software, is something they are going to have a look at on a case by case basis.

Don't get bogged down with foolishness like where the braces go, or how many spaces to indent.

Naming conventions, templates, frameworks and stragegies (eg avoiding side effects, are the key.

At the moment you don't have a department, you have several people under one on an org chart, that's where I'd start.

Collapse -

Training and audit

by k_arpad In reply to Reforming Software develo ...

I agree what Tony said about standards, templates and documents.
Your problem lies here: if your projects are so small, that only requires one developer ("one man show"), then the best way the developer handles the project from A to Z.
If you try to split the work between people (like developers and people handling the customer), it will be a disaster due the overhead.

So your job is to figure out how to do one-man-show with quality.

First, you need templates and documents. Do not expect the developers to produce large documentation, focus only on the minimum.

Second, train them. Explain the documents and how to use them. Train them how to avoid usual mistakes. Probably they are eager to learn from an experienced person how to handle certain situations. Probably they failed in the past because of the lack of experience.

Third, change the people. It is not easy. Even after the best training, when the developers go back to work, they will do everything the same way.
So take your best developer and your best project, and with strong hand coach him to use your templates and methods. Make this project as an example for the department. After the guy understands the way and follows it focus on the next developer.

Fourth, establish audit. The develoeprs should know that the project is not their private issue.
It is good for them because if they are sick or want to go to vacation, somebody else can step in. Slowly begin to intoduce the audit.
The fact that somebody else checks the project will improve the quality. The goal of these "audits" should be mentoring and help (giving advice), not the punishment.

Collapse -

In a Position to do Anything?

by Wayne M. In reply to Reforming Software develo ...

The steps to be taken will differ based on the precise position within the company. I say this because a title like "Senior developer / Project Manager", especially in a company where each developer handles his own projects, does not sound like it carries the authority to direct the work of other developers; I would expect a title such as "Software Manager" or "Member of the PMO" for such a role.

From my assumption about the current role, I would suggest a three part approach. One, personally implement what one feels are appropriate standards for one's own work. Two, discuss areas of concern with like-minded peers and develop some voluntary work standards. Three, identify those in a position to make department-wide changes and recommend, and volunteer for, a study group to determine department standards.

The desire to try and improve conditions is a good one, but one must also recognize the boundaries of one's sphere of influence.

Collapse -


by Tony Hopkinson In reply to In a Position to do Anyth ...

Get everybody together, come up with some stuff that will benefit everybody and then present management with a fait accomplit.

A place as badly run as this would probably implement some shelfware case tools endorsed by some academic in an ivory tower somewhere.

Collapse -


by ammarcs In reply to Nah.

yeah tony

thats what i think and thats why i am planning to change, because am sure if they continue this way, we will reach to a dead end, and the company will suffer alot.

what you are suggesting is pretty fine and i think it will help alot.

i am lookin as well for books that will help me and guide me step by step into such a process.

Collapse -

Beware of silver bullets,

by Tony Hopkinson In reply to exactly

magic wands, and all other the only way way to do is X. If it were that simple, no one would get in this sort of mess.

It's all bollocks, the 'team' is where it is, through aggressive neglect, incrementally improve. Don't look at each step as low hanging fruit, but as another stone in a solid foundation.
Look for where you are solving the same problems time after time, being slapped in the face by the same gotchas, the mind numbingly boring stuff you always want to fob off on the less alert. Engineer them out, bit by bit, app by app.

Collapse -

Minimum Standards

by daniellgtr In reply to Reforming Software develo ...

I recently attempted something similar at my own organisation. Beyond the excellent advice that the others have already posted I would add that what my project teams most wanted to know is: what constituted the minimum standards?

Defining what constitutes the minimum standards for the types of work products produced, amount and type of documentation and performing reporting and communication should be defined.

I ended up producing a high level "policy" document in conjunction with my teams as to what the minimum standards for a project would be. That was of course backed up by resources such as templates, good examples, checklists etc... Many of which were not already available but I put together.

We also initially set up a process of gating at either key milestone or phase end points where I was involved to ensure consistency, quality, and that we really were meeting our time and budget constraints.

So what is currently working is providing that guidance as to the minimum standard and giving the teams the freedom to work within that to define their own plans and more detailed templates etc... while still ensuring a level of management oversight.

I would also suggest that you treat what you are attempting to do "reforming the software development department" as a project in itself, with a plan and clearly defined goals.

Collapse -

treating the whole process as a project

by ammarcs In reply to Minimum Standards


this looks like a better approach, i was just thinking of fixing without a clear goal of what we want the department to look like at the end.

dealing with it as a project with clear defined goals will help alot and will show the progress.


Collapse -

Facing same problems in my department...lets discuss and overcome it..

by hi2rhythm In reply to Reforming Software develo ...

I am web developer , project leader and facing same problems for managing my lets discuss how to overcome and manage these this things...
waiting eargerly.......

Related Discussions

Related Forums