Ask Slashdot: Standard Software Development Environments?

First time accepted submitter sftwrdev97 writes "I have only been doing software development for about 5 years, and worked most of it at one company. I recently switched to a new company and am amazed at the lack of technology used in their development process. In my previous position, we used continuous integration, unit testing, automated regression testing, an industry standard (not open source) in version control, and tried to keep up with the latest tools, Java releases, etc. In the new position, there is no unit or regression testing, no continuous integration, compiled files are moved to the production environment basically by hand and there is no version control on them. The tools we are using have been unsupported for 5-7 years and we are still using old Java. I am just wondering since this is only my second job in the industry, is this the norm for most development environments? Or do most development environments try to keep up on technology or just use what ever gets them by?" What's it like in your neck of the woods?

Comments

Its a wide spectrum

[devilsandy]

you were at one end in earlier job and moved to the other end in new job.

No CI? No version control?

[barrywalker]

Run. Fast. This company is doomed without basic software engineering discipline.

Re:No CI? No version control?

[ByOhTek]

I'd have to agree.

Keeping things safe and secure where I work is a challenge, and we have mandates (that are followed) that ALL of our software be within the manufacturers 'actively supported' lifecycle, plus no more than 90 days out of date in patches. Working things as out of date as described in TFS seems like a nightmare in terms of reliability, security and lack of features,

Re:No CI? No version control?

[ranton]

Agreed. From my experience the lack of continuous integration, unit testing, and automated regression testing is the norm, but the lack of version control is simply inexcusable. It's not like it's a new startup or anything; if their tools are already unsupported for 5-7 years then they have been working this way for at least a decade.

Every job you take is an opportunity to build your skillsets and improve your career, and I find it unlikely that this job is the best place to do either. Unless you are able to quickly get management support in your efforts to improve development practices (which could significantly improve your abilities depending on how involved you were with those processes at your last job), I don't see why you would want to work there. I cannot imagine your coworkers are the best of the best, and your IT management probably has no idea how to run a software development group. (I have seen small companies in an uncompetitive niche do well despite such environments, but then again I also know someone who won the lottery)

Then again in this economy at least you are working, and who knows how good the IT industry is doing in your area.

Re:No CI? No version control?

[Anrego]

I'd say it depends on what they are actually doing.

Rigid process and a solid tool set is usually a good thing.. but "room full of coders with a goal" can work in some situations.

As for the norm.. I'd say most companies fall in the middle. You've seen the two extremes. Most places have a handful of critical tools that are very well maintained and kept up to date.. and a whole bunch that are "we should really upgrade that" or "yeah, that's a messy pile of scripts, but it still works" and will usually have something between "20 person process with 8 layers of review and testing to roll the dev version into production" and "I'll just copy the file over after lunch" for their production management.

Honestly the more important thing to be looking at is the people you work with, not the tools they use. The situation you describe would seem to speak poorly of them, but must not judge a book by its cover and all that. Well motivated, focused, and intelligent people can make masterpieces in the shittiest environment.. all the expensive tools in the world can't make a shitty coder produce gold.

Re:No CI? No version control?

[rihjol]

Alternatively, if he likes the place, it's an opportunity to step up and say "here's how we can do things better." If it's well-received, it's an opportunity to show both expertise and leadership.

Re:No CI? No version control?

[nahpets77]

Reminds me of the quote "In Chaos Lies Opportunity"... Sounds like a perfect opportunity to become a "value added" employee by "leveraging" your past experience and introducing "proven best practices" to your current company.

Re:No CI? No version control?

[s73v3r]

Well motivated, focused, and intelligent people can make masterpieces in the shittiest environment

This much is true. But you know what? Having those tools, especially version control, makes things sooooooooo much easier. And since they're so easy to set up, why the fuck would you want to bother without them?

Re:No CI? No version control?

[Chapter80]

I disagree.

As an owner of a software development company, I would LOVE for our team to use a more structured, process-oriented approach. Management support and financial support aren't the issue at my company. It's finding developers who have experience in such tools and processes, and having them embrace such methods.

Sometimes management KNOWS these things have payback, but can't figure out a way to kick-start these processes. Slashdotters frequently make fun of "management speak", and when I start preaching the benefits of regression testing, unit testing, and version control to my team, I see the Dogbert eyeroll, as if I'm the PHB.

So if you have the skills and experience to help your team implement such processes and tools, by all means, do it! Especially if you believe in the processes and tools. Or come work for me, and help me implement such tools and processes.

Then again, recognize that you need to "smart size" these things. Too much process can mean death to a small company.

Re:No CI? No version control?

[Matimus]

