Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Programming Software

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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Standard Software Development Environments?

Comments Filter:
  • you were at one end in earlier job and moved to the other end in new job.
  • by barrywalker ( 1855110 ) on Tuesday October 11, 2011 @02:08PM (#37681578)
    Run. Fast. This company is doomed without basic software engineering discipline.
    • 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,

      • by rihjol ( 904281 ) on Tuesday October 11, 2011 @02:57PM (#37682166)

        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.

        • by nahpets77 ( 866127 ) on Tuesday October 11, 2011 @03:20PM (#37682428)
          Reminds me of the quote "In Chaos Lies Opportunity"... Sounds like a perfect opportunity to become a "value added" employee by "leveraging" your past experience and introducing "proven best practices" to your current company.
        • by Matimus ( 598096 ) <mccredie@gma i l .com> on Tuesday October 11, 2011 @03:52PM (#37682850)

          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.

        • by asdf7890 ( 1518587 ) on Tuesday October 11, 2011 @04:04PM (#37682990)
          Definitely worth a try. But do keep your eyes open for ways out in case it doesn't work out well.

          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).
        • 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

        • by billcopc ( 196330 ) <> on Tuesday October 11, 2011 @06:13PM (#37684438) Homepage

          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.

        • Don't be silly. Orthodoxy doesn't thrive because no one has yet discovered an alternative. It thrives because of endemic management practices. A firm which even has a chance falling pray to such chaos can be safely assumed to have "personal ownership" of each project attached to key stake holders. Any change probably requires a careful political negotiation because each stake holders sees it as an encroachment on their territory. Each new guy will try to contribute his view on how things should be only
      • What if they're paying a fortune?

    • by ranton ( 36917 ) on Tuesday October 11, 2011 @02:28PM (#37681850)

      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.

    • by Anrego ( 830717 ) *

      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

      • 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.

        • by Anrego ( 830717 ) *

          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

      • 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

      • by s73v3r ( 963317 )

        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?

    • 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

  • Run, don't walk. (Score:5, Insightful)

    by badboy_tw2002 ( 524611 ) on Tuesday October 11, 2011 @02:09PM (#37681594)

    #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.

    • #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.

    • 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 (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.
  • regarding this company's practice. Yes it's common, no it's not a place you should work.

    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
  • by MrEricSir ( 398214 ) on Tuesday October 11, 2011 @02:13PM (#37681642) Homepage

    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.

    • 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.

      • 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

  • 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. :-)
  • by bondsbw ( 888959 ) on Tuesday October 11, 2011 @02:14PM (#37681656)

    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)

    by hondo77 ( 324058 ) on Tuesday October 11, 2011 @02:14PM (#37681660) Homepage

    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.

  • by Anonymous Coward on Tuesday October 11, 2011 @02:14PM (#37681664)

    * 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?

    • These are great questions (and there are many others that could be asked as well, concerning a multitude of important aspects of the work environment.)

      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.
  • by Synerg1y ( 2169962 ) on Tuesday October 11, 2011 @02:16PM (#37681680)

    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 :)

    • by shutdown -p now ( 807394 ) on Tuesday October 11, 2011 @02:44PM (#37682010) Journal

      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.

      • 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:


        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.

  • by BabaChazz ( 917957 ) on Tuesday October 11, 2011 @02:16PM (#37681684)

    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.

    • 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.

      • 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.

    • 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.

  • 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

  • by Faramir ( 61801 ) on Tuesday October 11, 2011 @02:17PM (#37681702) Homepage Journal
    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.
    • 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)

    by BigBuckHunter ( 722855 ) on Tuesday October 11, 2011 @02:18PM (#37681714)
    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?".
    • Re:Wisdom (Score:5, Insightful)

      by Unequivocal ( 155957 ) on Tuesday October 11, 2011 @02:48PM (#37682062)

      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..

      • The way I ask it is, "Tell me about your development tools and release process." Then I shut up and listen until they ask something in return or change the subject.
      • by Dahamma ( 304068 )

        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...

  • by PolygamousRanchKid ( 1290638 ) on Tuesday October 11, 2011 @02:19PM (#37681718)

    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.

  • 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.

    • Agreed. My two engineering jobs had version control, and none of the other stuff the OP mentions. Not having version control is pretty jarring.

  • 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 f
  • by dkleinsc ( 563838 ) on Tuesday October 11, 2011 @02:24PM (#37681800) Homepage

    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 [].

  • 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
  • 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)

    by MagikSlinger ( 259969 ) on Tuesday October 11, 2011 @02:26PM (#37681816) Homepage Journal

    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! ;-)

  • 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.

  • 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

  • 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.

  • by GPLHost-Thomas ( 1330431 ) on Tuesday October 11, 2011 @02:37PM (#37681942)
    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.).
    • 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.

      • I think you mistyped. I think you meant:

        both Git and Mercurial are far more useful and easy for anything that even the tiniest project should be using it.
  • by Lieutenant_Dan ( 583843 ) on Tuesday October 11, 2011 @02:39PM (#37681964) Homepage Journal

    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.

  • by vlm ( 69642 ) on Tuesday October 11, 2011 @02:41PM (#37681972)

    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?

    • 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.

  • by aristotle-dude ( 626586 ) on Tuesday October 11, 2011 @02:46PM (#37682034)

    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.

    • by vlm ( 69642 )

      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.


  • 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

  • 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.

  • by Charliemopps ( 1157495 ) on Tuesday October 11, 2011 @02:48PM (#37682066)
    Sadly it IS normal. But there's a paycheck right? Stay there until there's something that pays more... then leave.
  • Most companies don't know how to do software development, especially if they're not software development shops. If the project is a small one-or-two person project they might even be able to get away without version control for a while. It's pretty much impossible to scale up past that point though. Even fewer companies than have version control have good change management. So you'll never be absolutely sure what's deployed on production or whether you can rebuild the production servers from scratch if you
  • Yes, many of these things are standard in large development environments. The smaller you go, the less "standard" they might become. Nonetheless... I suspect that "drop everything and run away" might not be an opportunity for you, as if it were, you probably wouldn't be asking your question here. Every problem is an opportunity, right? Awesome! You have found a new opportunity to learn and grow. You have found yourself in a situation that rubs you the wrong way. How will you change it?
    • Run away? Y
  • 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

  • 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
  • It's not like the assignation of one man ever caused a world war.
  • by vlm ( 69642 ) on Tuesday October 11, 2011 @03:18PM (#37682406)

    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.

Competence, like truth, beauty, and contact lenses, is in the eye of the beholder. -- Dr. Laurence J. Peter