Development Environment Smells

There’s a lot of talk in the XP community about code smells, where code is hinting that something might have gone wrong.
I’d like to propose that there are also development environment smells that are as bad, if not worse than code smells. What ? Yup, even tho’ many of the code smells can lead to unmaintainable code (sometimes very quickly) and merciless refactoring is nearly always a good idea, a screwed up development environment causes current, immediate, certain decline in productivity.
When I talk about a development environment, I’m really focussed on the tools, hardware, network used to create the software. While Incompetent Management is a serious impact on projects, I’m trying to look at things that I can control.
So, in no particular order, here are my main development environment smells:

  • No command line build. This is pure evil. No excuses, ever.
  • Build environment tied to a particular IDE. I can’t believe that people do this. But they do, sigh.
  • No specific development test environment. You need to practice deployment
  • Development environment depends on externally managed resources. Database goes down, team stops work. Dumb.
  • A development environment that mandates a “reusable framework”. Reuse is dead. Build a bridge, get over it.

Maybe it’s just my psychotic enthusiasm but being forced to work with tools that hinder rather than help just seems broken, evil and wrong.
Tell me your stories of development environment smells.


10 thoughts on “Development Environment Smells

  1. “No command line build. This is pure evil.” – No, what’s pure evil is requiring a command line tool to do a build, even though it takes much longer to build from the command line than to build in the IDE. Plus, you actually have to hunt down classes and line numbers when you get compile errors, rather than just clicking on the error (in an IDE). Biiiiiig waste of time.
    “Build environment tied to a particular IDE.” Uh, yeah. You know what? I’m only building inside the IDE. So…not that important.
    “No specific development test environment. You need to practice deployment”. To be honest, I’m not sure what you mean. But I sure don’t see any need to practice deployment over. and over. and over. and over. and over again. That’s what a setup program is for.
    “Development environment depends on externally managed resources. Database goes down, team stops work. Dumb.” Well, I’m shocked to have to tell you that I 100% completely agree with you here. Even better is when you all share one database, so you, while doing development, have to get consensus to make changes to the DEVELOPMENT database. Every single thing you need to in order to do your development should be on your computer. Well, technically not the source control server…but, you know.
    “A development environment that mandates a “reusable framework”. Reuse is dead. Build a bridge, get over it.” No, I really have no idea what you’re talking about here. I think using JUnit is a pretty good idea, even though it’s reusable, but this probably is not what you meant. Really – I assume from your wording that you’re thinking of something specific, but I don’t have the slightest clue what you mean.
    I completely agree that working with tools that hinder rather than help just seems broken, evil and wrong. For example, I spent 3 hours the other day trying to figure out how to get my buggy video driver to appropriately rotate one screen, and set both screens to a decent resolution. Stupid Computers!
    But computers are here to automate logical, repetitive tasks, and I use an IDE just so these tasks can be automated. Need to open a class? ctrl-click on the classname. Need to go to the line number of a compile error? Just click on the error! Need to rename a method, and rename the method’s name in all code that calls it? Right click on the method name and hit rename!
    Why on earth would I want to give up these conveniences and use command line tools?

  2. To Paul:
    “No command line build” does not equal “Only a command line build” or “required to build via the command line”.
    I use an IDE all the time, but when I want to do a deployment to test, then it has to be done via the command line build. Also, the continuous integration tools need command line tools. If you’re working in a team, deploying to a production system, then you need a command line build to perform that work.
    As for the practise deployment, you’re right, that’s what the command line build is for, and that’s what building scrips to do it are for. Without the test environment, there’s no practice in deployment, and the first time you do it, is for real, and that’s dumb.
    “Reusable framework”. When a team of “architects” have designed the “corporate reusable framework for the ages” and you have to use it in your development. You’ve got no control over updates, and any bugs have to be patched via a circuitous route of change requests, resource allocation and releases.
    Your last sentences are correct Paul, I wasn’t advocating replacing an IDE with command line tools, but they need to be there.

  3. Ooh, we get full marks!
    “No command line build.” – Check. However, I did write a build script that should be runnable from the command-line but I haven’t tried it yet. At least it’s pure ANT.
    “Build environment tied to a particular IDE. I can’t believe that people do this. But they do, sigh.” – CHECK. WSAD (yes, broken, evil and wrong). It would be impossible to have our codebase actually compile in another IDE. Too many dependencies on the WSAD build. PS The seperate ANT script I created ended up including a new task that uses WSADs Workspace API to compile everything in the correct order because it would be impossible to do otherwise.
    “No specific development test environment.”. The “maintenance” team have this but it’s controlled by a teach lead and not really visible to developers.
    “Development environment depends on externally managed resources.” Check. Not to mention that all developers share the one instance. Oh and even better there is another team called the “static data team” who randomly change values, causing things to break. AND our system is hooked into a test release of another team’s system and if they break their bit we can’t use the front-end.
    “A development environment that mandates a “reusable framework”.” Check. This would be the web framework. But they are talking about moving to Struts eventually…
    What else? Let me see. Highly customised CruiseControl setup – hard to maintain. Duplicate JARs scattered everywhere, some conflicting versions; junit.jar and dbunit.jar and probably more like them are deloyed in the application EAR(!). JDK1.3.1. And well, not really an environment smell as such, but commons-logging used EVERYWHERE (see why this is a bad thing).

  4. jon, I appreciate your logical thought-out response.
    You’re right that an automated build would be nice. Actually, from your wording I’m guessing you’re working on a web app, whereas I’ve spent the last several months working on a GUI application. See I don’t need one nearly as much as you do, because I’m not deploying to a production environment on a regular basis. One would be nice – compiling the project when code is checked in, plus running Unit tests would certainly be nice. I also don’t need to practice deployment – that’s for the people who write and test the installer to figure out; but it’s TOTALLY different if you’re writing server kind of code for a production system that you’re updating regularly.
    “Reusable framework” – Oh, well, I couldn’t agree with you more there. We’re just starting to run into something kinda like this ourselves. See, we write out own “common” stuff, but then once it gets put into common, management doesn’t want us to change it for fear of breaking something else that might be using our common component. So if you need additional functionality, it’s often easier to rewrite your own class and do not put it in common.

  5. Paul,
    It really depends on how much trouble the installer people get into by waiting “until you’re done”. It may or may not be useful to practice “installing” earlier on.
    I think the Gump approach is what’s needed for these reusable framework things. Not changing reused components because of fear is sacrificing usability for reusability which seems pretty foolish.

  6. Reuse doesn’t have to be dead. Well, I would say that; I’m the guy in charge of making it work at Suncorp. 🙂
    What I would say is this: Reuse _must_ not be more painful than the value it adds. It _must_ not be forced down a project’s throat. It _must_ not be presented in one great big monolothic all-or-nothing heap.
    What I’m trying to do is present options to projects in small components that do targetted tasks, similar to open-source components. It _seems_ to be working okay, but so far there’s only 3 projects (and ’bout 4 small tools) that have used it; ask me in 12 months.
    The challenge with “reuse” is to find the right level of reuse. Stuff can be reused, otherwise there wouldn’t be components out there to get. The question is: how do you do it inside a company?
    That said: knowledge transfer and “reuse” will win over code-based reuse 9 times out of 10.

  7. Reuse is dead. Long live reuse.

    What he said. Jon Eaves does it again with a post on development environment smells.
    We already had a package system (think Debian, RedHat, etc.) when I started my current job, but one of the first things I did was build a script to handle actually …

Comments are closed.