I've been in that position. It worked out. It was also much more difficult than I initially thought it would be.

I break my career growth into two areas: learning from the examples of those around me, and learning on my own. To maximize your growth you will need a good mix of both types. There are likely experienced people who can teach you many things wherever you go. What you really need to ask yourself is whether you value the types of things that you can learn from your co-workers in this environment. In this case, they can't teach you much about tools and process. What can you learn? If you can't think of anything that interests you then this sounds like a dead end, and you should probably leave.

Re:No CI? No version control?

[asdf7890]

Definitely worth a try. But do keep your eyes open for ways out in case it doesn't work out well.

Best case: you get he credit for improving the company. That would put you in good stead where you are and help your attractiveness elsewhere if you need/want to move on later.

Worst case: you get somewhere to work until you find somewhere else. No point dropping yourself out of employment until you have a safe exit strategy, especially with the job market the way it is in most places. Just make sure you aren't standing too near any fans, so you've got time to duck if something unsavoury hits them.

Lack of CI and automated testing and such is not unusual at all - you were lucky in your last place (I wish I had that luck!). Lack of good source control is something that you need to fix fast, before it bites you in the arse (and it will).

Re:No CI? No version control?

[St.Creed]

It all depends on how you do it. I've never had trouble but my niece is semi-sociopath and she got fired 9 times in a row. At least I have sense enough to be subtle about it. Anyway, just make a presentation on "things you've learnt at other places" and why it's a good idea. If they don't get it, you can always build your own environment or leave (which I did in one case - they just weren't into development). But test the waters first. Are you the sole programmer under 60? Maybe try and find one guy who loves new stuff and has a lot of influence. Get him on board.

Re:No CI? No version control?

[MozeeToby]

This doesn't happen unless someone high up in the heirarchy is insisting that this is the correct way to do it. If it was as easy as someone stepping up and making changes someone would have done so by now. At best, you've got managers who are oblivious to how much time and money it is costing them. At worst, you have some decades out of data lead engineer who is actively resisting change. Either way this is going to be resisted heavily by someone in the chain. Even if you take your suggestions to the right person and win out you're going to be in the cross hairs of someone who has held considerable power in the organization for making them look like a fool. And you can bet that if anything, anything goes wrong with the transition you will be thrown under the bus if said person is given the opportunity.

As an earlier poster said: Run. Run fast, and run hard. I know you just started at a new job, but I've cleaned up after the messes that places like this produce, working there is going to be a black mark on your resume for anyone familiar with the companies work.

Re:No CI? No version control?

[billcopc]

Sure it is, and that's the route I usually take, but it's ten times more effort than you first anticipate. Even if you don't need to buy any new hardware, you still meet tons of resistance from people who refuse to change their habits.

Just a few years ago, I went through that hell convincing my employer to start using virtual machines instead of 10-year old PCs in the server room. He suffered from extreme sticker shock, would rather buy used stuff on eBay than spend a couple thousand on a white-box 2U server. Those things would fail every other week, they were awfully slow, and I wasn't too fond of driving out to the datacenter all the time to reboot a box or replace an (IDE) hard drive. It was like playing whack-a-mole with hardware failures. It took about a year to convince the boss to toss all that junk out and replace it with a big SAN and a few VM hosts. Just the time saved by not having to support crappy old hardware has more than covered the cost of upgrading to proper enterprise gear.

He finally saw the light, but it took a lot of nagging and teasing to open his eyes. Changing a company's dangerous or stupid ways is 10% technical know-how, and 90% psychology. You need to convince people their work will be faster/easier/better after the change, which often requires something to blow up in their faces before they'll even hear you out. Swoop in, save the day, and suddenly everyone's opening up their ears and budgets for your great ideas.

Re:No CI? No version control?

[superwiz]

Don't be silly. Orthodoxy doesn't thrive because no one has yet discovered an alternative. It thrives because of endemic management practices. A firm which even has a chance falling pray to such chaos can be safely assumed to have "personal ownership" of each project attached to key stake holders. Any change probably requires a careful political negotiation because each stake holders sees it as an encroachment on their territory. Each new guy will try to contribute his view on how things should be only to get frustrated and give up within 6 months. Remember that managers are agents of the organization. They may not necessarily act in the best interest of the organization though. They may very well be simply positioning for their personal long-term growth. And that means managing more people. If they get to fix more "problems" (really put out more of their own fires) and increase their own head count, then they get more visibility and are more likely to move up. The metrics which measure performance determine the motivation of the mid-level managers. If they are motivated by having projects which are unknown to anyone (because they perform near-flawlessly), then that's what they try to achieve. If they are motivated by being able to show "management skill" (ability to push people around whether its needed or not), then they try to achieve busy activity whether it's needed or not.

