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?
Run. Fast. This company is doomed without basic software engineering discipline.
#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.
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.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
* 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?
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 :)
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.
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?".
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?
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.