The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Deciding on a common development approach for a team

Folks,
The firm I have just joined want to introduce some form of common methodology/approach for system design amongst the various developers.

The existing guys mostly do their own thing and in their own favorite language. Two of these folks do most of their developement in c#, two others (including myself) are more experienced with vb.net.

I myself have been mostly working on my own within large intranet environments for over 8 years, covering many roles such as analyst/dba/developer etc. I have worked with groups of process/electronic engineers and alongside  finance or IPNET groups, but I have not much experience of working with other devs. I would like to describe my own design methodology as "agile" but in reality that was a function of the environment, where scant requirements meant a lot of iterative prototyping and small releases. "Firefighting" would better describe it.

As the oldest of the group and the new guy, I feel the management are looking to me to lead the initiative, but I am not sure where to start. The existing devs bristle when the topic is brought up, and they have been in the firm a long time. I would admit to being pretty weak when it comes to architecture. My approach is invariably to find the spikes, attack them and then look at the design. not good, I know.

Most of the development is based in asp.net, so I was hoping to research further then suggest MVC as the general architecture, and then maybe get the guys to agree on a common persistence method (Nhibernate,LINQ or the microsoft architecture blocks).

Any advice would be appreciated.

Mick
mick Send private email
Friday, April 11, 2008
 
 
Sounds like a tough ask, if you already have the feeling that the other developers are not so happy with your suggestions!

I suggest introducing one new thing at a time, slowly, maybe one new concept a month. Changing to a "unified wonderful architecture and methodology" all in one step would be very difficult.

Perhaps make a list of various recommended practices that you are not current using and start with the "low-hanging fruit". Some examples:
* coding standards
* code reviews
* unit tests
* nhibernate (maybe this one is a good start)
* nightly build
* continuous integration
* and so on

Perhaps you could get some buy-in from the other devs by getting their suggestions for practices/techniques they would like to use. Then together you could all decide which of all the suggestions would be an easy but rewarding starting point.

Good luck with a somewhat difficult task!
Steve McLeod Send private email
Friday, April 11, 2008
 
 
Thanks for the suggestions Steve. That all makes sense.

I suppose at the end of the day I do not want to be putting forward proposals for approaches about which I have not a lot of expertise. Personally, I am hoping to refine my craft and add discipline to my design approach. "Showboating" is not my intention, but it could easily be interpreted that way by folks who are still undecided about the "new guy".
mick Send private email
Friday, April 11, 2008
 
 
Difficult task.

Ultimately, you need to understand why you are doing this. "Because it seems the right thing to do" isn't enough. You need to point to specific problems that have occurred because of they way things are.

One of the simplest methods to do this is to introduce a bug tracking database. This will easily highlight a problem if there is one, and initial resistance from the developers can be overcome once they see the list of fixed bugs growing, and outstanding bugs reducing.

Once you have this and everyone is happy with it, you can start digging into the database to try and spot any patterns. If there are bugs in there that makes everyone feel uncomfortable, find out what caused it, and what could you have done to have prevented it. You can then instigate changes and overcome resistance because you have evidence of an actual problem you are trying to overcome.

Remember you are only trying to facilitate this change. It will work best if you let the others decide on the actual changes that need to be made. Think of yourself as the chairman of a meeting.

I don't think the actual technologies are your problem. You touched on it when you described firefighting. From your initial post, you seem to be looking at specific technologies, and trying to narrow down the variety used. This will only lead to a battle with the other devs, one in which everyone will loose sight of the bigger picture.

Perhaps one of your companies biggest strengths is the diversity of technologies used, so they can pick the best for the job, rather than the compromise everyone agreed on?
IanH. Send private email
Friday, April 11, 2008
 
 
Ian,
Yes a bugtracking db would could be good to bring the various folks together. It would also act as a catalyst for change.
Thanks
Mick
mick Send private email
Friday, April 11, 2008
 
 
> The firm I have just joined want to introduce some form of common methodology/approach for system design amongst the various developers.

You could probably do a requirements analysis on that sentence to find out what they really want.

> As the oldest of the group and the new guy, I feel the management are looking to me to lead the initiative, but I am not sure where to start.

Well are they? Or aren't they? You're suggesting that management have hired you as a team leader, without telling the team that they have a new leader.

> The existing devs bristle when the topic is brought up, and they have been in the firm a long time.

Anyway, I suggest that you be an organizer rather than a leader. The sine qua non is that the existing devs and you meet to talk with each other. Meet regularly. Anyway, at such a meeting I suggest you say things like, "We have problem X. What should we do about it?" and then:

* Try to come to a consensus as a team.
* Sometimes you might agree that it isn't much of a problem and doesn't need fixing
* Sometimes it's a problem that affects only a subset of the team
* Sometimes there's more than one possible solution; in which case you don't have to be adamant about implementing the "best" solution, instead any viable solution to the problem is good enough (sufficient to fix the problem or satisfy the requirement)
Christopher Wells Send private email
Friday, April 11, 2008
 
 
Mic

I think that the key (and possibly the winning) point is to sale to your partners not what they need to change, but what they will gain out from it.

I had a similar situation some time ago. I was leading a team  of system programmers/administrators that had been running for some time and was unwilling to change anything. Our main problem was the lack of documentation and clear procedures for some critical processes. Every time I raised the issue, everybody agreed, but no one did anything,

The way I found to gain their commitment was to relate the quality goals to some personal goals. For example, some of them criticized that the system operators called several times during the weekend to ask "stupid" questions they "should" already know. I related the increase in documentation quality to a lowering in calls and committed to decrease them.

They slowly agreed on this and as they saw that there were a real payoff for doing this "additional" effort, were more and more open to introducing new standards, procedures and documentation.