Re:No CI? No version control?

[Anrego]

Version control, yes.. you'd need a pretty damn compelling argument to say that version control doesn't adds value to just about any dev operation. Even on an individual level, it's nice to be able to make huge changes safe in the knowledge that a previous version is just a command away. That said people do succeed without it (web devs in particular). If it were me I'd work hard to try and introduce it, but I certainly wouldn't run screaming just because of that.

My argument was mainly against other tools and processes. Requirements management, unit testing, nightly builds, release coordination, bug tracking, etc. I've seen extreme cases of teams crushed under the weight of the tools that are supposed to help them, usually because the tools were imposed by upper management who were sold on them mainly using buzzwords. Not saying these tools (or at least a subset of them) don't add a lot of value, just that they shouldn't automatically be bolted on because "that's what you do".

The thing to consider at the end of the day is whether you succeed because of or inspite of your tools and processes. If the later, it's time to look at whether it really makes sense to keep using them.

Run, don't walk.

[badboy_tw2002]

#1. That sounds horrible. If you're looking to do good dev work, time to bail immediately, and next time be sure to ask about process in your interview.

#2. On the other hand, if you're a career climber at this company, you can make huge impacts by driving the adoption of these kinds of processes, and will quickly vault your way to the top of the engineering pile. That assumes that this way isn't the grand design of some really stupid people, or that you don't have managers that will support this. In that case, see #1.

Re:Run, don't walk.

[Smallpond]

#1 can be bad if some manager is just pulling stuff out of a catalog and imposing it on the developers. It can be good if the developers are on board with the process and had a hand in tailoring it to the way their group works. Technology alone doesn't make a good process.

keeping up with the world

[lynnae]

regarding this company's practice. Yes it's common, no it's not a place you should work.

It's common because companies can be very very afraid of change, see IE6.

You shouldn't work there for much longer because you really should be getting experience that will let you move your career forward. How would you show a prospective employer that you have Enterprise experience for example. Or experience working in with distributed version control.

IDE wise, Netbeans, Eclipse, Visual Studio are all the big boys. I've only ever used Netbeans and Eclipse for Java (I prefer Netbeans). I use Redcar at home for Ruby development. And VS at work for .net.

Yes, and yes.

[MrEricSir]

Yes, that's normal.

And yes, you should find a new job. Do you want to become a lazy programmer, or an excellent one? If it's the latter, you're in the wrong job.

Re:Yes, and yes.

[dr_leviathan]

Yes and not necessarily.

I don't think you need to flee your new job yet. If the work is interesting and the company culture is decent then maybe it is worth sticking around. You could help upgrade the company's software pipeline. I'd start by trying to get them to move to a good version control system, then add an automated build system, and then add some unit tests and an automated test framework.

On the other hand, if it the corporate culture is only OK or bad then yeah... flee early.

Re:Yes, and yes.

[Darinbob]

Never flee until you have somewhere to flee too :-) People who say they'd never work in a place like that must not have a lot of experience in needing to take any job they can get. It can actually look bad on a resume to be seen to be job hopping frequently, and it also looks very bad to see a long stretch of no employment no matter what the reason.

I had a job after leaving school that was a complete mess. We didn't even have QA. Everything was seat of the pants, one or two person teams. I set up a make system with my boss and he said "sure, you can waste time on it as long as you get the real job done". Later on I added a script to kick off make on all 5 Unix types we needed (I still had to swivel my chair around to kick off a windows build sadly). So one day he comes in and says "why are you working on getting your bug fix into all the builds?" because I was leaning back in my chair reading the paper. I pointed to the screen and said "I am doing the builds, see?". He was pretty impressed at that and never bothered me again about wasting my time on tools and scripts or cleaning up his older code

Re:Visual Studio

[MemoryDragon]

Actually VStudio is only the most professional way if you are in a windows only world. I do server programming in banks and there you dont even see Microsoft outside of the desktops by miles.
Eclipse btw. is pretty much standard there, although I dont like that IDE to much, I prefer Idea.

Do what is necessary and right

[bondsbw]

When I started, we had SourceSafe for version control, and Visual Studio 2002. That was pretty much it. Now, a few colleagues and I have made CI and unit testing a norm (at least for projects we are involved with). We now use CruiseControl.NET for CI, MbUnit for unit testing, SpecFlow for BDD, and Subversion (VisualSVN) for source control. We have also upgraded our toolkit significantly with open source and commercial tools (such as Resharper, various Red Gate tools, and various control libraries).

