Slashdot Mirror
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?
* 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?
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.
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.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
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).