Ask Slashdot: Standard Software Development Environments? 362
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?
No CI? No version control? (Score:5, Insightful)
Run, don't walk. (Score:5, Insightful)
#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.
Do what is necessary and right (Score:5, Insightful)
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.
Cost and size of company (Score:5, Insightful)
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 :)
This is your opportunity (Score:4, Insightful)
Wisdom (Score:5, Insightful)
Re:No CI? No version control? (Score:5, Insightful)
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.
56 posts and no one asked why? (Score:5, Insightful)
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 (Score:5, Insightful)
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 [satisfice.com]). 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 [ieee.org]. 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:Cost and size of company (Score:4, Insightful)
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:Wisdom (Score:5, Insightful)
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:No CI? No version control? (Score:5, Insightful)
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? (Score:4, Insightful)
Re:This is the norm. (Score:2, Insightful)
Isn't that what customers are for?
Re:No CI? No version control? (Score:4, Insightful)
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? (Score:2, Insightful)
In this situation it is not the question which tools they use but: which tools they not use. ... or if there are even enough rescue vessels ... ...
People without a version control system don't know if the code they deploy tomorrow contain the fix they already deployed yesterday.
With no version control system, you don't know which features are in the code base.
Likely they have no "plan" what they want to deploy tomorrow, which means they dont even know what features tomorrow will be available, which also means they frankly have no base to bill their customer for what they did.
With no overview over the features implemented, bugs fixed or not fixed (likely they have no issue tracker either) they are like a captain on a damaged ship, who does not have an accurate damage assessment, no position, no idea how much fuel is left, no indication of heading or speed and no idea if the crew is capable of fixing the damgage, if it is even worth fixing (note: heading, position, fuel -> cliff) or better to give up the ship
Sorry, the situation the article describes requires a lot of hero programmers. I doubt you ever find 2 of them at the same place
Sorry, for nitpicking, but you are wrong as you missed the most important word in your list: skilled. People who don't use the appropriated tools are in general not skilled, otherwise they would use them. Would you drag a hand cart behind you if you had a car ready and the skills to use it? Only one who neglects the usefulness of the car will use the cart. And when the axle of the cart breaks he will shrug, take the most valuable stuff and carry it instead of fixing the cart, as he simply lacks the skill for that.