The point: be your own advocate. The boss isn't going to care or even know about most of these things. Either that, or find a job where these are already established.

Heh

[hondo77]

Welcome to the real world, sonny. Now get offa my lawn 'cause it's never as green as my neighbor's. ;-)

Seriously, though, different companies are just different. That's just the way it works. Some are seriously great. Some seriously suck. The rest are in-between.

Obvious interview questions you forgot to ask:

[Anonymous Coward]

* Is there unit or regression testing?
* Do you use continuous integration?
* What is the workflow for moving items to the production environment?
* What version control system do you use?
* What tools are you using?
* What version of Java are you using?

Re:Obvious interview questions you forgot to ask:

[starfishsystems]

These are great questions (and there are many others that could be asked as well, concerning a multitude of important aspects of the work environment.)

Asking them tends to reflect well on you, showing your alertness and discernment. Nothing wrong with that. But the way job interviews work, it's you the applicant being interviewed. For the most part, you have to take the cues you're given, starting with you making a trip to the employer, not the other way around. In other words, you're the supplicant. There are often several people in the interview room, and you have the singular burden of responding to all of them. Finally, the interview schedule may, but frequently does not, permit adequate time for you to ask evaluative questions.

I've often found myself in interviews where there is a token "any questions?" moment right at the very end, with all the body language in the room telegraphing, "well, we're done here." Okay, let's agree that this is really dumb. After all, the fit has to work both ways or your placement will turn into failure. But we live in a culture where the employee is expected to adapt to the workplace, not the converse. There's very little acknowledgement that the workplace may be imperfect, or at any rate not easy for just anyone to fit into. If there are flaws, you'll rarely hear them spontaneously presented at interview time. You have to draw them out somehow.

Over the course of several decades in the industry, I've gotten a lot of practice with interviews, on both sides of the desk. Practice makes perfect. I've come to find them quite fun, actually, and that's a great attitude to bring with you. When you're relaxed and enjoying the experience, you can not only participate more effectively in being interviewed, but you can also spare some cognitive focus for picking up clues from the environment. Those clues will help to guide and inform your questions later, to the extent that you get the chance to ask questions. I guess the attitude is that you're bringing your best self to the task, but you're not too concerned about the outcome.

Here's two examples, just for fun. In one case, I was met in the lobby by some anonymous functionary who led me in silence to an interview room in which one school chair (the kind with the wide arm for writing on) had been placed under a recessed ceiling light, in effect a spotlight, in front of a long table with several office chairs behind it. The table was in shadow. This somewhat undersized school chair was exactly square to this long table. A few minutes later, the interviewers filed in, introduced themselves briefly, and began asking questions in turn. Meanwhile, I'm laughing inside. Sure, I'd made a long drive for nothing. There's no way I would want to work in a place like that. All that was missing was the whips and handcuffs. But on the other hand, might as well have some fun now that I'm here. So I moved my chair out of the spotlight, placed it at a casual angle where I could also see everybody's face, got nice and comfortable while making a couple of introductory comments on my own, and then said, well, let's get started. In retrospect, it was a very empowering experience. I totally outclassed these guys. Of course I wasn't offered the position, but then I wouldn't have taken it anyway.

Another interview ran well overtime, we were so interested in talking with each other. It was led by two scientists, the principal investigators in a research lab. They were wearing suits. I didn't know how to interpret that, at the time. I ended up working there for 12 years, one of the best times in my entire career. Turns out that these guys almost never wear suits, only on quite formal occasions. Why then did they wear them to the interview? As best I can tell, because they were treating the prospective employee as an honored guest. Wow. And that's the kind of people they proved to be.

Getting back to the kind of questions one might ask during an interview,

Re:This is the norm.

[cornface]

A lot of the times things like this don't help the bottom line.

I've worked with a lot of developers who get on a kick about this development methodology or this version control or this framework or this pattern and if given any sort of leeway will shoehorn it into every single thing they have even a small stake in.

Sometimes there is a good fit, but often it is just adding pointless overhead and complexity to something that doesn't need it.

Re:Too many tools are a waste of time.

[bondsbw]

Any development tool beyond a print statement is over-engineering.

I hope you didn't use a web browser to make this comment. You wouldn't want to over-engineer your web experience, after all.

Cost and size of company

[Synerg1y]

To answer your question better, I would have to know the # of employees at both companies aka size and the IT budget. The question to ask is are they giving you the tools to be successful. To directly answer your question though, yes for smaller IT shops it's the norm, for dedicated IT service companies and larger corporations it certainly is not. Enterprise environments with the project flows you speak of all cost money, a lot of, system debuggers, analysts, QC are all people the bosses need to hire, and they do not usually come cheap.

