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?
you were at one end in earlier job and moved to the other end in new job.
Run. Fast. This company is doomed without basic software engineering discipline.
Start looking for a new job -- unless you are in a position of authority and can fix that train wreck.
Seriously. No version control is a sign of EPIC failure in any software group.
Don't even mess with it. Find a job with some professionals.
#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.
regarding this company's practice. Yes it's common, no it's not a place you should work.
.net.
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
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.
There's no -1 for "I don't get it."
This is unfortunately just the way it is: some places do the Right Thing (for various meanings of Right Thing) and others do not. Now you'll know to ask about this kind of thing when you interview. :-)
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.
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?
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.
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.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
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.
In some small manufacturing plants you may find that is the norm.
Where software IS the business that will never fly.
I worked one place where there wasn't even a seperate test database. Test tables had "_test" applied to them.
My last week there I accidentally deleted a whole bunch of production data that locked everyone in the office out of some important functionality- took hours to get things back running.
Biggest mistake I ever made... LOL... although it makes me chuckle thinking back.
YES- it was an accident.
YES- I felt like a total doofus (although I kept telling them whilst there test needs to be seperated).
YES- I'm sure some people probably thought I did it on purpose.
"That's the way to do it" - Punch
During any economic downturn, one of the first things to go in a development environment is the technical writers or requirements analysts, then testing, then good processes. I write technical documentation and requirements. In every job (unfortunately I've had a few), I've seen this pattern for I'm the first one to be let go and then hear from co-workers how everything falls apart from there.
If you're now in a large company, I would be amazed that they are that far behind in good practices, but it does happen. I'm in a situation now where those good practices are only just being put back into place. It's very difficult to change the mind-set of a skunk-works environment. Managers have a hard time justifying strict processes and procedures.
Good luck in this job if you stick it out, and if you don't see change, consider a move to a more stable development team.
Life takes interesting turns, but the most interest is when you're off the beaten path.
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!
Welcome to the schizophrenic world of technology.
Most places simply accept that not using those types of tools helps the bottom line, and that it is the job of managers and developers alike to keep the goals in mind and have the vision to see them through to completion, or that bug tracking is an aspect of Support.
When you only have a couple people, you can get by without continuous integration tools or automated testing. The problem is convincing the business that growth is more than just adding warm bodies.
What's the deal with CI? What's wrong with merging at completion of work units -- like 2-3 weeks instead of daily?
Obvious MS troll is obvious.
In all my jobs (I started in 2004, notice that I work in Italy) at least we had a VCS (CVS, Subversion or some horrible things like StartTeam or PVCS) and an IDE (mostly Eclipse).
In one place we even had functional testing and CI with Hudson. But the two pieces above are the minimum requirements for a decent job, IMHO.
Buddy, send your resumes out and hope you get hired before the company goes under. It is very difficult to get a job if you are unemployed, even if it was through no fault of your own. No. It is no the norm. I have been with my company from almost its start up days. We always had source control and regression testing. Unit testing was spotty in the early days. We were on the bleeding edge of adopting new tech (C++ from the days it was a downloaded preprocessor for a C compiler). So it is not the norm even for start ups.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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.
I am officially gone from
If you only have a handful of people, it may simply be that they have been taking the 'quick and dirty' approach to development for a while and just haven't had the initiative to change it. In such an environment I suspect a few suggestions for improvements would be met with interest, especially if you're willing to put the time in to implement such. Now, on the other hand, if you're talking a mid to large development crew, then I'd be worried. That speaks to some serious weakness in management that they are willing to cut corners behind the scenes. Still, again, it could simply be lack of initiative. If you speak up with some suggestions you could find them receptive to some change, especially if you can sell them on the improvements in productivity and such.
I genuinely cringed when you said no version control. My opinion? Run away or revamp the whole system. All kinds of shit happens without version control.
You have two choices: You can either push them to start adopting some better tools, ESPECIALLY VERSION CONTROL, or you can leave. Pushing these things will take quite a bit of effort, and it's quite possible that you will not be successful in your efforts. However, if you are, and can demonstrate to everyone what tangible improvements they bring, you'll be a hero. But remember, I said tangible improvements. You need to be able to communicate actual improvements that will come, in terms of bugs fixed earlier, number of crises prevented, stuff like that. You can't just say, "We should be using this stuff because it's good!"
The other choice, is simply to leave. Sad as it may be, there are a lot of places out there that are not doing these necessary things. And most of them don't see any need for them, as they don't easily translate to benefits for the customer. Places like this don't care about the developers, and would have no problem sending you on a multiple month death march. If you are not able to convince them to adopt these tools, drop them like a bad habit. Make sure they know that you are leaving because of their refusal to adopt these practices.
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
I don't agree that it's the norm, even for a small company. You don't need big money, esp. for java development.
We're small and we get by well. cvs, eclipse, junit, cruisecontrol, ant, rpm. Throw a little money for Jira and you're doing pretty well.
But you're there, so either run or try and change things. But believe me, it's not easy. Developers get engrained in ways of doing things. And even if it's for the better, changing that takes time. Convincing your boss and a senior dev guy to start is your best bet.
My god! You are so helpful! Whatever would we do without you!
If this new job is on either the gov or contractor side of the DoD, this is more than normal (did my time in that setting, never want to go back). This sort of development setting is also commonly found in larger companies outside of DoD. I've only been out of school a few years, but I've already learned a valuable lesson: bad development environments are caused by lack of caring from the dev team which leads to a horrible working environment if you actually care about programming. Unfortunately these bad settings tend to pay the most, but I assure you that working in a company surrounded by people who know and stay current in their field who are also passionate about the work being done (professionally and personally) is worth more than any amount of hard currency.
I think you where very lucky in your first job. I have had several jobs and only in one of them the manager considered that kind of tools. In the rest they always told me "Great idea, do it!"; "Thanks, then other people can now start using these tools, too. I may need a server to set it up"; "What? No, do it in you own time at home, I don't care about that stupid stuff, other people don't need that shit. Shut up and work!". That's the main reason why I keep changing jobs....
Luckily for them you know what a proper development environment looks like. If they want to make it a top priority to improve in that area than great. If they don't see it that way find another job immediately. Life is too short to be stuck in a place like that.
I want to stress that I'm not in the industry as a developer but I do work on coop doing some code development. Where I work on coop we use Perforce as the SCM tool of choice and it is horrible.
Outlining some of the problems I've had with Perforce:
1) All the tools to work with Perforce are sloppy and bulky, The GUI is horrible and does not have a usable work flow
2) Perforce is known to crash, I've personally seen the Depo get so messed up that the company I do coop for had to call Perforce and ask what to do
3) Perforce makes it hard to get the files uploaded and then has in the past completely prevented me from checking them out
4) Perforce doesn't allow you to change a files name when it's checked out, It should keep track of Inodes not file names
5) Perforce has horrible cross platform support, unlike GIT
6) Perforce has poor workspace support, If you mess around at all it will get more lost then a baby in a room of topless women
7) Perforce loves to make more then 1 workspace per user and not tell you
8) Perforce loves to lock up preventing you from getting access to your files
9) Perforce is extremely slow, it crawl in comparison to GIT
10) Perforce doesn't provide any actual customer help
I've had these same problems at school, where we also run Perforce in our program. When it comes to SCM there is one product that I promise is more trouble then it's worth and that is Perforce. I haven't made up a single point above, I have had every problem I mentioned and coming from a closed source software I should of had been nothing but a stellar experience.
If perforce wants to create a usable product they need to get rid of the GUI entirely, They do have a CLI but it's not the greatest. They need to create power shell tools to work it. They need to allow you to actually use the workspace and not manage it for you exclusively and they need to stop the freezing and crashing that plagues the software. .
Luckily there is a GIT which does fix all the problems i've had with Perforce and has left me with a wonderful solution to SCM. I even use GIT at school now above Perforce because it leaves me with a usable product that can hold up.
Sounds like a place I worked where the owner fancied himself a developer because he wrote the initial program in GWBasic. His fair-haired right-hand man wrote (probably still writes) some of the sloppiest code I have ever seen and when the boss man wants a change made he goes to "Karl" who "tweaks" the code solving the immediate problem and all too often creating a morass of workarounds and kludges which end up stifling attempts to extend the code. Rumor has it that they are still using a 12 year old IDE that was new when Win 98 was the latest, greatest thing on the block.
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.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Unfortunately, this sounds like almost every company for which I've worked.
At one job, we were using the same hardware and software that had been used about eight years earlier to originally develop the software. Nobody, including the other developers, saw any reason to change a thing. At one point, the secretaries were getting new machines, so we grabbed their old machines which were still much newer than any of our development boxes.
The only company I ever worked for that provided up-to-date hardware and software went out of business after six months, in part because they were spending so much money on "cool stuff" whether they needed it or not. (Lesson learned from the dot-com craze: Don't get expensive office space, fancy and expensive working "environments" and other perks until you actually have a revenue stream!)
Top priority is version control. Without that, you don't know where you are. Which version control system doesn't matter that much. They all work well for small projects.
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.).
Here are my two cents: In any team environment, a good version/source management is a must. Build and deployment processes should also be examined. Shell scripting will go a long way to automate and alleviate many of your recurring headaches. With that said, there is nothing that annoys me more than employing industry standard buzz words for any and every solution, thus bloating the development process. As a developer, I always appreciate a thin development environment that allows me to do more development and less infrastructure, third-party software debugging.
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.
This has exactly zero to do with the question asked in TFS.
How's its Java syntax highlighting? Objective-C autocompletion? Visual nib editor?
Visual Studio is a nice IDE (the debugger is still probably the best for any mainstream platform), but it is very much a Windows IDE. If you're targeting Windows, then it's probably the right tool for the job. If you aren't, then it almost certainly isn't.
I am TheRaven on Soylent News
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.
Jesus was a compassionate social conservative who called individuals to sin no more.
Using version control is an standard thing to do in software development. This even applies to the embedded system. Unit-tests are not widely used. However, not using them is stupid. The same applies to other more elaborate test mechanisms. Continuous integration is not used in all companies, but the use is becoming more common lately.
If you are able to establish a tool landscape in your company then that would be a move in the right direction. What you also need is an agile development approach instead of the fumbling around approach. Agile is required, as requirements are never totally known at project start. They normally form in a longer process. Therefore you need also to support aspect oriented methods and feature driven development. And you should design for change and include monitoring in your enterprise application.
If all these things are possible you actually can stay with the company.
My employer makes spiffy gadgets for the automotive market, and you may own one of our products. Commonly, developers have VS for building code in a simulator and CodeWright for developing code to run on an embedded device. Version control is done with Git, CI with Jenkins, code review with Gerrit, issue tracking with Jira.
Sadly it IS normal. But there's a paycheck right? Stay there until there's something that pays more... then leave.
Anything that can't be automatically tested should probably be redesigned to have some test hooks added. I/O can have some kind of loopback or test fixture, GUI testing is easy to automate, it's generally rare error conditions that can be hard to simulate. Those are the cases where you might need to add a way to inject errors upstream to force the condition.
Version control is a must for any development more complicated than "hello, world", even when it's a one-man project. There are no ifs or buts about it. There's a reason why VCS date back 40 years.
Sometimes they'll listen to reason, though. It's usually pretty easy to get a version control system set up. Might be a bit harder to get them to agree to a legitimate test environment if they don't already have one. They might at least allow you to build one with vmware. Drop in a build and deploy process and the development environment would be almost civilized.
If they're not keen on any of that you'd be better off finding a real software shop to work in.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
If the company is a start-up, then they need to get some process fast or they are one disk crash away from oblivion. If they've been around long enough to know better then you might want to move on now. Either way you can try to encourage them to adopt some process first, then if it just isn't going to happen look for a new job. They absolutely must have a source control system and offsite backups. It doesn't matter what's normal, not having source control is like not having toilet paper in the bathroom. Even a one-person development team should use it. Offsite backups are literally your fire insurance. The other things you mentioned are all good to have, and their presence or absence may give you some idea of the relative maturity of the business, but version control and backups are absolutely non-negotiable. Java versions are a little different. There, you may be forced to develop in an older version to support a customer that's slow to change their client configurations. This can be true especially when your clients are businesses rather than individuals. At one job I was developing in Java 1.1 for a long time because our biggest customer was running Netscape 4 on OS/2 at 6000 locations and that was the latest version they could handle. The software still worked fine for folks with newer browsers and JREs, I just didn't get to use Swing and a host of other niceties.
-- Conserve binary trees; recycle your email. --
... at how many of the comments say to run from the company because they don't have good software practices and look for a job where that stuff is already in place. It makes me wonder how many people think that a company should just hand everything to you.
If you see a problem in the company, where you know you can add the value of good software engineering practices, fix it. You looking for career advancement? What looks better on a resume? A person who switches jobs because they don't have what he wants implemented? Or a person who sees a problem, presents a solution, implements it and learns how to deal with it? Which choice screams of career advancement?
Yes, it will be a risk and maybe it will get turned down, but at least make an effort. In software development, people tend to get caught up in their own little "programming" worlds and fail to see the big picture. Really, if you like the people you are working with, then just try to show them why they should be developing it the way you think it should be. If they argue that they don't want to change because of money, show them how much they can save by doing it your way. If they still don't agree and can't give valid reasons why they don't want to change, then it may be time to consider looking, because they aren't really looking for your input at that point and aren't really amenable to change.
Option 2 probably isn't viable (although we don't know enough to make the call for sure). The place he works at likes being backwards, and the workers probably lacks tech enthusiasm. Updating things is difficult and error prone and its importance is for the long term and the benefits are non-obvious. OP probably can't do anything and will probably end up on the losing end of office politics if he tries.
Democracy Now! - your daily, uncensored, corporate-free
Most places simply accept that not using those types of tools helps the bottom line
Any place that thinks not using Version Control, or many of the other tools, especially when low cost or no cost solutions are available, is run by incompetent idiots.
Whichever route you take, good luck to you!
You haven't seen shit yet, you'll experience FAR crazier things in your career for sure.
What you should be asking however is ... why are THEY using old tools and not what you would consider 'best practices' (me too from the sound of it).
There may actually be a reason, and it may give you a hint as to what direction you want to take with the company. The reason is probably a bad one, but it may not be.
In short, you shouldn't be asking slashdot, you should be asking the people you work with that actually have some idea whats going on with the company you work for. You'll get a lot of retarded answers from slashdot telling you EXACTLY how it SHOULD BE when the people giving the answers have no clue what sort of requirements your company is operating under.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
My current job is mostly internal software, no software is sold (it's mostly data sources that we sell). We don't have testing tools except for some SQL scripts for parallel testing comparisons. Don't really need them either since a parallel test run for a few weeks against production pretty well tests everything (at least in our environment.) And since there are only two developers (the other is my boss), we don't really do much code review, although we do have 'what do you think about this' sessions quite a bit. We use VSS for production (because we always have), and subversion for development source control since Subversion integrates with NetBeans and we don't really have a need to merge code since we never work on the same code sets at the same time. Developers have full access to production, and can put code into place at any time without any restrictions. But since the two of us have over 25 years experience apiece, we know better than to do so during production periods and without adequate testing. I tend to script out database changes so I can make sure what changes in production is what I actually did in dev. No QC system at all, code moves straight from the dev system to production. No long, drawn out design sessions, most design work is done as we code after a high-level 'here is what I think we should do' session. Kinda waterfall like, write some code, get some results, write more code. Takes forever to get anything done because priorities are always shifting.
In a prior company with more outward facing software, we used more automated tools and actually had a QC staff to use them. We used CVS for version control, since there was more of a need of a pure lock/check-in type system. Larger development staff of varying skills, system admins created tar balls and scripts to install code into QC and production. Code was moved to a staging area, then Unison was used to sync to production servers. Developers were not allowed access to any production system. Much more structured with actual design specs and sign offs. Took forever to get anything done because of all the BS that we had to go through.
Both methods worked fine and produced good quality, repeatable results. I prefer the current environment to work in, but the more structured environment is required for larger shops. And the bigger the shop, the more structure that seems to be needed to keep conflicts at a minimum.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
You are alerted to bugs sooner. You know exactly when a regression bug get added, and can fix them sooner. However, remember, CI tests are only run when stuff is checked in to the trunk, or certain branches.
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."
I do not fail; I succeed at finding out what does not work.
I work for a small company that hired outside consultants to build them a basic web app integrated with SharePoint. I was hired after the consultants charged wayyyy too much and delivered crap results.
I was not specifically hired to do software development. I've never developed in a structured development environment. When I arrived there was no source control, barely an IDE, and no documentation. I've spent the last 2 years reverse engineering what was there and building something far more usable. We're now using Team Foundation Server and are getting a more structured process for builds due to SAS70 requirements.
It's really difficult to manage the release cycles people expect when I'm the only person who writes any reasonable amount of code or understands the whole ecosystem. Because of this, most of my time is spent squashing bugs or working on building the next client site. I know there are plenty of deficiencies in our whole process (and I can identify them) but I don't have the time or resources to change much currently. The closest person to my level of knowledge is our IT guy, and he has zero background in software development (or best practices for IT for that matter).
What the hell should I do? I would need to be involved in any decision to hire a real software developer because I don't trust the company to properly vet those who would be applying. The company also doesn't want to departmentalize things -- I hold the same title/position as others who write absolutely no code. I'm not sure they'd be receptive to someone who is primarily a software developer.
It's not like the assignation of one man ever caused a world war.
If your software processes credit cards, that type of environment is banned by Visa. Among other restrictions, you have to run supported versions of all software. You have to have a release process, including code reviews. You have to have a development process. It doesn't have to be strictly Agile, but the process has to be documented and followed. I've worked in other sectors at other companies where things are much more chaotic.
As a programmer, you should take work which makes you a better programmer, while making enough money to be reasonably happy. You know if you're getting better as a programmer or simply treading water until the next job comes along. If you take work for the money, you're more likely to fall into the latter trap. The amount money you make, whether the company will survive longer than a few years into the future, and the exact processes at work at the company don't have that much to do with improving your skills as a programmer. What does improve your skills as a programmer involve things like how much design are you doing, do you get to see your work through to completion, do you get to be exposed to a variety of technologies and environments (not necessarily the latest fads), and do you get to work with other highly skilled technical people (especially other programmers).
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Isn't that what customers are for?
The summary doesn't tell us the slightest thing about the job or the work environment?
eg.
* How many programmers work there?
* What sort of software is it?
* Is the software any good (despite all the 'missing' programming practices) or is it worthy of a Daily WTF article?
I'm sure you'll get lots of opinions below but they're all posting in ignorance. There's simply not enough information up there to form an opinion.
No sig today...
Dude... How did you *not* know this before taking the job???
"What is your technology stack?" "What bug tracking?" "What build tools?" "What development environment?"
You need to interview them, just as much as they are interviewing you.
You have crafted your own hell. Either fix it, or leave while you can.
...all I can suggest is to create a Development Environment in a Virtual Machine (I use VMWare for this) preferably allocated a minimum of 4 GB RAM and 2 Processors. Use a Server OS as your Platform such as Windows Server 2008, install SQL Server 2008 R2 Developer Edition (including SSRS, SSAS, SSIS), Install SharePoint Server 2010, Install Visual Studio 2010 for SharePoint WebPart development. Use TFS for integrating to the Source Control DB.
After all the installation has been completed, setup the VM to connect to the company's domain and do all the development and testing in the VM. After it is fully tested, check-in the updates to TFS. It is a royal pain in the rear to set this all up from scratch.
If you're the release engineer and the first one to hold that position at that company, and management and development understand they are a software company and are willing to work together to succeed, I envy you, It is time for you to take the lead and implement good software build and maintenance practices. Start reading up on source control, build maangement, and quality assurance processes. Consider using subversion (svn) or git for source control (since they provide cross-platform clients and integrate very well with Linux, Windows, and Macs) and ant (Apache Ant) as your built platform. Get your developers into the habit of including notes on their checkins, and script build release notes with each build. Any time a build fails, capture the build error, and if you can fix it yourself patch it and provide is an an unofficial build, but do not check in the fix; email the offending error to the development team, cc: the QA team, and also note that an unofficial build has been provided for QA to make progress.
Include QA in every step of the process; all too many people consider QA to be merely QC and a "final step" in the software production process. A mature development environment will include quality assurance from the very beginning (the requirements and specificiations stage) and release engineers often act as unofficial liasons between software development and QA despite living more in the development/sysadmin role. In fact release engineering can be one of the more fun roles in a software development environment because of the mix of technical challenges and being a more people-oriented position.
Also, as far as tools go: don't blindly go f/oss. I tend to prefer f/oss but keep in mind that the tools need to make your work easier, not harder. If a F/OSS tool complicates the job, but a for-pay tool makes you more productive, push for the company to buy the tool.
Consider designing and implementing and managing process and managing people to be your MOST important task in release engineering, and the tools you use to be secondary, and based on the decisions you and the rest of the team make regarding processes and policies you propose.
I'll add more later - but don't let people discourage you. Release engineering can be a LOT of fun!
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Ah yes, its always good to encourage a developer to steal software from other developers, thats exactly how to show that you deserve to be paid for your profession ... by ripping off others in your profession trying to do the same thing.
Grow up.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I'm a C++ programmer, you insensitive clod. C/C++ is not limited to Windows, yet there are no better IDE for C++ than Visual Studio (especially with Visual Assist).
Coding etudes
Maybe HR / a non tech manger did the interview and they have no idea about the software being used.
I'm an old greying kind of guy... I've been writing code with some variant of 'vi' for going on 20 years or so... The place I'm at now, I'm one of about 4 'old guys'... We use 'vi'... Corporately we use cvs, bugzilla, manually hacked up nightly build and regression testing. It works well and our code is safe. Occasionally some young whippersnapper will come in and shake his head at us old guys not using Eclipse/Git/whatever... "I'm surprised you guys get any work done at all!" ... It doesn't take long for little Johnny to see that we typically can code circles around him... Frankly, I don't give a rats what tools someone uses, as long as they're good. So I agree with the basic sentiment that SCM, CI, test suites, etc, are all vital and necessary, I don't think it's of much value to criticize the choice of tool... Oh yeah, and emacs sucks.
Use this as an opportunity to contribute what you know to your company. Don't assume that the deficits in your work environment are a result of apathy. With 5 years experience in that environment, you can well be the worker to come up with a proposal or demonstration to upgrade the environment.
Make sure you don't assume that everyone knows or understands what the benefits of the solutions you want to bring to the table are. Lay it out and be prepared to show real-world examples and answer questions. You might get more out of this than just a better work environment. This could be a stellar opportunity for career advancement!
I swear to God...I swear to God! That is NOT how you treat your human!
Oh come on, please automate testing whether the player can complete the level without being stuck in a progression blocker, when level designers keep changing it daily. You will either need really smart level designers (more like scripters) or will need to "automate" testing again after each change.
Even better example is automating tests that "AI does not behave erratically/stupid when players does something unexpected".
Coding etudes
Only if you're using Microsoft APIs and libraries. However, if you want to do cross-platform development, then you're better off using something like QT. (which works great on Windows with MinGW) I've been using QT Creator for awhile and it is very good. (furthermore, the QT documentation is excellent and has gotten me out of many a problem) True, you can use QT with Visual Studio and get QT projects to build with nmake, but it feels bolted-on compared to using an IDE that was designed with QT in mind.
"It is a denial of justice not to stretch out a helping hand to the fallen; that is the common right of humanity."
I worked for an ISO 9001 company which had all kinds of procedures an practices in place. These were externally audited. Yet somehow the only programming language approved in the big books was C (which nobody used) and an old version of C at that.
It was here I discovered that there are two reasons for "best practices" one was just as it said, unit testing and whatnot to reduce bugs.
The other was a combination of power broking and make work. The company I worked for had a huge QA department. So when they were idle they would put QA people on whatever project had some budget. The QA people would lard on the procedures and practices. They would make sure that everything was as ISO as it could be. They would see nothing wrong with 5 or 6 QA people for every programmer. Projects would grind to a halt where the programmers were quickly sucked into providing materials (not code but documentation and whatnot) for QA.
Another company had one senior guy who made sure to do code reviews. A code review could be an all day affair while he and his lackeys would go through your (potentially in production) unit tested code and start altering it starting with removing all the unit tests as they interfered with the changes. Then they would hand back a broken set of code and smugly say they put you back on the right track. This same company had a custom complicated source control system that prevented you from checking out code without being authorized for it. After checking the code back in the authorization would be withdrawn. I would guess that manager spent nearly all day doing yards and yards of micro management.
But to partially answer your question what are the best tools? The answer depends completely upon the skill of both your best and worst programmers. GIT is a great system for great programmers. A terrible system for poor programmers. VSS is a great environment for managing a pile of crap programmers. You mentioned using an old version of Java. Is there a reason for this? Once in a blue moon there is a good reason for sticking with an old environment. Maybe it is being deployed to some crap embedded device. More often it is a spaghetti architecture where too many things break when you upgrade and without good unit tests it is hard to pin down the problems.
How mission critical is your system? If this is a navigation system then your code should have more unit tests than code by a wide margin. If it is a dating site then maybe you can be a bit slack about even things like data integrity and thus have a tiny set of unit tests that make sure that core functionality remains intact after changes.
What IDE? Eclipse is a big favorite of mine but most modern IDEs are good enough and might even be better depending on the language in question (even XCode).
But a sure bad smell is documentation. I would guess that 99% of documentation is never read. So people who create systems that somehow leave yards and yards of documentation behind are basically creating TPS reports. Good documentation is the sort that everyone will read or those who do will literally thank you for it. Something like a command by command document on how to set up a production server. That is a life saver. (Didn't know that you had to install the beta version of X).
Another bad smell is given off by meetings. Many people who don't code seem to think that meetings are productive. A Monday morning pow wow to see look at last week's progress and see that everyone has a plan for the week is good. Daily meetings or regular 2 hour meetings only serve to make some poor manager feel like they are contributing.
A great manager is barely there. They quietly make sure that progress is being made and quickly deal with roadblocks present and future, especially those created by the company itself. So the moment a programmer hears the words "Code metric" or some such trash then their manger is out of control. Maybe the manager uses code metrics but from the programmer's perspective all they should hear it as "Keep up the good work." Or "Why
It happens that I also use Qt (note it's Qt, since QT is for QuickTime) for my pet projects (like programming N900 phone). And as much as I like Qt Creator, it has much less features than VS and is severely limited by underlying qmake. While you can create something like "solution" by using nested qmake projects, you cannot easily control which configuration (a set of compiler options, with Debug and Release being predefined) you want to build for a particular project in a solution - and none of these can be done from QtCreator GUI. In fact, you cannot even rebuild a single (nested) project from withing QtCreator GUI, let alone edit dependencies between them. Also, QtCreator doesn't allow you to arrange project files differently than they are laid out on filesystem and does not expose compiler options, relying on hand-editing .pro files.
This is all basic usage, but this haven't been improved in more than 2 years (since 1.0 version).
Coding etudes
Merging is a lot less painful the more frequently you do it.
This is true. Commonly, the development environment evolves in ad hoc fashion with various elements and approaches being tried along the way. The result after a few year can be pretty messy, especially if developers have been sidelined to do the system administration. If you're a developer, it's important during the interview to find out about this, but the exact details are probably less important than the attitude toward maintaining and improving that environment. There's always room for improvement, after all. It's exactly the sort of question that you can very reasonably ask during an interview. I'd look for clear, candid answers from each of your interviewers, according to the perspective they have within the organization.
Parity: What to do when the weekend comes.
He obviously used telnet, you insensitive clod!
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
This company is a bunch of clowns. They can not possibly hope to deliver working software reliably and on time (or at all).
What happens is that everyone develops "their" code in isolation. Near the deadline for the project everyone tried to deliver their code all at once. Not only do they find that it doesn't "fit together" (it doesn't compile), but after a few weeks of late-nighters and all-weekenders trying to fix it, when it does compile, it doesn't run and certainly doesn't do what it was intended to.
This sort of disaster scenario has been documented and understood - in books you can buy from Amazon - (heck, even by Microsoft of all organisations) since the 1980s. This isn't just old, it's antediluvian. It doesn't work!
I worked at a place like that before. Not only was the product flaky and always late, but it was a very stressful place to work with the developers "given responsibility" whenever something went wrong. They went bust 18 months after I escaped.
The reasons things went wrong were that there wasn't a team: individual developers silo'd and working on different things, forbidden from communicating in case they were "wasting time." And there were a bunch of enthusiastic but inexperienced junior coders in China churning out lines of code (Perl-written-in-C) by the thousand that did nothing but crash.
There were no peer reviews (i.e. code reviews), there was a coding standard that was ignored, infrequent status meetings, plans (MS Project) that were pure fantasy.
The Director of Software Development and his sidekick sought to ensure quality and timeliness by taking the developers individually into their offices and shouting at them for 30-45 minutes.
Appraisals involved the aforementioned dynamic duo. You would be invited in, smiled at unconvincingly and then asked how you thought you did in the previous year. Then you would be told how you did and what pay rise you were (or weren't) getting.
I was there for 2 years and 2 months and the Software office had between 22 and 25 people at any one time during that period. 19 of us left (including 2 who resigned when I was working out my 1 month notice period).
They were dinosaurs and their bones lie under the Cambridgeshire countryside.
BTW, it was my second job in the industry, too.
Stick Men
This is the norm.
Most places simply accept that not using those types of tools helps the bottom line, and that it is the job of managers and developers alike to keep the goals in mind and have the vision to see them through to completion, or that bug tracking is an aspect of Support.
Oh *come on*. Have you ever collaborated with competent developers and/or companies that *didn't* use source control? There is absolutely no reason not to use one, even if you're the sole dev on a small project.
A long time ago I worked with a pretty good self-taught developer on a small, but growing, community website. He didn't use a vcs, but once I told him what they did we started using one instantly. If anyone tells you that it's not necessary for whatever reason they're grossly incompetent.
Are you a grammar Nazi? I'm trying to improve my English; please correct my errors!
I know this probably isn't a popular open source option, but the latest TFS 2010 is quite good at version control. .Net 2.0 platform for a while now .Net 4.0
We've been using Sourcesafe / VB6 /
But sourcesafe is all shared drive based which makes it particularly slow over the internet
we're currently in the process of moving to TFS 2010 /
TFS stores all it's data under MSSQL 2008.
presents a soap interface for checkins / check outs (so will actually work with VB6 or other development enviroments quite easily)
If you have a MSDN subscription the licence for TFS / Database is already covered
the only licences needed are for Visual Studio / the CAL's (Client Access Licences)
you can view source over a web interface and can be set to operate similar to Sourcesafe (only one checkout allowed at a time)
plus it has Windows Explorer integration via the Power Tools
Most places do have a rough form of version control, as simple as zips backed up to a server. These kinds of low-tech unofficial approaches seem ugly, but basically do the job for a single developer or several independents.
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
I don't quite get the "industry standard (not open source) in version control" part. What is the difference between them? Does that mean open source version control is not as up to standard as industrial solutions? I asked because so far only one of the three companies I worked for uses non-open source vcs.
Regardless of what the state of version control and bug tracking and development tools are used within a company I always have my own available. If the company I am working with has a suitable suite of tools then I use them. When no such suite exists mine is available as either a standalone or server installation on my own workstation or laptop.
If I am working with a team that has nothing I generally offer to setup and deploy a basic infrastructure if the existing one is missing or broken. Normally a suite of Trac/SVN works reasonably and only takes an hour or so to setup.
As a consultant for many years I have seen the full range from none to a full suite of tools supporting a rigorous development process. I've help with roll outs of CVS, SVN, AccuRev, and ClearCase. Personally Trac and SVN do everything thing I need and do it really well. That said I normally augment those tools with my preferred setup of RabbitSVN + meld or TortoiseSVN and WinMerge and some personal scripts for diffing and merging.
All of this version control isn't worth a damn if there's no foosball table or bar fridge stocked with Coca Cola, Pepsi, and Aquafina. That's what drives the creative process, the movie pictures on the wall and the basket ball hoop in the corner help too. Using CVS is for suits and lawyers, real programmers don't have time to comment their code if they want to be successful. Your new company is giving you the freedom to code outside of the box, embrace it. As for unit testing and automated regression testing, that's what customers are for. If it is good enough for MS, then it should be good enough for you.
If I were paid enough, I'd code in Notepad, save my work on floppy discs and use dot-matrix printouts on fanfold paper for version control (again). Maybe the submitter is making hella money at this company, in which case #1 is moot in my book.
Better known as 318230.
No automated testing and no source control never help the bottom line.
No, but sometimes source control can damage the bottom line, and also greatly impair productivity. Anyone who's used Clearcase will agree with me on this. Not only is it ridiculously expensive, you have to hire a full-time administrator just to maintain the Clearcase server, and using it will slow down all your development work.
you ask in an interview. This is not the norm among good development shops. You are stuck in a pretty bad one it seems. So, you have not really found a job yet, this is a stop gap for you I'm afraid, unless you are willing to regress professionally.
So, next time be smarter and interview your prospective employers as well and ask about their processes, tools they use to manage them, methodologies, what kind of hardware infrastructure they have in place, build environment, automated tests, do they have QA department/employees, what developer tools are used, how do developers typically work (IDE only, or do some use CLI tools?), what GUI toolkit is used, how does continual improvement work, do they have a coding standard, do they do peer reviews, are they mandatory, are developers admins on their machines, what OSes do developers typically work with, what databases etc (just off the top of my head the things that are important to me). If you spot any red flags, like no version control used, ask more questions for clarification. If they really don't use version control and think its not necessary, eliminate them. Not everyone is worth working for I'm afraid.
And if you are thinking of instituting change and putting proper practices in place, think again. If you were not hired specifically with a mandate to do that, you will just being perceived as a bitchy new guy, who complains a lot about how things are done at the new place.
As the island of our knowledge grows, so does the shore of our ignorance.
No, actually Mitt says there are 1 million unfilled tech positions here in the U.S., so ramp up the visas!
Note, not ramp up citizenship, just visas, we wouldn't want to bring over people who then expect similar wages!
For newer software, newer design, newer methodology - unless it saves them cash they won't go for it. You can rant all you like about newer tech, latest ideas from Silicon valley, etc etc ... the bottom line is ... the bottom line.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
>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.
Nope.
1. In some cases the decision to eschew good test automation comes from the top in an effort to reduce time to market by reducing total lines of code. To quote one CEO I worked with, "We'll add quality later" followed by mumblings about how engineering would rewrite the code a bunch of times and would to save time by getting to the final product and then testing." No number of personal anecdotes, quotes from papers and books, reasoned arguments, supporting arguments from executive staff, etc. showing that a smarter and more thorough test effort makes time to market shorter and more predictable will change things. The best you can do is take care of your own corner of the product, point out the places where you fixed certain types of bugs in X hours versus X weeks by group members not doing that, hope your co-workers join you, and hope for a leadership change that will be more receptive to your input before the company tanks.
2. Most developers can make it a decade into their career without both grasping the utility (fewer bugs reaching users that become irate, less effort to fix the bugs you do find, more predicable schedules so that death marches are less likely, less integration pain with fewer errors) of and choosing to apply good test automation and continuous integration. They can be impervious to talk, management buying people copies of relevant books (The Clean Coder, XP: Extreme Programming Explained, etc.) in their choice of print or Kindle edition and telling them to read it at work whenever they want, a rubber chicken or toilet plunger for whoever last broke things, etc. You need to get management buy in with leadership willing to hire and fire if people won't get in line.
In both cases you may be better off finding a more sensible job.
While "Matt's version control system" sounds ridiculously stupid, it's a pretty common thing for new coders to just throw away everything old they find, because they can't understand it.
But if the code they hand you isn't in working shape, then it's usually easier to just recode than try to wade through piles of code that don't make any sense.
forget about English. Just shout out a torrent of buzzwords and the check is in the mail! proven practice
-- no sig today
This has exactly zero to do with the question asked in TFS.
Exactly.
And the answer to that question, from my experience, is "yes, this is quite common". As to whether one could say it's the norm possibly depends on the kind of shop you're talking about.
My first computing job (back in the late '70s) was at a shop that offered bureau services run on a Burroughs B3700 mainframe. A lot of my software tools were already 5 years past their release date, and it wasn't uncommon for me to have to patch binaries directly when the Fortran, assembly or COBOL source had either been lost or had already diverged significantly from its associated code. Back then we just saw this as a fact of life and got on with it.
Unless I happened to be the sysop or one of the keypunch ops, I didn't even have a dumb terminal to input my code. Most of my work was written on 80-column coding sheets with a strange stylus-like wooden instrument with graphite in the middle. (Or if our patches were small, we used a 10-button card punch.) Our offices were thus a lot quieter than modern counterparts.
The good thing about this was that it kept your problem-solving skills honed, which I would consider vastly more important than having the very latest toys to play with.
Well, since you asked ... Here's my daily work environment (Just so you know it's worse somewhere :-) )
- Main application coded in VB 6.0 ("ported" from VB 3.0, so it uses NO "advanced" features of VB 6.0) :-(
- Secondary and "tool" applications coded in C/C++ (but compiled with Visual Studio 6.0)
- Version control: MKS
- Bug Tracking: MKS
- SQA -- Only since 2010, and the product in its current form has basically been around since VB 1.0 (the original version was written in Pascal for an Apple ][!)
- Code reviews: no
- Coding standards: no
- Continuous Integration: WTF is that?
- Unit testing: HA!
The good news is, we're hiring!
You fell through a hole in time and are at MS developing Win95????
Sure enough, the cow costume was hanging up next to the superhero outfit and sailors uniform. (S,Spud)
A shop needs to at least have a version control system. I would consider that if you are in a Unix environment (linux etc) you are working in an older development arena and you are looking at a minimum you should have subversion.
Requirements Tracking, Use Cases, Test Driven Development, Integration Testing, and Validation are all buzzwords for making sure the PROCESS is correct. Tools are just in support of the process. If your company is doing the previous then what you are looking at is pushing a technology refresh on your tools.
If the previous is not done, push the processes first. You can show how taking a strong model can improve the system and then you can show that tools enhance. Its all about proving the cost savings.
If its a small company, its HARD to prove the cost savings as an overall group since you probably are looking at a few "super stars" who do not take direction well but will produce greatly in the short terms. Short Term development (small products, products that have short shelf life) tends to push towards quick development and cheap processes.
I can program myself out of a Hello World Contest!!
"Welcome to hell, kid." - Wally (of Dilbert fame)
I haven't worked anywhere without version control in 20 years. And we had stuff on m'frames, too. The folks running your new shop are idiots, and ignorant idiots. Both hands on the gun, and taking time to aim, and squeeze the trigger like a lemon, to shoot themselves in the foot.
In *real* professional shops, we had (actually, I helped build) automated systems that extracted the current release ever single 0-dark-thirty in the morning from our VCS and rebuilt production, every single day.
Keep your options open for other jobs, I'm afraid.
mark
How many comments on this topic are "run for the hills and ask better questions in the future". Everyone here seems to assume that just because a company doesn't have X or Y, which they think makes their lives easier that the company is doomed or terrible to work for. That can't be further from the truth. Regression tests are nice, but maybe this company doesn't require regular overtime. VCS are important, but maybe these guys keep a manual version repository (lots and lots of copies of old files) and work in a way that almost nobody is ever touching the same file during the same month, let alone at the same time.
That an organization uses a development environment you are familiar with should only be one of many aspects that inform how you think about that organization or whether you wish to work with them. They are clearly successful (using 7 year old environments suggests they've been around at least that long). So, figure out how they are doing it, what they are doing right, and what improvements they may be ameniable to, given the group dynamics at work.
run very fast.