Slashdot Mirror

← Back to Stories (view on slashdot.org)

Same Dev Tools/Language/Framework For Everyone?

Posted by kdawson on from the one-size-fits-none dept.

AC writes "Upper management of the company I work at recently declared that all new development should be done with a single combination of development tools, language, and framework. The main rationale is that people can be relocated from one group / project to another faster, because they don't need to learn a new environment when they switch. Of course the chosen language / framework used by everybody does not need to be the best tool for the job, but it should be good enough to allow every project to get done. What does Slashdot think about this? Is it OK to use the same development tools and language for every project, instead of choosing what fits best? Will the time saved be sufficient to offset the time lost to the 'not the best tool for the job' environment developers will be forced to use?"

12 of 519 comments (clear)

  1. Choose them all under one. by jpyeron · · Score: 5, Interesting

    We frequently encounter this issue with our clients (government, military, and commercial). We know that this can be a very bad thing if they capriciously apply it across the board. What we have recommended allows for the most flexibility, while minimizing the "tools". In order of importance.

    1. Cygwin (0$)
    2. Eclipse (0-250$)
    3. Teraterm (0$)
    4. Adobe CS whichever (900-2500$)
    5. Microsoft Office 2003. (400$)

    This would allow any team member to move from one workstation/area of work to another without too much effort.

    As to the language, we recommend that one be chosen for "prototyping/scripting" and another for "enterprise" development.

    With Cygwin you get the CM tools, build tools, perl/bash/etc. (Already included tool set under Mac/Linux/Unix...) With Eclipse you get every thing too. (works on all OS) Teraterm nice term, just don't like putty myself. (not needed outside of windows) Adobe for those that like spending money. (Mac/Windows) Office, they are going to buy it anyway.

    1. Re:Choose them all under one. by snl2587 · · Score: 3, Interesting

      I just have to ask: when does Eclipse cost $250? I assume that would be some sort of support plan, but I can't find it advertised.

    2. Re:Choose them all under one. by Jurily · · Score: 3, Interesting

      You really work for lines in your CV?

      I should add "hitting my boss because he had complaints about my smoking habits and some nasty phrases about my mom" then.

      But seriously, if I do some work, I make sure I do it for the best of my abilities, and noone can say anything about that. Personal differences are another matter, and they usually arise when my would-be boss doesn't like what I do when I'm done with my work at that time.

      For some reason, my bosses seem to think that if I don't appear as working at a particular point in time, I'm not working at all.

      Back to your comment, I really do care about productivity, it's just that I don't define it as "appears as though he has something to do, always".

    3. Re:Choose them all under one. by BKX · · Score: 3, Interesting

      You should take a job-related book with you to your smoke breaks. Crack it open whether you read it or not. Or some kind of PDA.

    4. Re:Choose them all under one. by nschubach · · Score: 3, Interesting

      My first guess is that he may work for an accounting and or payroll function and he might not be suited for a training department or operations programming. (or vice versa)

      Were I work there are several different departments all with different programming needs. It helps to know some intimate details about accounting in order to give them the right tools to do their jobs. It would also be a pretty steep learning curve for that same developer to put their accounting knowledge on the bench while being tasked to write a program for the operation of the company. Without knowledge of the processes that go on in the operation, they will likely create software that's useful, but not very elegant or meaningful for the front line supervisor that needs to update numbers.

      Where I work, they have a dedicated development staff, and the projects they roll out are very well planned, organized, and managed. Unfortunately though, there are some things the operation needs and wants in short order that would help them perform better and they can't wait for a full 2 year project plan and all that. That's where the fun happens. It used to be tasked to some poor supervisor or someone that might be a hobbyist programmer in an area to create something in Access to get them their numbers or perform the task of training someone... yes, they would train people with Access because that's all they had to work with.

      Recently though, there has been an upstart of a group that handles "mid-level" operational reporting tools and rapid development tasks in order to take on these one man projects and try to standardize them across the company instead of having 80 odd programs in different states and countries doing the same things (frankly wasting time solving the same problems all areas face.)

      Is it the best solution? Probably not. But it's been working. The "start up sub group" has been able to quickly roll out applications (web apps in this case) to the field so they can perform their job easier and more efficient. If they run across something that requires more development, it's pushed up the chain to the dedicated development/systems teams to do a corporate assessment. There's something to be said for project planning and all that, but sometimes it's ungainly slow and cumbersome. In this small group, the developer is usually tasked with talking to the requester, laying out the design and functionality of the application with the user and coding it up on the framework in place. Granted, it's a lot of work on the developer, but they gain a knowledge of what the field needs and can better layout what that niche of the company needs to do it's job in a rather short period of time where the common standard project time line for the dedicated team of developers would take way too long to gather that knowledge, lay out a plan, and code the application.

      --
      Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
  2. Re:Depends by twatter · · Score: 5, Interesting

    It's lame to reply to myself, but I forgot something re: development tools.

    Don't dictate what your developers use, if it's possible. Case in point: In my current company we are building a VB.NET web application. There are six developers and five of us use Visual Studio, but the tech lead does not, he uses VIM. I was amazed by this, but after seeing him wrangle some text with that thing, I can see the value over an IDE, although I still prefer its warm confines because I've come to rely on the bells and whistles.

    BUT, this works only because he has a build system where he does not rely on the VS project files, only the source code, resources, images, etc. The end result is the same as if you had compiled the thing inside Visual Studio, except that you used only the compilers. This is very cool, and while I don't fully understand the build files, I can see how that's a definite advantage. The scripts even pull the source off CVS and everything.

    My point I guess is that you shouldn't tie yourself to development tools, if possible. That's just common sense, and at the same time you'll allow developers to use the tools they prefer. That makes for happy developers.

    Maybe one of these days I'll try VIM or EMACS, or maybe I'll just stick with the IDE. But at least I know I have the option.

  3. Re:Standardize the RIGHT tools by CodeBuster · · Score: 4, Interesting

    Subversion + Ant + CruiseControl = source control with fully automated builds and reporting and it's free (as in beer).

  4. Two by Tablizer · · Score: 4, Interesting

    A similar question came up roughly a year ago on slashdot. My recommendation is to chose two: one "scriptish" language (PHP, Python, etc.) and one strong-typed language (Java, Eiffel). C# is sort of a compromise between the two, but marries you to MS (so far), which may bite you in the future like VB6 did.
         

    --
    Table-ized A.I.
  5. GCC + Make + Emacs by martin-boundary · · Score: 5, Interesting
    The biggest risk with standardization is that you'll paint yourself into a corner with the wrong tools.

    Makefiles are text files, and completely tool agnostic. By standardizing on Make, you don't paint yourself into a corner with a single toolchain.

    Emacs has editing modes for many languages and file formats. By standardizing on that, you don't paint yourself into a corner, unlike a single language IDE. (Also, those who prefer vi can still use Emacs in viper mode, so Emacs is a more flexible choice than vi for the company).

    GCC is a compiler collection, with support for many languages. By standardizing on that, you don't paint yourself into a corner with a single language.

    Best of all, these tools don't take up a lot of RAM, so the development machines will be responsive without beefy hardware.

  6. Re:No way. by TheNucleon · · Score: 3, Interesting

    You hit on an important point - "developers are notoriously intolerant of following orders simply for orders sake". If all your developers loved CoolToolABC, but then you ordered them to all use CoolToolABC, they would rebel and feel stifled. There's a lot of creativity in software development, and to ignore the psychology of it is a big mistake that I've seen many corporations make.

    --
    My comments are my own, and do not represent the views of my employer, my spouse, my children, or my cats.
  7. it's not terrible if done in moderation by Trepidity · · Score: 4, Interesting

    I'm in academia, where just about the opposite prevails: you can use whatever you damn well please, and generally PhD students don't even get that much in the way of hard-and-fast rules from their advisors, so they use what they please too, as do half the research scientists and post-docs. The results of that are why companies consider standardization.

    The main problem is that, while experimenting with lots of languages and using languages perfectly suited to a particular task is nice, doing it too freely makes for a nightmare if you ever want to combine things, have a programmer of one system help out on another project, etc.---just the sorts of issues that prompted this question.

    My current research project's codebase, partly inherited, partly pasted together from components that were lying around the lab, and partly of my own doing, using nine languages, as a result of everyone using whatever seems like the right tool for each job. There's a C backend for one part and a C++ backend for another part; an AI component in Lisp; some GUI and glue-y stuff in Python; other GUI stuff and some other AI stuff in Java; some text-munging scripts in Perl; some number-crunching in Ocaml; some parsing and god knows what else in Haskell; and some other AI in an in-house language that compiles to Java.

    Now some of those tools were indeed exactly the right tool for the job. But this is not ideal to maintain, and it's nearly impossible to ship to anyone who isn't me in a way that a mere mortal could get the code built and running.

    Oh, and there's some other projects in the group that use C#, and one that uses Scheme, if I want to go for double-digits...

    --
    10 PRINT CHR$(205.5+RND(1)); : GOTO 10
  8. Re:A gross misunderstanding of the process by Rimbo · · Score: 5, Interesting

    Sounds like Stanford taught things the right way.

    Just last week, I was thinking about this. The University of Texas (where I went) had a similar philosophy when I was there as well; the goal was to teach the concepts and how to learn new languages. We groused about it incessantly at the time, but looking back over how my career has progressed and how I've been able to adapt to new technology, it was absolutely the right education.

    Consider this: At the time I started my Freshman year in college, the Fall of 1991...

    1. The Linux kernel had not yet been released by Linus Torvalds (v0.11, Dec. 1991)
    2. The World Wide Web had not yet been released to the public (1993) -- NCSA Mosaic was not to even begin development for over a year (Late 1992)
    3. Java had not yet been released to the public (1995)
    4. The latest release of Windows, 3.0, was still a 16-bit shell launched (not by default) from DOS.
    5. Microsoft Office was just a bundle including Word, Excel and Powerpoint at a discount (vs. their separate costs) and had only existed for one year; it was generally an also-ran compared with Lotus SmartSuite and Wordperfect (e.g., Lotus Ami Pro 3.0 was ranked as the #1 word processor for Windows by PC Computing magazine at that time)
    6. The C++ STL had yet to be developed (proposed 1993, released 1994).
    7. The first GSM network ever was just being launched; IS-95 (Qualcomm CDMA) was not to be introduced for another 4 years.
    8. The Eternal September had not yet occurred (1993)
    9. IBM was still the dominant PC maker.
    10. Design Patterns was 3 years from publication.

    The most basic elements of what we develop with today didn't even exist, and those that did exist were in nascent forms that they today barely resemble. Even ANSI C got a major update 8 years afterwards with the C99 standard -- which is nine years ago.

    But wait, there's more!!!

    When I was in grad school at UCSD, I took a class on Software Evolution. The instructor would give us a project, and every couple of weeks ask us to make changes to the project as our next assignment, to expand the project's capabilities. We were given the freedom to choose whatever means we wanted to pursue this goal. The initial assignment was to generate a simple web page.

    A friend of mine chose to use Perl. I asked him if he knew Perl, and he said, "No, but I can learn how in the time it takes to implement this in any other language, and with each new assignment I can just write a whole new script."

    He was the only one in the class to finish every assignment.

    The moral of the story is not that Perl is something wonderful, but rather that Perl was the appropriate tool for the job and that learning how to use the appropriate tool takes less time than using a tool you're familiar with that doesn't work so well. Consider chopping down an overgrown pine tree. If you know how to use a hand saw but not a chainsaw, the guy who uses a chainsaw is going to hack the tree down in less time regardless of whether he has to read the manual to learn how to use it. (And then after that, he'll know how to use a chainsaw on other trees, too.)

    So... yeah.