Also at smaller shops it is up to you to take the initiative to upgrade usually since there is nobody else to do it and the bosses are typically busy with other stuff. As long as you are comfortable in it though it doesn't matter. What you'll notice is the standard is also lower, most CEO / boss people aren't ignorant / stupid enough to think that a smaller IT crew can produce the same quality as a bigger one, so everybody just rolls with the bugs and punches until a working product is ready.

If this is an IT firm though, and they are running outdated software, then chances are your management team is NOT IT and that is usually a good sign to run. I've only truelly enjoyed working with IT people when I approach the coding realm, and everybody else is kinda meh, but you do what you to to put bread on the table :)

As you become more independent though and possibly as your skill range widens, you may find things work out for the best in your career as there are more job paths to take. A common one is sql developer to sql dba, they are so closely related, experience can jump you from one to the other.

I'm basing this all on your going from a larger well organized shop to a smaller to less organized one based on you naming the practices and lack of. I guess it's always possible to have a shitty large IT shop too, just talk to Sony :)

Re:Cost and size of company

[shutdown -p now]

Even for smaller shops, it's definitely not the norm to have no version control at all.

Well, at least not for shops that are worth working at.

Re:Cost and size of company

[NewWorldDan]

I'm a one man shop and I use version control, CI becomes a non-issue. I'm not convinced that unit testing is practical. However, there's one big red flag in the OP's question:

NEVER DEVELOP ON OLD TECHNOLOGY.

You will eventually find yourself out of work and unable to find work because you have a deprecated skillset. I've seen a lot of people in that situation. I know a very good Access programmer who really needs a job right now.

Deliberately behind the times

[BabaChazz]

We've found that going with the Latest and Greatest causes a lot of grief: M$ has elected to change a lot of the way version control works with their 2010 update to VSS, for instance, and as we still have clients who insist on the more compact executables produced by Visual Studio 6 (11 years old now), we cannot upgrade any further than VS2008. On my current build machine, for instance, I have every VS version between VS6 and VS2008, and I use every one of them for building some part of some product.

That said, some form of version control is critical. All it takes is one fumble-fingered tech erasing a project (which is what spurred our installation of a source control system) or one showstopper bug introduced into the shipping product with no record of how it got there, and you quickly learn the value of having backed-up old source versions.

Your shop shows all the hallmarks of the single-developer shop that grew without direction, as they all do initially. I'd strongly suggest that it would be in your interests to try and get at least minimal tools together... and to update to a recent Java before you start losing sales because of an outdated and now unsupported platform.

Re:Deliberately behind the times

[MemoryDragon]

Everyone who uses Visual Source Safe as version control system should rething his job. Sorry, but Microsoft does not use VSS
in their own development because they know what junk it it. Using this system as version control system given the myriads of really good free alternatives is inexcusable.

Re:Deliberately behind the times

[Mafia$oft]