However, not all of them accepted the changes. Some were still  reluctant and I had the need to impose them the new rules, but as the majority was doing it, they had little excuses. 

Hope this shed some light and good luck.
Pablo Send private email
Friday, April 11, 2008
 
 
Christopher says:
Well are they? Or aren't they? You're suggesting that management have hired you as a team leader, without telling the team that they have a new leader.

No, Christopher, they definately have not hired me as a team leader.
When I say the team bristled when the topic was brought up.. on reflection maybe I have worded that too strong. We have not yet entered into a full discussion regarding this yet. But, when the topic is brought up, you do get the distinct feeling that folks are reluctant. Not due to laziness or obstinacy, more because the benefits are not so clear. I would agree with the folks who have posted that we as a team should focus on what needs to be improved and then plan how to implement a agreed framework for the future.
mick Send private email
Friday, April 11, 2008
 
 
> No, Christopher, they definately have not hired me as a team leader.

In that case you need to work out what your role in this process improvement is. Remember the golden rule - don't care about somthing more than your manager!
IanH. Send private email
Friday, April 11, 2008
 
 
Suggesting "a common development approach" might be what's called "a solution looking for a problem".

Strategically, obtaining buy-in from the team might be a two-stage process:

a) Yes, "X" is a problem that we'd like to fix
b) Yes, "Y" would be a worthwhile solution to that problem

Tactically, try asking or guiding the team to identify the solutions (and even the problems), instead of imposing a Grand Vision.
Christopher Wells Send private email
Friday, April 11, 2008
 
 
This could be a rough road, since you say you lack knowledge and experience in this area.  You might try working at a different company that already has strength in this, where you can learn from a good mentor.  Then you'll be better equipped to take the lead at your next job.
Mike Stockdale Send private email
Friday, April 11, 2008
 
 
Sounds like the first step would be to try to get down on paper what are the current practices being used.

I've experienced too many times the "expert" coming down from "on high" and dictating what "best practices" "Should" be (I hate that "Should" word).  And typically the 'System' the "expert" dictates has more holes and inconsistencies and Catch-22 situations than what's already in place.

So naturally developers that have a way of working that already works for them are reluctant to change that.

And somehow that's usually the FIRST thing Management thinks of -- "We're working too chaotic, too unpredictable, let's ENFORCE a "Common Development Approach" (CDA) for the team!  That'll SOLVE our 'problem', we'll FORCE the developers to be DISCIPLINED!"

From my perspective I've seen developers trying to develop the best they can with the systems they have available.  If the EXISTING practices they're using can have a little more visibility added to them, that's usually helpful.

But mandating "common approaches" rarely works.
AllanL5
Friday, April 11, 2008
 
 
I'm trying to do exactly the same things as Steve McLeod suggested! Interesting.

Good luck, it's not easy.
Davide Vosti Send private email
Friday, April 11, 2008
 
 
Mick,

You have concerns about your ability to lead the initiative. Fair enough.

Instead of a lead, how about a facilitator?

Here's my thinking:

1. Everyone has some "pain" in their day.
2. Find out what everyone's pain is
3. See if there's any common ground
4. Let the team in on what you've found.
5. See if they are collectively able to come up with a common solution.
6. Help get the solution implemented
7. Rinse and repeat until the team members feel safe enough to talk about sensitive issues like development language.

It may not work, but what have you got to lose? Give the team a chance to prove they are mature, responsible adults. You'll gain a lot of respect if you can help them improve their work environment.

Good luck.
Bruce
Friday, April 11, 2008
 
 
Mick,

These is post from Joel, you could use it as a guideline. All 12 steps are too much at once but as pepole have suggested, you could implement each one slowly.

1,2,3 and 4 are critical to have IMHO

http://www.joelonsoftware.com/articles/fog0000000043.html
EdNoWeb
Friday, April 11, 2008
 
 
I appreciate the advice. I shall let you know how it goes.

Monday, April 14, 2008
 
 
Mick, I've been in the same position.  My best suggestion is to build the process in an incremental manner.

Get real-world feedback on the requirements.  Determine the "features" of the process based on what the affected parties (the developers) see as important and useful to them.  Resistance is less likely since they will feel part of a change that makes their working life easier.  They've probably had enough attempts to impose bureaucratic, out-of-touch processes on them.

Gain experience by first working on the most straight-forward, least controversial parts (where possible).

Just like any software that you would produce, treat any product of your efforts (build scripts, unit tests, documentation, etc.) as something that needs to be tested for defects before it is released.  Not just once, but for every change. 

Ask someone for feedback on a new or altered document before sending them out (or at least, try stepping away from it for a day, and read it fresh on the next day.) 

A change to a build or deployment script can introduce a defect and must be testable in some way before truly being used in the real build process.  You can lose a lot of credibility if a new bug brings everyone's work to a halt until fixed.

Evaluate any tool against your requirements.  Something might get a glowing recommendation or be a "company standard" yet still be unsuitable for your team.  (I was once pressured to run Microsoft Visual SourceSafe over a Unix SMB file-system share as a "solution" to Unix source code management.  Running this as a small pilot gave me concrete evidence to give management on why this was a bad idea.)

Less mechanical process improvements (introducing inspections, or changes to defect tracking) could be introduced as a pilot project with a subgroup, especially if those involved are those more tolerant of the mistakes and adjustments that will naturally occur when creating something new.

These suggestions are not just practical.  Those with emotional or political investment in the status quo may try to exaggerate the normal growing pains of a new process.  Validating each process change in some same way will improve your credibility and give some protection against such complaints; of course, it will also improve the results for everybody.
Chris G Send private email
Monday, April 14, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz