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?
We usually just send the grunt work to India, and let them handle the details.
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.
Hell no! This is not normal - run away quickly!
#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.
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.
That must suck. I would try to talk to the people in charge to see if they could get you guys something better. If that don't work, try getting the software for free if you know what I mean. (as long as your not in Belgium)
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. :-)
No, this is not the norm.
This sounds like a disaster.
-paul
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?
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?".
I work on a large multiyear project with 300+ people. We used RSA from IBM for java development. The version control system has changed over time. Since it is a long project we don't use the latest. Instead we are one version behind. There have been upgrades during the project but there was alot of care that we used versions that worked. There is enough people on the project that we are not doing things by hand like at your new position. Things are also very organized because we have been working on this a long time.
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.
KYLE'S FATHER
Do you understand?
KYLE
Yes. Yes, I do, Dad. Now let me tell
you how it works in the real world.
At your company, you've got a serious problem with management. It might be your direct managers, or it might be unreasonable demands of the higher ups forcing your direct manager to not get what s/he wants
You may not be (and are probably not) the first to bring this up, you'll need to speak with your direct manager about this.
. Management needs to realize that they need to readjust their priorities on how fast they can respond to things, and allow time / hours to be budgeted towards improving the development environments / tools / practices (which I'm sure your co-workers also are aware of).
If they won't / can't make this happen, then hey, it's a paycheck, and you've said your piece.
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
I am not a software developer, but I am in a similar environment. I went from a media company that had over 20,000 employees to an insurance company that has 1300. The programming groups are just like your situation. What's frustrating is that the developers will release a change and not even notify us on the application support side.I find out about new versions when my users call me to complain about a bug.
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.
Well, since you have experience with unit testing, version control, regression testing and the like, how about you make your case with your manager. Treat this as an opportunity, not a challenge. Your situation is typical for a company (or a department) that just existed out of 2-3 developers and had to expand.
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.
You assume that all the layers you described are necessary for software development, aren't you? The point is: All this infrastructure needs to be maintained. Have you ever checked how much time you spend with the real product? Or checked the overall cost?
Sometimes there are very good reasons for such a low-level approach.
I give you an example: I work in a private health insureance company that is more than 100 years old an has 5 million customers with about 20 million contracts and more than 50 millions of different tariffs and policies. Every day about 20 000 bills need to be processed. The base system is a zOs based mainframe. It has an uninterupted uptime of 11 years now!
Developing software for this environment is at the same time extremely challenging and extremely easy. It is challenging because one has to take care that the tools used must be available in 20 + years from now on. So the math is done with Fortran and SAS, database stuff is done with cobol etc.
The easy part is, that one needs not to learn the newes style or program, one can become a real master of the particular infrastructure and of the issues.
There is no need to run. There is a serious need to evaluate your situation: Do you understand why the development style is as it is? Do you understand the business idea that is behind this development style, if any? Maybe you find out that there are very good reason fot his. Or maybe you where hire because you have knowledge in the newest technology and it is hoped you can improve the situation.
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.
I was the driving force behind one employers adoption of version control, and of migrating off a vendor-specific language. If they are willing to change, you can make a big difference, and version control is an easy sell - everyone has a horror story about deleting something important.
Dev environments and testing are much more variable - some places do not support SOTA testing, and you may have to get used to it. Some places don't have any way to emulate the deployment environment.
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
In this case, it depends on the size and focus of the organization. Generally, the bigger the shop, the better the tools, and the more systematic the practices. When you run into a place using old tools and developing for out-of-favor languages, it's often because the folks on the development team want it that way - they're comfortable with the existing system, and have a vested interest in making sure current practices don't change.
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
Sounds like there's room for improvement at your current job, but too much process can also be a bad thing.
You're in a great position to make positive change in your new organization. Convince them to use version control and get an up-to-date toolset at a minimum. One of my old employers, an innovative tech company, had a motto to fail fast and iterate quickly. That approach can be a good thing if you're trying to innovate.
When companies get down to it, building software is either viewed through one of two lenses: part of a profit center, or simply loss due to overhead. With the typical ignorant business view of "profit at all costs, make your quarter numbers, kill anyone in the way" that means you'll experience either:
A.) If you contribute to profit (e.g. building software that helps make money or is sold) - You should expect the minimum level of support to keep things "mostly" up to date. This is where OpenSource tools shine (since they don't have to cut a PO & your salary is already a sunk cost). Good developers will help move things along with minimal budget purchases where needed. Play your cards right and the "we're not keeping up with industry" argument can get you some good results. Try that line at the beginning of a quarter after some good sales have gone through :)
B.) If you're just a red line on the balance sheet (e.g. building software that just lets things operate) - Your screwed. You're already considered a "drain" on the balance sheet. If you think you're going to get funding to spend more money on something that's not bringing in revenue you're dreaming. Now you might stand a snowball's chance in hell of getting funding for something, but you're going to have to petition to PROVE how spending money will free up your time (since that's a sunk cost) to be directed to something else. The "we're not keeping up with industry" argument goes nowhere here.
Some free advice - get yourself a job in category A if possible, where the software you write brings in real money to the company: where they need you and have to play nice politics (and they know it). Otherwise, your salary and everything you need to do you job will always be "an expense to to be minimized" by a stupid PHB who would pocket your paycheck towards his ill-gotten bonus in a _HEARTBEAT_ if he could....
Sane developers use Visual Studio. Most of the crowd around here are somewhat masochistic in that they like to use a bunch of non-integrated and unrelated tools to accomplish their broader development goals. I hear they also write makefiles from scratch using vi -- which I couldn't even figure out how to exit from.
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.
Instead of posting the question on Slashdot, where you'll get a lot of useless, conflicting advice, why not talk to the people you work with? You're the new guy on the scene so maybe they have reasons for working this way. Bring it up at the next team meeting. Say, "Hey, I have some thoughts on on tools I've used before. What do you think of... [insert tool you used before here]." Tell them how much it will cost and why you think it's a good idea.
In the past I've introduced imaging software, backup scripts, remote desktop control software and document recovery tools to companies where they just weren't aware such things were available at an affordable price.
Maybe you can get changes made, or at least find out why they're working in this style. If you don't like the way things are going, then you can consider your options.
but thanks for all of the replies.
I agree with other posters that...
- (1) you need to get out quickly (or take the lead in introducing practices that are more professionally responsible)
- (2) in the future, you need to ask about these items IN THE INTERVIEW; fwiw I would be disinclined to hire someone who wasn't showing an interest in these topics
That said, I think it's also important to include the counterpoint: these practices usually scale with the maturity and seriousness of your project. If the software you're writing doesn't (1) send billions of dollars worth of hardware to Mars or (2) assist in open-heart surgery (just 2 examples), then perhaps it doesn't need as many protocols and quality measures as software that does. These practices do come at a cost. Don't apply them as a matter of religion; first be sure they're justified by the business value they offer.
Keep that last bit in mind, but NOTHING excuses them from basic practices like SCM. Either make some improvements or move on.
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.
What YOUR questions should have been during the interview process . . .
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
Yes, it is normal.
No, you probably can't change it. (depending on how egocentric the management is)
I tried changing one company to using svn, it was like pulling teeth, I was accused of deliberately complicating things to provide myself with job security, yadda, yadda, yadda.. in the end, they liked it for about a week and now they don't use it at all.
Software development is something I've been doing for 20 years or so, the #1 burnout factor is, IMO, dealing with insecure managers.
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...
After scanning a number of comments, it looks most of the highly rated comments aren't actually addressing the actual question.
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.
Are you working for Adobe now?
When you look at all the non-secure software that Adobe puts out, this can be the only reason.
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
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
He's talking about the parent and obvious MS-astroturfer North Korea. Read his post history for a hilarious failure of subtly. My favorite:
No I'm not a Microsoft employee. Why does everyone always think you have to work for some company if you give positive comments about them?
If he doesn't work for Microsoft, he should, because he's one hell of a troll. It's always a similar pattern, "Such and such non-MS technology is okay, but the competing MS-technology is surprisingly superior!"
It's mostly just one time thing where elitist Linux geeks (those using on desktops, I actually use on servers too) want to show off when they once have the change.
it's a lot easier to rootkit and hide in Linux based systems than Windows, and most people don't know how to get rid of them too. Hell, in Linux a simple rootkit can work just by editing the system commands like ls.
Also, don't forget the fact that Google royally screwed over their existing users when they seriously limited the available resources and changed pricing just a few weeks ago. And how do you know Google won't discontinue the service soon enough as they seem to do with a lot of their products. I can't rely on that. At least other services give me some reliability.
I run Linux servers myself too, and I think they're better in some situations. At the same time I can also see and understand that there's also lots of Windows Servers around and they also do better job at some things. The fact is 50% of servers run Windows Server, and you can't get around that. Personally, I use the best tool for the job and don't really care about all the evangelist bullshit.
Sorry North Korea, you're not going to change popular opinion on /. by pretending to not have an agenda. We're not that stupid.
Maybe HR / a non tech manger did the interview and they have no idea about the software being used.
You have a production enviroment?
Luxury!
All we have is a cardboard box in the middle of the road, and we're lucky to have that.
You kids these days with your version control and latest releases...
welcome to the real world. i've been setting up development environments for over 20 years. maybe 10% are done well and then it falls off very steeply. there are teams still using cron, shell, and perl to do their builds. almost no-one uses pre-integration which is an order of magnitude better than continuous-integration. even when teams do use most of the tools that have become made available in the past 10 years, its generally not well maintained, out-dated. can teams still be successful without a good development environment. Yep, it happens everyday. It's just requires more brute force and long wasted hours performing tasks that should take minutes that take days and weeks. It seems almost impossible that this could be true, but once you've moved around a bit. The hardest part of about improving the development environment is not technical, it's getting buy-in and that means the right priorities. the development environment in most places is the last thing folks will work on, as they are so busy overcoming it to make then next delivery. another pattern you'll notice is that it is rare to see even the most basic development practices applied to the creation and deployment of the environment. it generally is a hackfest.
I would draw a distinction between "keeping up with technology" and getting your job done. You will learn eventually that the only reason to ever upgrade or re-write something is when there is a compelling need to. Blindly updating and grabbing the latest "keeping up with technology" will put you into a tailspin. Most of the buzz is just that. Ignore it and do what makes sense to you. You sound like someone who isn't willing to put such systems in place.
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.
Every place I've been, there were "process weenies". At least, that's the attitude you have until you slow down and realize that without the weenie you'll lose your buns.
It sounds to me like you know what this company needs if it's going to produce software that doesn't just blow up.
This could be your mission. Get some process and standardization going. Dare I say it? It could be you. You. You could be that weenie.
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!
Welcome to the wider world of software development!
That's pretty much standard. It sounds like you were lucky with your first role, and fortunately, since you were lucky enough to begin your career within a well run development team, hopefully you'll be able to take some of what you've learnt and bring about some positive changes in your new team. Unfortunately if they've been working like this for a long time, it may be difficult to convince them that there's a better way...
Good luck!
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."
Excellent essays on how it should work:
The "Joel Test" http://www.joelonsoftware.com/articles/fog0000000043.html
"Getting Things Done When You're only a Grunt" - about fixing broken process when you're not in management.
http://www.joelonsoftware.com/articles/fog0000000332.html
it has console.log. So where is the problem?
The other half of why is "Why are they doing that?" Usually there is a reason. For example, do they use a 5 year-old Java to maintain compatibility? If you start building with the latest Java you now require the latest JRE with your product. Are they not using version control because they still considering their small output to be non-mission critical, development, prototype, or even non-software? (I would still suggest using RCS or SCCS or something for version control)
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
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
All those practices, processes and buzzwords do not matter much if the end result is not better.
Did you verify what the end result is?
Do you have the customer perspective in this company?
Did you have it before?
Okay, I've worked with a company that was on top of tools and best practices and was dysfunctional, a company with no organization that still got things done and a few in between which honestly were the ones I was happiest working with.
The hyper on top of it company spent more time worrying whether a data encapsulation class was properly unit, integration and performance tested than in shipping a product that customers wanted. Dealing with customer feed back then was an abysmal exercise in management asking why process did not work. Oh and new tools that aren't tested make developers crazy.
The under organized company had good vision and while getting things tested was soul sucking customers liked the product which was gratifying.
The companies in between that do good products and use version control and some kind of formal testing make developers proud of their product while slowing the decent into madness so yes be your own advocate and try to get them into version control and some sort of build process. ( I sold this once just by telling management that this would yield consistant and usable version numbers which they turned into savings in support ) and if you get unreasonable push back then leave. My advice though is don't go whole hog. Get version control first.
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
I've experience a small shop like the one described.
Two places that use Visual Source Safe (VSS) (Because everyone did bak then), but moved on to CVS in one case (early 2000s), Subversion (SVN) in another.
A company will go with something for a number of years, then change when it feels it needs to. Then it can be a big change. We're moving now to Maven as our build and integration tool, Jenkins for continuous integration, SVN for source control. Previously we had Ant, CruiseControl and VSS. We're staying with Eclipse. We're looking at CDI and JSF2 on the front end, but integrating with our legacy application code on the app servers. It's easy with a CDI extension, and these technologies seem reasonably mature now to be worth working with.
These tools are worthwhile. Continuous integration and testing are very useful. Maven is powerful and encapsulates the build process well. Jenkins just fires off Maven at the right time so gives nice separation of concerns. It could be worth the original poster trying to champion some of these things. I think the company will see the benefit.
A post above mentions Intelli-J. Eclipse is nice. The Maven integration can be a little rough at times, but the tools are incredibly powerful. I think a lot of Resharper is copied from Eclipse! Having gone back to Java and Eclipse after some time in the Dot-Net world, it's nice to be back and I notice how much more there is in the latest version. If you've been using Java with VSS then you'll find the integration between SVN and Eclipse excellent! CDI Events make Dot-Net events look poor, but LINQ was nice when used with care :-)
Get another job lined up. This is not an economy to be quitting paying jobs without something in place.
Perforce is for chumps with mega budgets that can afford to have build engineers and people who specialize in running a super complex version control system. There's zero chance this guy has either of those things if this company doesn't have version control yet. Git (or any of the other DVCS systems, mercurial, bazaar) beat SVN to pulp in flexibility, ease of use, and speed. There's a good reason people are moving away from SVN toward them.
The comments about Resharper, Intelli-J and CruiseControl are right on though...
I've done this job for decades, including many years before version control.
Those were the dark ages of pain and terror and confusion.
Just maybe you can help this company move on, and win a gold star.
Possibly you'll be banging your head against a brick wall
a) Are you an evangelist? If yes, go for it, but let your bosses know this will be 25%+ of your workload for the next while. They may welcome it, and you may end up kicking the company into much better shape. Could be promotion in it etc.
b) Are you a coder who wants to work with other great coders? Leave. If this company had any great coders now, they'd have SVN/etc. It's not a 'maybe'
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
Puleeze. You're lucky if you have version control in some places. The biggest problem is still the same: the vast number of companies do not really understand technology THEMSELVES, they hire managers who subscribe to some daft idea that you can manage anything if you have METRICS and they throw knowledge out the door because THEY DON'T LIKE HAVING TO DEAL WITH COMPETANT I. T. PROFESSIONALS. Instead, they rely on believing the marketing hype. There are plenty of companies out there who use new technology only when Microsoft promises it will decrease development costs and they think that means developer salaries, yet they still want functional systems. They want to claim they use a particular development methodology, but no methodology makes up for the lack of complete documented systems analysis and design.
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.
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.
Even for smaller shops, it's definitely not the norm to have no version control at all.
I moved to a smaller start-up place three years ago. Owner says to me, "There's a lot of code that Matt (the former lead developer) had and worked on, should be a good base to get started from." Great, super.
After looking around, I found an older Dell that was his workstation. He had about 150 different subdirectories in his home directory, some with similar names (eg, processlogs-1, processlogs-2, etc). In each subdirectory was where the version control magic actually took place. Each source file had a matching suffix number corresponding to the revision number. Sort of. A text file in each directory had the "official" revision number, except when it didn't which was about 80% of the time. And usually if it did, the actual "working" code was in another subdirectory anyway.
It took about a three months before statements like "See if Matt had anything that might help with this..." stopped being uttered. I finally had to come out and tell everyone that we're getting source control, everyone's using it, and we're throwing away all that old code. Assuming you could find a working version, everything had what looked like Matt's favorite parts from three different styles, but not consistently.
It helped that we were moving in a new direction as a company, but the owner really thought he had value in all that code Matt wrote for him for two years. What he had was a mess that would have taken someone competent about 4-6 months to write. "So, yeah boss: Matt basically overcharged you for a shitty product, perhaps 1% of which has any real persistent value to us going forward." He wasn't happy to hear it. Was rough, but now we have an actual build system, automatic documentation, unit tests, automated deployment, backups, change lists you can actually use... all manner of wonders.
-B
Thats how we do it! Most low tech dev environment ever. Its a great throwback and I get stuff done just fine. Inherited this from the former programmer and oh man is it bad. Still works though. AND this is a mission critical environment! LOL!!
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.
The last 2 positions I had:
First had basically same as OT. Up to date java, but no testing / version control.
Second started basically the same, but I implemented version control, build control, and some forms of regression testing. Unit testing was next on the list when the company went under.
Have you ever seen anybody who was promoted for showing the existing management how wrong they were in theory and practice? I though not. Given that, you have an excellent opportunity to suggest improvements -- an opportunity to put theory and one way of putting it into practice into terms that are meaningful to your new firm. (ie. Don't expect to copy old firm's tools lock stock and barrel across to new.)
It sounds like a very interesting situation. Don't bail out as some have suggested.
forget about English. Just shout out a torrent of buzzwords and the check is in the mail! proven practice
-- no sig today
You have not heard? All SE is going to India for 5USD/hr at most. You cant afford all that s/w licensing
end of comment
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.
Sounds like the development environment at my previous place. I spent months just trying to get them to start using an issue tracker. Pointing out that the huge backlog of bugs/features/deadlines can be organized and managed so we don't have a client calling 2 days AFTER the deadline for a feature/system we haven't even started working on and asking "where the fuck is it?". This kept happening every other month or so!
My advice is to ask them why they don't use such tools. If they say that they don't have the time to learn it, then find the time and do it yourself. And teach everyone else. It will save your ass many times over. Point our the places where such a tool could have saved them time/money. If after a while they still don't see the benefit in it and are still resisting, its time to find a new place to work.
And next time you will have another thing to ask at the interview.
Frankly - you can consider making a difference by adding "best practices" and dragging their heads out of the sand.
But - in seeking out the notion of becoming the "hero" -- you really have to be honest about WHY they are not doing things already: what is preventing this team of your now co-workers from doing even the most basic steps?
Is there a company cultural issue? i.e. Management not respecting and appreciating the value of invested time to establish proper software engineering?
Or - are they are just very very foolish (which is unlikely - but really if so - that is a larger problem).
You also need to consider your role in the team -- and within the company. Are you empowered and *supported* to make incremental change?
One of the KEY changes you can start with is "Lunch and Learns" to interview your team mates -- and share ideas.
If you create enough ground swell around how these practices make jobs better. costs lower. and people happier -- you can be that hero.
However - be prepared for disappointment if the right people aren't supporting this.... And if your peers are clock punchers who just draw the paycheck. Sometimes its too big a fight -- too many flies to swat down. And if THAT is the case -- politely bow out with a respectful "creative differences" and definitely incorporate into what you're looking for at your next gig.
good luck.
Frankly - that you'd have to "post" to Slashdot for this tells a few things:
1) you're kinda a dick.
2) you're not really seeking "Advice" but likely more seeking fodder for how you're better then the great unwashed who are just idiots.
So - you're better then them.
you can step up and be a mentor to your new team --
or you can leave - and then cast disparages for the balance of your career.
either way - you're still likely just another "I'm so much smarter than my peers" kinda guy. Or prove me wrong. step up to this challenge. earn your job.