[reposting old semi-finished copy since Slashdot ate my entire edit window cold and UNRECOVERABLE when messing with Options dialog - and that's not the first time either of severe data loss with Slashdot website design!]

- no atomic checkins ("goddamn, somebody forgot to check in another file again" - "err what in fact I did"), no consistent changesets
- 5 GB max (official Microsoft recommendation), severe index size limitations
- may corrupt easily
- branching is ""supported"" but stay far away from it (said to be #1 source of corruption)
- NO BLAME MECHANISM (perusing the Changelog thus takes about 5 minutes each to hit the relevant spot)
- no 3-way merge AFAICS (and TFS still does not have that either)
- cross-platform support is laughable (there's SOS, but you easily hit trouble on each of RHEL, Ubuntu and Mac, and of course there's no 64bit platform anyway, and it's x86 only)
- performance is abysmal (depending on the moon phase, current mood of the Windoze server and number of busy colleagues, waiting for - yes, indeed - 1.5GB of source repository TAKES AGES (15 min. with VSS on Windows, up to 2 hours on SOS when synching database and subsequently fetching the entire tree); dito simply switching folders in GUI client treeview on SOS may take up to 5 minutes sometimes; this all as opposed to waiting for at most one minute for a kernel.org update to arrive from an internet server
- terrible check-out mode of operation, leading to that dreaded "all files readonly" standard way of operation as opposed to good SCM
- large slowdown of MSVS operation (lock contention!?!?) when additionally running the standalone VSS client
- keeps asking the same stupid questions over and over again rather than simply fetching files
- no distributed SCM (minor item)
- sos command line client is NOT parallelization-safe (needs addition of manual flock/lockfile mechanisms in a wrapper script for reliable use within a massively parallel build system)
- VSS DOES NOT LOCALLY DELETE FILES REMOVED FROM REPO (that one is a killer)

And please do me a favour and don't go cold-turkey to a TFS "upgrade"
but have a worthwhile attempt at reaching an informed decision of which ALM/SCM to actually use.
TFS, while most likely a lot better than VSS, is said to still have lots of rough spots.
See various Internet blogs (e.g. "TFS the Lotus Notes of ALM").

Suitable alternative names may be Mercurial, git, and ALM components such as Trac.

This is your opportunity

[Faramir]

Instead of running - change things. Take it one step at a time. All these tools are valuable, but you can get by without some. Personally, I would start with Version Control, follow up with system/regression testing, then unit testing, continuous integration, and finally deployment process. I've never been in an environment with continuous integration. It hurts, and I'm trying to change that, but I've been picking my battles carefully and not pushed very hard on that one yet (challenges with integration into our version control platform). Don't run from the company, unless they're unable or unwilling to accept concrete proposals for changes. But be very cautious as the new guy. You don't want to continually annoy folks with your shiny new way of doing things. Be patient, research the reasons for each proposals, and try to work each one in over time.

Wisdom

[BigBuckHunter]

Congratulations. You are now wiser than you were prior to accepting the position which you now fill. The next time you interview for a company, which sounds like it may be soon given your current situation, you will now possess an assorted list of queries when the interviewer asks, "Do you have any questions regarding the position or the company?".

Re:Wisdom

[Unequivocal]

I'd suggest being thoughtful in terms of how you ask those questions. If I'm interviewing someone and they give me the third degree on process stuff, I start worrying that they are a "process fanatic." Now don't get me wrong - I'm all for good dev process but there are some people who are fanatical and irritating and not nice to work with, and getting a lot of questions about it would be a small red flag. Just making this point to add nuance to your point.

I absolutely think you should inquire into what the technical and process aspects of the job look like (among others). Just be thoughtful about how you ask..

Re:Wisdom

[SirGarlon]

The way I ask it is, "Tell me about your development tools and release process." Then I shut up and listen until they ask something in return or change the subject.

Re:Wisdom

[Dahamma]

And, really, even without asking questions like that directly you should be able to get am idea of how rigorous their development processes are. If I went through an entire interview with 4-5 engineers and not one of them asked me about unit testing, versioning, deployment, scalability, tools, etc, then that's a pretty big red flag right there...

The "norm" is . . . there is no norm"

[PolygamousRanchKid]

It depends on the product and project that you are developing.

Research Prototype? Two developers? Quality not an issue? Need to be done as soon as possible for a demo? Maybe vi and make are all you need. The error reporting system can be post-its on a wall.

Long Term Product? Supporting multiple customers on multiple platforms? Man-rated? Well, you had better have all the doo-hickeys then.

I've seen both these methods work, and all types of mixes in between. Like I said, it depends on your product and project, there is no norm.

This is definitely not normal

[dkleinsc]

The good news is you can probably start doing some of this stuff on your own. For instance, you can probably set up git on your dev box and just use it for your own change management. You can definitely write unit tests for your code, although you may have to keep that fact hidden from your boss. Just start doing it.

If someone is running around in a panic of "I lost the version of the file from 3 days ago and we need to get it live right now!", use your version control and pull up the version from 3 days ago. When asked "How did you do that?" tell them all you can about the repo, so now you have 2 devs sharing code using a DVCS, and then he tells his buddy and so on, so that by the time management has to make a decision about whether to officially use DVCS the devs can say "We've been doing this for months and it's helped us work faster and recover from screw-ups quickly."

This all assumes that the organization is this bad because it doesn't know any better, not because it's actually being impeded by a manager who would be featured over on Daily WTF.

Re:This is definitely not normal

[dkleinsc]

Sorry, obviously the link is incorrect. The correct link: The Daily WTF.

Yes, it is normal.

[MagikSlinger]

I've been in corporate IT for over 10 years now.

The corporate standard version for Crystal Reports was so old, the version wasn't even listed on their website.

They were creating classic ASP (not .Net) applications as recently as 2005.

The most recently approved version of Visual Studio is... 2005.

There are still active VB6 programmers in the company.

Most of my department uses VSS 5 (yes 5, not 6).

The main corporate Java web app servers were Java 1.4 until last year.

On the other hand, if you come work for my sub-group, we've recently decided to screw corporate standards. We use mercurial, continuous integration with Hudson, Glassfish, latest version of Eclipse IDE, Java 6 and jQuery. None of this is corporate "approved", but we get high marks from our users! ;-)

you just learned a valuable interviewing lesson

[Surt]

And the lesson is, you need to ask more questions about the place you are interviewing. You wound up in an egregiously bad one because you didn't ask those questions. Remember in the future that at least one quarter of the interview should be devoted to you asking them questions, and if their interview practice doesn't allow for that, run away.

At least put YOUR changes on a VCS!

[GPLHost-Thomas]

If there's no VCS in the company, I'd use one at least for myself and my own code. Then if you use a distributed system like Git or Mercurial, you don't even have to ask anyone, it can become viral, and you don't need any piece of infrastructure that doesn't exist already (there's always a way to send patches, using a USB key, a mail attachment, etc.).

Re:At least put YOUR changes on a VCS!

[GPLHost-Thomas]

I think you mistyped. I think you meant:

both Git and Mercurial are far more useful and easy for anything that even the tiniest project should be using it.

Make the software open source!

[Lieutenant_Dan]

It is obvious to everyone that you could harness the synergies that the OSS movement provides by convincing senior management at your new company to make the software open source. I would encourage you to take the initial step and putting the source code on torrents right now, which would show effective leadership and a long-term vision that your new company greatly requires.

By making it open source you will find that there are very mature methodologies for version control and the likelihood that your code will be forked is almost zero (76% to be exact, or in decimal terms 0.76 which is pretty close to zero, more so than 12). Regression testing will be addressed by the multitude of your clients who will willingly give up their slack time to test the product and provide valuable Q&A. You will then need to merely glance at the feedback forum that you will set-up at your $4.99 LAMP web host to get a high-level view of the pertinent concerns.

And use Ruby on Rails; it's the future.

Only when we free ourselves from the dichotomy of corporate greed and lack of client-facing event management, can we attain new heights that will make your company stand out from the rest of software makers out there.

Which is nice.

56 posts and no one asked why?

[vlm]

56 posts so far and no one asked why? This is the crucial question.

1) They hired you specifically because YOU know good dev practices and management wants to model everything after you, or at least after your former employer. Well, golden boy, stay put and rake in the cash. Should be easy to angle into a management job assuming you want that. Maybe the boss thinks he's getting a promotion and is trying to put you as his protege.

2) They started so small they didn't need those things. Now they're big, so they hired a guy from a big time operator. Sounds like it won't be too tough to convince them the new big guy comes with a new big VCS or a new big testing system.

3) They're planning on selling / getting out of the field and just need to keep you around until the sale or bankruptcy is final, or they're completely bonkers insane. Run like hell

