Today we were setting up for a big integration test with a subcontractor. One of the engineers found a small porting issue that I needed to fix.

So, I made the small tweek and rebuild the EAR.

Well, lo and behold, one of the other engineers decided to completely change the way that the classpath is defined in the build file. He wanted to make it "cleaner." Well, I wrote that classpath definition a particular way in order to allow me to add specific JAR files to the EAR post-build.

So, I deploy the EAR to the server and notice that the product is shitting all over itself with linking errors because it cannot find the libraries it needs. So, I spend over an hour rolling back his changes and, thus, the subcontractor was waiting for an hour because this ass decided to "fix" something without telling anyone.

I will say that this is probably partially my fault for not creating a staging branch in source control, but I rely on my other engineers (who are the best engineers in the division) not to fuck stuff up.

This guy has a history of this behavior, too.

I wish that I could just code the whole product ... I've already coded more than 90% of the product. Everything was fine before everyone else started "helping" me.

That seems pretty common.

As a fellow developer...I feel your pain.

It's quite common and is the major reason for CONFIGURATION CONTROL. CC needs to be formal and slightly painful so the people wanting to do changes have to think twice about making changes to 'clean things up'.

framulated amulite?

Application development by commitee rarely, if ever, works. The software company that I worked for finally figured that concept out and put a monster of a change control process in place to encourage people to get it right the first time and test their code BEFORE the actual build. They also put ONE PERSON in charge of builds and now things are so much better. Best of luck to you.

Quoted: It's quite common and is the major reason for CONFIGURATION CONTROL. CC needs to be formal and slightly painful so the people wanting to do changes have to think twice about making changes to 'clean things up'.

I would normally disagree strongly. I HATE process, mostly because it gets in the way. We are smallish team and we've tried to formulate a "startup" atmosphere where people are given big tasks and left to their own devices. We're talking about senior and principal engineers working on this high-profile product; you shouldn't have this sort of shit happening.

Now, I'm wondering if a process would help.

I have no idea wtf you are talking about.  You build EARS?

I design powerlines, I know not what you speak of.

Quoted: I have no idea wtf you are talking about.  You build EARS? I design powerlines, I know not what you speak of.

Software engineering.

EAR = Enterprise ARchive.

Basically, it is a big bundle of java classes that are designed to run on a specific type of application server. Unfortunately, our company, in their infinite wisdom, decided to go with one of the worst application servers I've ever seen because it came bundled with a pretty decent MPI (master person index). I spent most of the first month of development writing an abstraction layer to allow us to seemlessly move over to JBoss.

Sounds like you have a pretty fragile development process.

Quoted: <snip> our company, in their infinite wisdom, decided to go with one of the worst application servers I've ever seen because it came bundled with a pretty decent MPI (master person index). I spent most of the first month of development writing an abstraction layer to allow us to seemlessly move over to JBoss.

What app server are you using now?  Although pricey we were using WebLogic and didn't have many issues with it.  However, I was pushing for JBoss.  Couldn't convince the corporate brass to go with a FOSS solution even though they have great support plans if they really wanted to point a finger at someone in a crisis.  Sadly we kicked BEA out of the company after some licensing issues and we converted our primary procurement system to .NET...oh well...can't win them all.

Since you have a small team I would think that some better communication/process may also help.  I do get pretty anal and check source code changes every morning before doing a "get latest" on the tree.

Edited for spelling.

"Rogue changes" are the bane of code deployments.  They happen in our company all the time, in fact we can't even get our CM to hand a finalized package off to ops for deployment.  He has to get in and monkey with the package after its' been deployed to make settings on the fly, outside of CVS, and completely undocumented.  No matter how hard our SAs (who are some of the more experienced in the industry) push to control this, getting done fast always takes precedence over getting it done right.  The result is product outages that are difficult, if not impossible to diagnose without CM present in the troubleshooting process (something they shouldn't EVERY be involved in).

CVS is a mindset as much as it is a technology.  If you can't instill it in your folks, you're doomed to repeat the same painful history over and over again...I know we do.  And I'm just the network engineer who gets called at every outage because the error messages built into our code all indicate 'network unreachable' or some such non-sense, which our Tier-1 support group assumes to mean 'network problem', when in fact what's really happening is that the code is black-holing customer requests.

God I hate that crap.

Draw down!

Quoted: CVS is a mindset as much as it is a technology.  If you can't instill it in your folks, you're doomed to repeat the same painful history over and over again...I know we do.

+1.  At the project I'm on now I asked for some sort of VCS for the development team (me and one other guy).  I was told "Well, there's only two developers, so you work it out."  Basically it boils down to: I don't change your code, and you don't change mine.  If a change is needed, tell me what you need and I'll do it.

ETA: At my last job one guy was notorious for making updates... on the production servers... and then not documenting them or putting them into the code that was stored in the VCS.  Last I heard he was still there; most other developers got frustrated and left.

It doesn't sound like it's the guy's fault.  Sounds like the process is broken.

Ty

Coding via a "team" takes SO MUCH LONGER.........

Being a loner coder is much better and more productive.  Granted big companies can't have just one dude coding.......... I'm speaking more from the small company aspect.

So the next job you do with this clown, before you get too deeply involved, just ductape his ass to some cold-water pipes in the basement and tell everyone you sent him for cigarettes or something. Problem solved.

Let me on your team.

I can program in Basic, assembly code (for a Commodore), and C.  No not C+ or C++ or whatever + they're on now.  C.

Side benefit, I still have a copy of blitz somewhere and our final product can be really fast.

I can't be much worse than some of the guys on your team lol.

Quoted: <snip> I asked for some sort of VCS for the development team (me and one other guy).  I was told "Well, there's only two developers, so you work it out."  Basically it boils down to: I don't change your code, and you don't change mine.  If a change is needed, tell me what you need and I'll do it.

IMO you ALWAYS use some sort of source control.  I do it even on with a team of one person.  It looks like you understand that but the other guy doesn't.  I can't imagine doing without it.  Especially, when you have multi-environments (dev, qa/staging, production).  Then there is versioning and having the ability to roll back when needed.

Quoted: Quoted: <snip> I asked for some sort of VCS for the development team (me and one other guy).  I was told "Well, there's only two developers, so you work it out."  Basically it boils down to: I don't change your code, and you don't change mine.  If a change is needed, tell me what you need and I'll do it. IMO you ALWAYS use some sort of source control.

+1

There is no excuse not to. SVN takes 10 minutes to install and configure on a reasonable Linux machine. It has a windows plug-in (Tortoise) that is extremely easy to use.

www.youtube.com/watch?v=-ktvs4YZt7g

We were using MS Visual SourceSafe at my last job.  Clunky to use, but once you get used to it it becomes fairly easy.  However, one of our guys didn't like it and changed everything over to CVS.  And he did without telling anyone because he wanted to do it right then.  What a nightmare.  All of our projects were delayed, all of our test environments were worthless, and we were just totally screwed until he got everything straight.  And to make matters worse, he didn't put everything on CVS, so now we had to deal with two VCS products at the same time.
I was pissed, yet when I said something, management said, "What, you're against change for the better?"

Quoted: CVS is a mindset as much as it is a technology..

Switch over to SVN (Subversion) -- much improved version of CVS.  You won't regret it.

- CD

First incident:
Second incident:
Third incident:

Kharn

I haven't a clue what ya'll at talkin' about, but you might try a bigger hammer. Was any of that OP in English?

It's fun bein' 50 and only usin' puters cuz ya want to, not because you have to!