Ask Slashdot: Standard Software Development Environments? 362
First time accepted submitter sftwrdev97 writes "I have only been doing software development for about 5 years, and worked most of it at one company. I recently switched to a new company and am amazed at the lack of technology used in their development process. In my previous position, we used continuous integration, unit testing, automated regression testing, an industry standard (not open source) in version control, and tried to keep up with the latest tools, Java releases, etc. In the new position, there is no unit or regression testing, no continuous integration, compiled files are moved to the production environment basically by hand and there is no version control on them. The tools we are using have been unsupported for 5-7 years and we are still using old Java. I am just wondering since this is only my second job in the industry, is this the norm for most development environments? Or do most development environments try to keep up on technology or just use what ever gets them by?" What's it like in your neck of the woods?
Its a wide spectrum (Score:2)
Re:Worst summary ever? (Score:4, Funny)
The summary doesn't tell us the slightest thing about the job or the work environment...What sort of software is it?...There's simply not enough information up there to form an opinion.
Product Security Team at Adobe, with special responsibility for Flash and Acrobat?
No CI? No version control? (Score:5, Insightful)
Re: (Score:3)
I'd have to agree.
Keeping things safe and secure where I work is a challenge, and we have mandates (that are followed) that ALL of our software be within the manufacturers 'actively supported' lifecycle, plus no more than 90 days out of date in patches. Working things as out of date as described in TFS seems like a nightmare in terms of reliability, security and lack of features,
Re:No CI? No version control? (Score:5, Insightful)
Alternatively, if he likes the place, it's an opportunity to step up and say "here's how we can do things better." If it's well-received, it's an opportunity to show both expertise and leadership.
Re:No CI? No version control? (Score:4, Insightful)
Re:No CI? No version control? (Score:4, Insightful)
I've been in that position. It worked out. It was also much more difficult than I initially thought it would be.
I break my career growth into two areas: learning from the examples of those around me, and learning on my own. To maximize your growth you will need a good mix of both types. There are likely experienced people who can teach you many things wherever you go. What you really need to ask yourself is whether you value the types of things that you can learn from your co-workers in this environment. In this case, they can't teach you much about tools and process. What can you learn? If you can't think of anything that interests you then this sounds like a dead end, and you should probably leave.
Re:No CI? No version control? (Score:4, Informative)
Best case: you get he credit for improving the company. That would put you in good stead where you are and help your attractiveness elsewhere if you need/want to move on later.
Worst case: you get somewhere to work until you find somewhere else. No point dropping yourself out of employment until you have a safe exit strategy, especially with the job market the way it is in most places. Just make sure you aren't standing too near any fans, so you've got time to duck if something unsavoury hits them.
Lack of CI and automated testing and such is not unusual at all - you were lucky in your last place (I wish I had that luck!). Lack of good source control is something that you need to fix fast, before it bites you in the arse (and it will).
Re: (Score:3)
This doesn't happen unless someone high up in the heirarchy is insisting that this is the correct way to do it. If it was as easy as someone stepping up and making changes someone would have done so by now. At best, you've got managers who are oblivious to how much time and money it is costing them. At worst, you have some decades out of data lead engineer who is actively resisting change. Either way this is going to be resisted heavily by someone in the chain. Even if you take your suggestions to the
Re:No CI? No version control? (Score:4, Interesting)
Sure it is, and that's the route I usually take, but it's ten times more effort than you first anticipate. Even if you don't need to buy any new hardware, you still meet tons of resistance from people who refuse to change their habits.
Just a few years ago, I went through that hell convincing my employer to start using virtual machines instead of 10-year old PCs in the server room. He suffered from extreme sticker shock, would rather buy used stuff on eBay than spend a couple thousand on a white-box 2U server. Those things would fail every other week, they were awfully slow, and I wasn't too fond of driving out to the datacenter all the time to reboot a box or replace an (IDE) hard drive. It was like playing whack-a-mole with hardware failures. It took about a year to convince the boss to toss all that junk out and replace it with a big SAN and a few VM hosts. Just the time saved by not having to support crappy old hardware has more than covered the cost of upgrading to proper enterprise gear.
He finally saw the light, but it took a lot of nagging and teasing to open his eyes. Changing a company's dangerous or stupid ways is 10% technical know-how, and 90% psychology. You need to convince people their work will be faster/easier/better after the change, which often requires something to blow up in their faces before they'll even hear you out. Swoop in, save the day, and suddenly everyone's opening up their ears and budgets for your great ideas.
Re: (Score:3)
Re: (Score:3)
It all depends on how you do it. I've never had trouble but my niece is semi-sociopath and she got fired 9 times in a row. At least I have sense enough to be subtle about it. Anyway, just make a presentation on "things you've learnt at other places" and why it's a good idea. If they don't get it, you can always build your own environment or leave (which I did in one case - they just weren't into development). But test the waters first. Are you the sole programmer under 60? Maybe try and find one guy who lov
Re: (Score:2)
What if they're paying a fortune?
Re:No CI? No version control? (Score:5, Insightful)
Agreed. From my experience the lack of continuous integration, unit testing, and automated regression testing is the norm, but the lack of version control is simply inexcusable. It's not like it's a new startup or anything; if their tools are already unsupported for 5-7 years then they have been working this way for at least a decade.
Every job you take is an opportunity to build your skillsets and improve your career, and I find it unlikely that this job is the best place to do either. Unless you are able to quickly get management support in your efforts to improve development practices (which could significantly improve your abilities depending on how involved you were with those processes at your last job), I don't see why you would want to work there. I cannot imagine your coworkers are the best of the best, and your IT management probably has no idea how to run a software development group. (I have seen small companies in an uncompetitive niche do well despite such environments, but then again I also know someone who won the lottery)
Then again in this economy at least you are working, and who knows how good the IT industry is doing in your area.
Re: (Score:3)
I'd say it depends on what they are actually doing.
Rigid process and a solid tool set is usually a good thing.. but "room full of coders with a goal" can work in some situations.
As for the norm.. I'd say most companies fall in the middle. You've seen the two extremes. Most places have a handful of critical tools that are very well maintained and kept up to date.. and a whole bunch that are "we should really upgrade that" or "yeah, that's a messy pile of scripts, but it still works" and will usually have som
Re: (Score:2)
I'd say it depends on what they are actually doing.
Then you don't know what you're talking about and should not be allowed in a position of responsibility.
Not using version control is simply inexcusable. The guy needs to run fast (maybe his old job will take him back) before the place crashes and burns.
Re: (Score:3)
Version control, yes.. you'd need a pretty damn compelling argument to say that version control doesn't adds value to just about any dev operation. Even on an individual level, it's nice to be able to make huge changes safe in the knowledge that a previous version is just a command away. That said people do succeed without it (web devs in particular). If it were me I'd work hard to try and introduce it, but I certainly wouldn't run screaming just because of that.
My argument was mainly against other tools an
Version control is not optional (Score:3)
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 c
Re: (Score:3)
Well motivated, focused, and intelligent people can make masterpieces in the shittiest environment
This much is true. But you know what? Having those tools, especially version control, makes things sooooooooo much easier. And since they're so easy to set up, why the fuck would you want to bother without them?
Re: (Score:3)
I disagree.
As an owner of a software development company, I would LOVE for our team to use a more structured, process-oriented approach. Management support and financial support aren't the issue at my company. It's finding developers who have experience in such tools and processes, and having them embrace such methods.
Sometimes management KNOWS these things have payback, but can't figure out a way to kick-start these processes. Slashdotters frequently make fun of "management speak", and when I start prea
Re: (Score:2)
It's not a common misconception. It's very accurate. If they aren't doing these basic things, then what else are they doing wrong? What else are they burdening their developers with unnecessarily?
While it might be very possible that great programmers could overcome that, why the fuck would you want to?
Re: (Score:2)
Re: (Score:2)
I would add, management also likes to hear about risks and how they can be reduced or eliminated.
Run, don't walk. (Score:5, Insightful)
#1. That sounds horrible. If you're looking to do good dev work, time to bail immediately, and next time be sure to ask about process in your interview.
#2. On the other hand, if you're a career climber at this company, you can make huge impacts by driving the adoption of these kinds of processes, and will quickly vault your way to the top of the engineering pile. That assumes that this way isn't the grand design of some really stupid people, or that you don't have managers that will support this. In that case, see #1.
Re: (Score:3)
#1 can be bad if some manager is just pulling stuff out of a catalog and imposing it on the developers. It can be good if the developers are on board with the process and had a hand in tailoring it to the way their group works. Technology alone doesn't make a good process.
Re: (Score:2)
If the OP is looking to get a good job in the future, he'd do well to bail right now. What gets nasty sometimes is if you make the mistake of sticking around an obviously incompetent firm, you tend to get some of it to rub off. It won't necessarily hurt your abilities, but some firms do become a sort of pox on ones CV.
Option 2 probably isn't viable (Score:2)
keeping up with the world (Score:2)
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 b
Yes, and yes. (Score:3)
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.
Re: (Score:3)
Yes and not necessarily.
I don't think you need to flee your new job yet. If the work is interesting and the company culture is decent then maybe it is worth sticking around. You could help upgrade the company's software pipeline. I'd start by trying to get them to move to a good version control system, then add an automated build system, and then add some unit tests and an automated test framework.
On the other hand, if it the corporate culture is only OK or bad then yeah... flee early.
Re: (Score:3)
Never flee until you have somewhere to flee too :-) People who say they'd never work in a place like that must not have a lot of experience in needing to take any job they can get. It can actually look bad on a resume to be seen to be job hopping frequently, and it also looks very bad to see a long stretch of no employment no matter what the reason.
I had a job after leaving school that was a complete mess. We didn't even have QA. Everything was seat of the pants, one or two person teams. I set up a mak
The real world, unfortunately (Score:2)
Do what is necessary and right (Score:5, Insightful)
When I started, we had SourceSafe for version control, and Visual Studio 2002. That was pretty much it. Now, a few colleagues and I have made CI and unit testing a norm (at least for projects we are involved with). We now use CruiseControl.NET for CI, MbUnit for unit testing, SpecFlow for BDD, and Subversion (VisualSVN) for source control. We have also upgraded our toolkit significantly with open source and commercial tools (such as Resharper, various Red Gate tools, and various control libraries).
The point: be your own advocate. The boss isn't going to care or even know about most of these things. Either that, or find a job where these are already established.
Heh (Score:4, Interesting)
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.
Obvious interview questions you forgot to ask: (Score:4, Informative)
* 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?
Re: (Score:3)
Asking them tends to reflect well on you, showing your alertness and discernment. Nothing wrong with that. But the way job interviews work, it's you the applicant being interviewed. For the most part, you have to take the cues you're given, starting with you making a trip to the employer, not the other way around. In other words, you're the supplicant.
Cost and size of company (Score:5, Insightful)
To answer your question better, I would have to know the # of employees at both companies aka size and the IT budget. The question to ask is are they giving you the tools to be successful. To directly answer your question though, yes for smaller IT shops it's the norm, for dedicated IT service companies and larger corporations it certainly is not. Enterprise environments with the project flows you speak of all cost money, a lot of, system debuggers, analysts, QC are all people the bosses need to hire, and they do not usually come cheap.
Also at smaller shops it is up to you to take the initiative to upgrade usually since there is nobody else to do it and the bosses are typically busy with other stuff. As long as you are comfortable in it though it doesn't matter. What you'll notice is the standard is also lower, most CEO / boss people aren't ignorant / stupid enough to think that a smaller IT crew can produce the same quality as a bigger one, so everybody just rolls with the bugs and punches until a working product is ready.
If this is an IT firm though, and they are running outdated software, then chances are your management team is NOT IT and that is usually a good sign to run. I've only truelly enjoyed working with IT people when I approach the coding realm, and everybody else is kinda meh, but you do what you to to put bread on the table :)
As you become more independent though and possibly as your skill range widens, you may find things work out for the best in your career as there are more job paths to take. A common one is sql developer to sql dba, they are so closely related, experience can jump you from one to the other.
I'm basing this all on your going from a larger well organized shop to a smaller to less organized one based on you naming the practices and lack of. I guess it's always possible to have a shitty large IT shop too, just talk to Sony :)
Re:Cost and size of company (Score:4, Insightful)
Even for smaller shops, it's definitely not the norm to have no version control at all.
Well, at least not for shops that are worth working at.
Re: (Score:3)
I'm a one man shop and I use version control, CI becomes a non-issue. I'm not convinced that unit testing is practical. However, there's one big red flag in the OP's question:
NEVER DEVELOP ON OLD TECHNOLOGY.
You will eventually find yourself out of work and unable to find work because you have a deprecated skillset. I've seen a lot of people in that situation. I know a very good Access programmer who really needs a job right now.
Deliberately behind the times (Score:5, Informative)
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.
Re: (Score:2)
If you're using Visual SourceSafe, it's probably worse than not having any VCS at all. Reason being that VSS is extremely flaky and plain unreliable, but lures people into thinking that their code is safe because it's in a VCS (which is true of pretty much anything else, just not this case).
Kill it with fire, and upgrade to something that works. If you insist on using ancient software, run CVS - it's still better by a long shot.
Re: (Score:2)
I won't argue about VSS' flakiness, but I will say that so far it has not failed us when we needed to revert. The flakiness starts when you want to do something less than straight-arrow, like split a project, and there a lot of the flakiness actually comes from the integration with the other VS tools. In my experience. Your mileage may vary.
Re: (Score:3)
Everyone who uses Visual Source Safe as version control system should rething his job. Sorry, but Microsoft does not use VSS
in their own development because they know what junk it it. Using this system as version control system given the myriads of really good free alternatives is inexcusable.
Depends on the Economy (Score:2)
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
This is your opportunity (Score:4, Insightful)
Re: (Score:2)
I'd try to identify the most time consuming and error prone manual operations. I wouldn't kick things off by pushing unit testing. Some people look at testing, documentation, etc as more of a tax than a benefit. If you can come up with some tools and scripts to automate those slow error-prone processes first, you'll get the entire team listening really fast. Figure out what helps your workflow and push it out to the rest of the team.
Wisdom (Score:5, Insightful)
Re:Wisdom (Score:5, Insightful)
I'd suggest being thoughtful in terms of how you ask those questions. If I'm interviewing someone and they give me the third degree on process stuff, I start worrying that they are a "process fanatic." Now don't get me wrong - I'm all for good dev process but there are some people who are fanatical and irritating and not nice to work with, and getting a lot of questions about it would be a small red flag. Just making this point to add nuance to your point.
I absolutely think you should inquire into what the technical and process aspects of the job look like (among others). Just be thoughtful about how you ask..
Re: (Score:3)
Re: (Score:3)
And, really, even without asking questions like that directly you should be able to get am idea of how rigorous their development processes are. If I went through an entire interview with 4-5 engineers and not one of them asked me about unit testing, versioning, deployment, scalability, tools, etc, then that's a pretty big red flag right there...
The "norm" is . . . there is no norm" (Score:4, Informative)
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.
At least VCS and IDE must be there (Score:2)
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.
Re: (Score:2)
Agreed. My two engineering jobs had version control, and none of the other stuff the OP mentions. Not having version control is pretty jarring.
Quit when you still can (Score:2)
This is definitely not normal (Score:3)
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 [slashdot.org].
Re: (Score:3)
Sorry, obviously the link is incorrect. The correct link: The Daily WTF [thedailywtf.com].
How big of a development environment we talking? (Score:2)
Two Choices (Score:2)
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
Yes, it is normal. (Score:4, Interesting)
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! ;-)
you just learned a valuable interviewing lesson (Score:3)
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.
Yup, this is normal (Score:2)
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 a
Version control first (Score:2)
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.
At least put YOUR changes on a VCS! (Score:3)
Re: (Score:2)
Yea, or they could use something designed without grandious plans of dominating the world with a decentralized ... something, I don't know what they were going for, the point is both Git and Mercurial are far more complicated than need be for anything but the most complex projects.
Contrary to popular belief, anarchy is not productive.
Re: (Score:3)
both Git and Mercurial are far more useful and easy for anything that even the tiniest project should be using it.
Make the software open source! (Score:3, Funny)
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.
56 posts and no one asked why? (Score:5, Insightful)
56 posts so far and no one asked why? This is the crucial question.
1) They hired you specifically because YOU know good dev practices and management wants to model everything after you, or at least after your former employer. Well, golden boy, stay put and rake in the cash. Should be easy to angle into a management job assuming you want that. Maybe the boss thinks he's getting a promotion and is trying to put you as his protege.
2) They started so small they didn't need those things. Now they're big, so they hired a guy from a big time operator. Sounds like it won't be too tough to convince them the new big guy comes with a new big VCS or a new big testing system.
3) They're planning on selling / getting out of the field and just need to keep you around until the sale or bankruptcy is final, or they're completely bonkers insane. Run like hell
Also you have to factor in the change difficulty level. Is your team... just you? Then what the heck does the boss care what your VCS is, just roll one out. Is your team also fed up old timers who know better? or is your team all clueless noobs? Will IT slap you on the back and buy you a beer if you install a GIT repo "hub" like gitolite, or take you out back and shoot you? How bout management?
Re: (Score:2)
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?
Thats pretty much a universal 'take you out back and shoot you' response, unless of course you talk to them about it first.
You don't start fucking around on someones network without talking to them first. When you are at work its not YOUR PC or YOUR NETWORK or anything of YOURS, its THEIRS, and you should be respectful of the fact that you don't know everything going on and you clearly are not a system admin so you know even less about whats going on with their systems.
Version Control a must. IDE useful too. (Score:3)
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.
Re: (Score:2)
I would stay away from GIT and other system popular in the blogosphere and go with SVN as it is tried and true
We ran from svn fast as we could because its dying... git has taken over, like it or not. Your quote sounds like something fresh outta 2006, but that was a long time ago.
All git pullers have essentially a full backup of the repo. All pullers are what other VCS would call a hub. With SVN you need a backup and availability strategy for the SVN hub, if the hub is down you're dead in the water, but not with GIT. With GIT you still need offsite offline backups, etc, but level of admin work is much lower.
Wors
Leave the company (Score:2)
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
Where I am... (Score:2)
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 (Score:3)
Most Companies (Score:2)
Every problem is an opportunity (Score:2)
Its your second job (Score:2)
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 hav
Depends... (Score:2)
meh..... (Score:2)
Ticketing system? (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:2)
Obvious MS troll is obvious.
Re: (Score:2)
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.
Re: (Score:2)
This has exactly zero to do with the question asked in TFS.
Re: (Score:3)
A lot of the times things like this don't help the bottom line.
I've worked with a lot of developers who get on a kick about this development methodology or this version control or this framework or this pattern and if given any sort of leeway will shoehorn it into every single thing they have even a small stake in.
Sometimes there is a good fit, but often it is just adding pointless overhead and complexity to something that doesn't need it.
Re: (Score:2)
Most places simply accept that not using those types of tools helps the bottom line, and that it is the job of managers and developers alike to keep the goals in mind and have the vision to see them through to completion, or that bug tracking is an aspect of Support.
When you only have a couple people, you can get by without continuous integration tools or automated testing. The problem is convincing the business that growth is more than just adding warm bodies.
What's the deal with CI? What's wrong with merging at completion of work units -- like 2-3 weeks instead of daily?
Re: (Score:2)
You are alerted to bugs sooner. You know exactly when a regression bug get added, and can fix them sooner. However, remember, CI tests are only run when stuff is checked in to the trunk, or certain branches.
Re: (Score:2)
Most places simply accept that not using those types of tools helps the bottom line
Any place that thinks not using Version Control, or many of the other tools, especially when low cost or no cost solutions are available, is run by incompetent idiots.
Re: (Score:2)
Anything that can't be automatically tested should probably be redesigned to have some test hooks added. I/O can have some kind of loopback or test fixture, GUI testing is easy to automate, it's generally rare error conditions that can be hard to simulate. Those are the cases where you might need to add a way to inject errors upstream to force the condition.
Re: (Score:3)
Anything that can't be automatically tested should probably be redesigned to have some test hooks added.
Then you're testing the code you added to do testing, not the code you needed to test.
If you're redesigning your code JUST for the purposes of testing, you've failed to understand what you're trying to test.
Re: (Score:3)
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.
Re: (Score:2)
I'd go so far as to say that it's probably something that the OP should have inquired about when being interviewed. Whoever is conducting the interview ought to be able to answer a basic question like that without having to go to too much trouble.
Every job has tools of the trade that are essential and a larger number of ones that are optional but greatly improve the efficiency of the job. A well run company will have all the mandatory ones, and in up to date versions, and probably a few of the optional ones
I would say, fight or flight (Score:5, Insightful)
It is unusual for a software shop to be as immature in its tools and processes as your new employer. Rather than join in the chorus of voices condemning your employer, let me suggest an alternative.
Understand the reasons for the current situation. Professionals, especially engineers, usually have a rational basis for their choices. Perhaps they are disillusioned from having wasted time and energy in the past (see Test Automation Snake Oil [satisfice.com]). Perhaps they have a few heroic individuals who hold everything together and don't see the need for tools. I have no idea. I cannot wrap my brain around how someone would try to get by without revision control but that's immaterial. You have to understand that before you can either change it, or learn to live with it.
Read the IEEE paper, How to Be a Star Engineer [ieee.org]. Then, be a star. Help your team see the value in some basic tools like version control. Introduce them. Train your peers. Proceed slowly and patiently. Talk to your managers and senior staff about the risks you can mitigate and be realistic about the costs of doing so. In other words, help your company do better software engineering.
It is very possible they hired you because you come from a disciplined engineering shop and can help them improve their practices.
Or you can take the coward's way out and flee before you try to teach anything or learn anything.
Re: (Score:3)
It is unusual for a software shop
Assuming its a software shop... I've never worked in one, but I have some decades doing dev work as basically a tool maker at a couple places. The guy's description sounds like a lot of embedded places I've worked where "things just kinda got out of hand" after starting as such simple little projects.
One minute you're basically writing a one page web cgi front end for "grep" and it seems like next thing you know, you're creating a giant data warehouse and statistical analysis system, wtf?
Re: (Score:3)
This is exactly why even the smallest projects need to use basic tools like version control right from the very start.
Once anything I'm working on gets larger than, say, a couple files or a hundred lines, I set up a version control system for it. If I find myself doing something (such as copying binaries to a machine) more than a few times, I make a script for it and check that in. I set up a Makefile for even the most basic programs. Then, as the software gets larger or more people work on it, that's al
Re: (Score:2)
This is excellent advice. Very few situations in life that appear to be irrational actually are. Almost always they come from some past experience that taught somebody a good lesson too well.
Take version control, for example. My first exposure to version control software was Microsoft's Visual SourceSafe [wikipedia.org], back in the late '90s. Maybe it's better now, but back then VSS was an incredibly poor product. Imagine if someone managed to shrink-wrap the experienc
Re: (Score:3)
If your heart acquires strength, you will be able to remove blemishes from others without thinking evil of them.
Mohandas Gandhi
Smug bastard never had to deal with Team Foundation Server.
Re: (Score:2)
Start looking for a new job -- unless you are in a position of authority and can fix that train wreck.
Or fix from below. The key to that is not being cocky.. introduce stuff slowly, in a "this might be a good idea" vice "you are all idiots for not using this" kinda way.
If the people you work with really are idiots, then yeah.. run. Fancy process and powerful dev tools won't fix bad programmers, and in fact will just make your life more hell because in addition to messing up the code, they will now mess up the process (ever seen someone try to use VC who just doesn't get it.. "but it compiles on _my_ box" ..
Re: (Score:2)
I agree. Noone likes a smart-ass. You have to use guerilla- and partisan techniques.
You could use version control yourself, get it working and ally yourself with another coworker. Configure the SCM for him and make sure it is working properly.Make him see the light and be a proponent, too.
If this is impossible, suck it up or change employer.
Re: (Score:2)
I run a small software company with 3 programmers on staff (my self included) and I use version control. There's no excuse to not use and I'd be scared of any place that didn't. Hell, I used it when it was just me and I was hoping to be able to hire other people someday.
Re: (Score:2)
Version control is a must for any development more complicated than "hello, world", even when it's a one-man project. There are no ifs or buts about it. There's a reason why VCS date back 40 years.