Also you have to factor in the change difficulty level. Is your team... just you? Then what the heck does the boss care what your VCS is, just roll one out. Is your team also fed up old timers who know better? or is your team all clueless noobs? Will IT slap you on the back and buy you a beer if you install a GIT repo "hub" like gitolite, or take you out back and shoot you? How bout management?

I would say, fight or flight

[SirGarlon]

If your heart acquires strength, you will be able to remove blemishes from others without thinking evil of them.

Mohandas Gandhi

It is unusual for a software shop to be as immature in its tools and processes as your new employer. Rather than join in the chorus of voices condemning your employer, let me suggest an alternative.

Understand the reasons for the current situation. Professionals, especially engineers, usually have a rational basis for their choices. Perhaps they are disillusioned from having wasted time and energy in the past (see Test Automation Snake Oil). Perhaps they have a few heroic individuals who hold everything together and don't see the need for tools. I have no idea. I cannot wrap my brain around how someone would try to get by without revision control but that's immaterial. You have to understand that before you can either change it, or learn to live with it.

Read the IEEE paper, How to Be a Star Engineer. Then, be a star. Help your team see the value in some basic tools like version control. Introduce them. Train your peers. Proceed slowly and patiently. Talk to your managers and senior staff about the risks you can mitigate and be realistic about the costs of doing so. In other words, help your company do better software engineering.

It is very possible they hired you because you come from a disciplined engineering shop and can help them improve their practices.

Or you can take the coward's way out and flee before you try to teach anything or learn anything.

Re:I would say, fight or flight

[vlm]

It is unusual for a software shop

Assuming its a software shop... I've never worked in one, but I have some decades doing dev work as basically a tool maker at a couple places. The guy's description sounds like a lot of embedded places I've worked where "things just kinda got out of hand" after starting as such simple little projects.

One minute you're basically writing a one page web cgi front end for "grep" and it seems like next thing you know, you're creating a giant data warehouse and statistical analysis system, wtf?

Re:I would say, fight or flight

[Just Some Guy]

If your heart acquires strength, you will be able to remove blemishes from others without thinking evil of them.

