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.
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.
I live ze unknown. I love ze unknown. I am ze unknown.
* 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.
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.
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?".
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!
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! ;-)
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
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.
Wearing pants should always be optional.
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.
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?