A question for programmers out there

[dotswarlock 2,424]

How do you function with your projects?

 

For the longest time, each programmer/analyst in our team (only 3) was assigned entire projects from start to finish: talking with the client, analyzing, creating the database, creating the interfaces, talking with the client the whole time, doing preliminary testing and putting in production, all of this with loose supervision.  We were basically mini project managers for the whole thing.  All of our clients were internal, so there was no notion of billing involved, only correctly estimating the development time, managing our clients’ expectations and delivering a quality product.  It worked great for a long while, but it did kind of “assign” an application to a programmer and did not exactly created a unified programming approach (each programmer has his preferences).  It could also be a bit messy if someone was on vacation.

 

Management is now trying to switch to a model where they create a bank of hours for a project to which they can assign an X amount of personnel on it (whether they have experience with the app or not), but let’s just say that the programmer who originally created the application is a lot more efficient than the guy who just drops in to make a few changes.  It’s also a bit harder to feel personally responsible for the project when you just do a few pieces of it (if you just programmed a configuration interface then it’s hard to feel responsible for how the data is actually processed underneath).

 

The switch in philosophy is not the most pleasant (change rarely is), so it kind of got me curious; how do you guys work as part of a team?  What do you find works or not?  Who is in charge and who is the makes the design decisions; the supervisor who has a rough idea of what he wants or the guy that specializes in the process / technology?  With more than one person working on the same project, how do you ensure that a single project is (mostly) programmed using a similar approach?

 

I’m curious.

 

Thanks!

 

[darkdooku 99]

I'll see if I can address some of your questions:

"how do you guys work as part of a team?  What do you find works or not?  Who is in charge and who is the makes the design decisions; the supervisor who has a rough idea of what he wants or the guy that specializes in the process / technology?"

 

In my experience this varies from company to company and even from manager to manager within a single company. One method I've seen work pretty well is to keep as much of the project development open/transparent as possible. There's nothing more frustrating than being left in a black box working on your own little piece of code and only knowing what your other teammates are working on when you happen to step on each other's toes modifying the same section of code. Quick team meetings(<10 minutes) once/couple times a week to keep the team up to date on what everyone is working on and any major issues helps create a sense of team and also helps from a management stand-point keep track of how the project is moving. As a programmer if you are more familiar with some code that someone else is working on, offering up your help/assistance if they need it is always a plus. It may not help you get your work done but helps fosters a more team oriented environment showing that you want to help others improve themselves and the common project you're both on and also makes sure the information isn't lost in the event you get hit by a bus/leave the company/have a bad case of amnesia. Additionally maybe further down the line they'll be able to help you solve some problem/learn something new etc.

 

In terms of who makes process/design decisions. I think it's important for a manager to have a clearly defined design/development process for their programmers but allow programmers the freedom to design the code they will be working on themselves. Reviewing the designs as a team prior to execution to get group feedback can be very helpful at times but at other times tedious and can lead to long meetings of back/forth between opposing approaches/ideas, so take that with a grain of salt.

 

"how do you ensure that a single project is (mostly) programmed using a similar approach?"
 

Company coding standards and actually enforcing them will go a long way towards helping ensure a more common code base. Everyone has there own way of solving problems so you can't guarantee that all code will be written the exact same. Reviewing code changes (either as a team or by a team lead/senior programmer) and giving feedback to the implementer prior to committing them to the common codebase can help make sure code generally follows conventions set forward and also helps in the QA department to catch errors before they are exposed to the test team or client.

As companies/projects grow it becomes harder to have just one person handle everything and I imagine it will be difficult for some people to switch over to the team environment but I can tell you from experience if you have a good team of developers working with you, and you can communicate ideas/issues to each other well, and can accept constructive criticism on your work and give it to your teammates too it can be a blast to work on projects together.

Edited January 13, 2017 by darkdooku

[dotswarlock 2,424]

Thanks for the feedback!