Mohandas Gandhi

Smug bastard never had to deal with Team Foundation Server.

Re:I would say, fight or flight

[c 0xFF]

This is exactly why even the smallest projects need to use basic tools like version control right from the very start.

Once anything I'm working on gets larger than, say, a couple files or a hundred lines, I set up a version control system for it. If I find myself doing something (such as copying binaries to a machine) more than a few times, I make a script for it and check that in. I set up a Makefile for even the most basic programs. Then, as the software gets larger or more people work on it, that's already in place, and adding other features (configure scripts, for example) are less of a hassle to put in.

Version Control a must. IDE useful too.

[aristotle-dude]

A lot of people who talk about the Visual Studio are probably not using a stock install but most likely using addons like Resharper to give them the functionality they enjoy.

If you are focused on Java but like the ease of use of Visual Studio + Resharper then take a look at Intelli-J. It is a Java IDE written by the same guys that produced Resharper for VS.NET so you are going to see a lot of similarities between the two products.

I would stay away from GIT and other system popular in the blogosphere and go with SVN as it is tried and true or evaluate Perforce to see if it fits within your budget.

As for continuous integration, look into CruiseControl or something similar.

sadly

[Charliemopps]

Sadly it IS normal. But there's a paycheck right? Stay there until there's something that pays more... then leave.

Every problem is an opportunity

[morningstar8]

Yes, many of these things are standard in large development environments. The smaller you go, the less "standard" they might become. Nonetheless... I suspect that "drop everything and run away" might not be an opportunity for you, as if it were, you probably wouldn't be asking your question here. Every problem is an opportunity, right? Awesome! You have found a new opportunity to learn and grow. You have found yourself in a situation that rubs you the wrong way. How will you change it?

• Run away? You don't like the situation, you don't like fighting windmills, and you're ready and willing to move on. Great, go for it!
• Stick it out? You don't like the situation, you don't like fighting windmills, and you can't move on. Take this opportunity to learn about your new environment from within. Try to understand why they do what they do, and how it got that way. Someday, in a new role, you can bring that experience to bear on a new problem.
• Fix the problems? You don't like the situation, and you have the courage and compassion to take on the windmill. Great! Tread gently, as you are new to this organization. Build trust within the organization. Take the time to understand why they do what they do, and how it got that way. Then, when the opportunity is right and you have a sympathetic ear, make your case for change to the right people. You will likely only have one shot, so make it good.

Whichever route you take, good luck to you!

Version control is not optional

[msobkow]

I don't care how good your programmers are, version control is not optional -- and the versioning server needs to be backed up regularly.

Relying on the programmers to keep copies of code on different workstations and servers, and somehow magically coordinate them without ever losing code is absolute madness.

Old tools aren't unusual, especially if you need them to support "legacy" apps. But some companies don't invest in keeping their tools and code up to date at all, and sooner or later the house of cards comes crashing down. Guess whose "job" it is to bail them out of the resulting situation? And when you tell them how long it'll take, it'll be your fault for being "incompetent."

Ticketing system?

[vlm]

You forgot to mention your ticketing system, or whatever it is you use to track bugs and customer requests. Negative points if that is "nothing at all" or "the salesman promises the customer whatever they want to hear". Positive points if its some kind of request tracker ... you know, like that Request Tracker system...

Other places use, essentially, manual ticketing by to do lists. Or a use Excel as the corporate standard DBMS and store their bugs in a spreadsheet. Some places use email, not as crazy as it sounds. A "workflow management" system using Lotus Notes will cause horrific pain, but is technically usable.

I've never even heard of places using formal project planning systems like microsoft project and GNATT charts and all that, but I suppose it could theoretically happen.

Re:This is the norm.

[Anonymous Coward]

Manual testing is a massive time sink

Isn't that what customers are for?

Re:This is the norm.

[BitZtream]

Anything that can't be automatically tested should probably be redesigned to have some test hooks added.

Then you're testing the code you added to do testing, not the code you needed to test.

If you're redesigning your code JUST for the purposes of testing, you've failed to understand what you're trying to test.

Re:Worst summary ever?

[RDW]

The summary doesn't tell us the slightest thing about the job or the work environment...What sort of software is it?...There's simply not enough information up there to form an opinion.

Product Security Team at Adobe, with special responsibility for Flash and Acrobat?

Re:Worst summary ever?

[anomaly256]

If they are deploying said compiled binaries by hand... onto embedded hardware, then it makes perfect sense. The only thing here that really stands out is lack of version control, there really isn't a situation where that is justifiable. All the other points, I could easily invent or recount some corner case where they make sense...