Home‎ > ‎

Development Environment Tips

  • Just Say No to "Developmestuction"
    You need three environments: Devel, QA, and Production. Never mix them. Have separate hardware, separate databases, separate directory structures, separate everything. Development will be a bunch of sandboxes, as many as you have projects, and often living on developer workstations. QA will be running your Release Candidates for testers to bang on. Production will run nothing that hasn't gone through QA first

  • Be able to create new sandboxes with one click
    Write a script that installs all the dependencies, configures the database, sets the connection strings and so-on with just one or two clicks. You want to encourage your developers to spawn as many dev environments as they want, or else they'll recycle old environments when they get lazy, contaminating test results in the process

  • Never give anyone but developers read/write access to Devel resources
    One day you'll wipe out the Devel or QA database to begin a new round of testing with a clean slate, and the next minute someone is paging you frantically because you forgot to change a connection string after deploying a program, and they've been writing production data to your test environment for months. Deny read/write access to Devel resources for any account that isn't for a developer, and you'll catch any configuration mistakes early

  • Do everything in your power to shorten the development cycle
    The development cycle is: code -> compile -> run -> debug. If it takes an hour to compile, find a faster compiler or faster CPUs. If running it means spending twenty minutes setting up a test environment after each compile, then find a way to automate it and get that gap shortened to a few seconds. If attaching a debugger takes 10 clicks and a password, find a way to eliminate as much as you can. And for pete's sake, make it a priority. If you minimize the noise between when a developer thinks of a change and can see that change happening, then your projects will go orders of magnitude faster

  • Even one-man shops need source control management (SCM)
    Source control should be seen as an extension of the programming language and the basic tools for organizing code. If you like #Regions and subroutines and organizing code into files and folders, then you'll appreciate the ability to organize code in time and variety, too

  • The road to QA goes through the SCM
    Make it a rule that all code that gets to the QA environment must have been checked-out from the SCM. Never copy files, commit them from Dev and then run an update or checkout on QA. This should also apply to compiled code: only deploy binaries that have been built from a clean check-out of the source from the SCM. This will guarantee that you didn't fail to check-in something important

  • Use an SCM that's good at merging
    When it comes to managing changes an SCM either works by merging files, or merging changes. The ones that merge files (CVS, Subversion and others) are not as good as the ones that work by merging changes (GIT, Mercurial). Having the power to split codebases into different branches to explore new features and bugfixes, then merge them together into whatever fusions you need, is like having a command language for gene splicing

  • Don't think of branching as temporary
    Try to give up the idea of a "main" trunk of code. At any time in the program's life your "trunk" could be woven out of any combination of branches you have at the time. Don't think of branches as temporary excursions that must be merged back in after the experiment or bugfix is complete, but as definitions of where the program could go

  • Use virtual machines for clean slates and hostile hosts
    An easy way to create a testing or QA machine with a clean slate, whenever and as often as you like, is to prepare a virtual machine in Microsoft's Virtual PC or VMWare. Save the image in a repository and peel off a copy whenever you need it. Also, when you have a bug that only manifests on certain configurations of workstation or server, see if you can replicate that configuration in a virtual machine, then archive those images and make it part of your QA process to test against them all before each release

  • Case tracking is part of the spec
    There are three parts to the spec of any program: 1) the real requirements, 2) ponies, unicorns, and cup-holders, and 3) all of the stuff that everybody discovers during development. Case tracking systems (a.k.a. bug trackers) are used to fill in the third part, and if you don't have one then your spec will be incomplete

  • Automate documentation
    Many languages now support a way of building documentation based on properly formatted comments in the code. Sandcastle for .Net, POD for Perl, and so-on. Automate this so the documentation is built every time new code is checked in, and it will never be out of date

  • A Build Server is a sleep aid
    A Build Server is any machine that checks out newly committed code, tries to compile it, runs all your unit tests on it, and regenerates all the documentation from formatted comments in the code. The reason for having this is because programmers are too lazy to do those things themselves, but the real reason is to make it easy to go home on Friday and sleep easy the whole weekend, because you'll check-in all your last changes at 3pm and know you're good to go by 3:25

  • Visual Studio? Have a separate app.config for Debug and Release targets
    Open the .csproj or .vbproj files for editing in Notepad (they're XML), find the <PropertyGroup> tag where the condition is for the Debug configuration, and add a new child element that looks like this:
    Now copy app.config to a new file called debug.app.config, and make changes to your connection strings, addresses, directories, logging, etc, save and reload the project. This version will now be used whenever you build to the Debug configuration, while the original app.config will be used when you build to the Release configuration

Development Workplace Tips

  • Quiet is better than collaborative
    There is a hypothesis that making developers work in an open environment with no walls or cubicles will foster communication and creativity. This is true. However, it is an extremely expensive benefit, costing you more than half of your productivity. Developers will still communicate over Instant Messaging and email when they need control over their interruptions, and get together in meeting rooms when they want to brainstorm creative ideas and synchronize everyone's knowledge of the project

  • Buy doors, get a free programmer
    Every programmer that you put into an office with a door that closes is like getting another programmer for free, because productivity can double when they can shut out distractions. It takes up to 15 minutes for a developer to get back into the flow after a single, 30-second interruption, so a few distractions per day can destroy an enormous amount of value

  • Buy twice as many pixels, get a free programmer
    Another productivity doubler is to give them either two monitors, or really big monitors (27" and up). The reason it works so well for programmers is because one screen has a maximized IDE, and the other screen has a web browser with documentation in it. When debugging, the second screen is where the programmer will put the program so he can watch what's happening while stepping through wonky parts of the code. He will progress much faster than by alt-tabbing between windows, or tiling them so he can only see half of each

  • Cram as much RAM as you can
    It'll be used to open multiple instances of the IDE and VMs for the project plus the libraries and services it relies on. You should minimize how often your developer has to shut down a program to free up enough resources to load something else he needs

  • Printed books are cheap monitors
    You still need to give programmers at least two monitors, but you can get a little bit more mileage by purchasing printed books. Give O'Reilly a decent fiscal quarter, because they're like really cheap third, fourth, fifth, and sixth monitors. Give programmers something to read on the toilet

  • You can never have too many whiteboards
    Consider "whiteboard paint" or melamine sheets ($12 for an 8'x4' sheet at home improvement stores, glue them down with "Liquid Nails") to cover every square inch of programmer offices and brainstorming rooms. The reason you want to have a huge amount of whiteboard space is to discourage erasing, so ideas and objectives will keep tickling the developers brains every time they walk into the room or gaze off into space. Buy lots of different colors of markers, and never have more than one eraser per room

  • Keep the office in good repair
    Fix broken windows, broken tiles, leaky pipes, busted A/C, drippy faucets, blown fuses and potholes in the parking lot. If the developers see and feel that their work environment is always kept in good repair, they will feel the pressure to keep their software bug-free and in good condition, too

  • Decorate tastefully
    Keep some potted plants (watered and trimmed regularly), ditch the 70s wood paneling and carpet, buy some modern furniture and paint the walls. And as importantly as the quality would be the consistency: if you go for a modern look, then don't mix it in with classic-style furniture. Just like with keeping the office in good repair, these environmental cues will be reflected in the developers' work. Quality, consistency, and taste

  • Give flexibility, get flexibility
    Your developers want to work flexible hours, even work from home sometimes, but it looks bad to the other departments who must show up at 8 and leave at 5:30. Who do these programmers think they are, showing up whenever they feel? Sleeping in when there's work to be done? A developer's productivity is a function of his brain activity, so he's working for you at 7:30am when he's in the shower, experiencing creative pause and realizing there's a faster, shorter, cheaper way to deliver the feature you want. Creativity does not start up at 9 and shut down at 5. Consequently, they want flexibility. If they're bushed in the morning after an all-nighter, let them come in at 11. In return, you'll create the conditions that let you execute new directions and exploit short-lived opportunities. Why? Because they will deliver better value at lower cost with code that can adapt to many different situations. The other departments will care less when the programmers give them tools that let them be flexible, too

Developer Retainment Tips

  • Just because it's worse elsewhere doesn't mean you won't lose your top talent
    Other companies may indeed force 45-50 hour work weeks plus weekends, cram them in elbow-to-elbow and give them health plans with a $3,500/year deductible, but it doesn't mean you can sit pretty with your lead developer grinning and taking it. There's four things a developer, like any other human being, wants from a job: competitive salary, comfortable environment, challenging work, and a future. If you keep filling vacancies at the top from outside the company, then the bright kids at the bottom will seek work elsewhere even if it pays the same but gives them a sense of having a career path. If you make them work in a closet with 4 other programmers and inadequate ventilation, they'll bolt for the first place that gives them an office with a window. If you hire a whiz-kid and make him edit Microsoft Access forms in Visual Basic, you won't see him after a few months. If they find another job that pays more but has longer hours and commute, they will take it because it'll make them feel like they're getting paid what they're worth.
    Of course, you could just hire H1B workers exclusively. That'll last until they get citizenship, or the other country's economy rises above ours

  • Hire a maid and a janitor
    Have someone clean the offices, empty the trash cans, replace the paper towels in the bathroom and vacuum the carpet. Have someone replace burned-out lights, empty water-cooler bottles and unclog the toilets. Nobody wants to work in a cesspool and they won't see it as their job to do basic janitorial work

  • Stock options are nice, but only if they're worth something
    If your stock is traded in pink sheets, your employees won't see much value in their options. "Options" are not a magic word that can be used to retain staff and stop people from quitting, nor do they have much power in the beginning when they're still years away from maturity. However...

  • Tell them about your vision
    Even companies traded OTC can give employees the sense of having an investment if you share your plans and vision with them. They don't like doing the 9-to-5 working for a machine, but they'll put in more effort and longer hours if they know where the company is aimed for and feel like they're a key part of the plan. So tell them the plan. You don't have to whip-out ledgers and forecasts and numbers, just say "we want to be the leader in Market X, and here's how we plan to do it"

  • Listen to their ideas and give them credit when you implement them
    Your web developer is trying to tell you how to improve your search engine rankings by getting rid of IMG based text, but you ignore him. Then a year later you hire a fancy high-priced SEO firm who tell you exactly the same thing, and now you command your devs to use CSS and ditch the GIFs and PNGs. A month later you're wondering why he's handing in his two-weeks notice. Do not treat ideas as if they're only worth the salary or title of the guy who came up with them. It's okay to be dubious of ideas if they don't sound right to you, but if you hear them confirmed then just say something like, "I didn't fully appreciate your idea the first time I heard it, but now I do. Thank you."

  • Stupid, little things matter. Like candy
    M&Ms are cheap. So are cereal cups, buckets of pretzel sticks, coffee, tea, and fancy-ass sweeteners like Agave Nectar. Stock these in the break room and don't put them behind a vending machine's paywall, unless the prices on that machine are so low they barely cover cost. Get one of those K-Cup coffee machines and stock at least 10 flavors. Get a La Marzocco Linca espresso machine if you've got enough Metrosexuals on the payroll who really want it. Sure, what the hell. And you know what? It's cheaper than paying for another 30 days access to Dice.com and re-training the next shmuck

Employment Retainment Tips

  • Bosses work at a different abstraction layer
    No matter how many intermediate bosses you have, the one who signs the paychecks doesn't care if your LAMP hosted SOA architecture with ACID transactions can handle 200k requests per second. Why are there even 200k requests per second when we only max out at 10k visits per minute? Your boss is a programmer of a different kind, but he or she works from a different abstraction layer with a different kind of API. You are supposed to expose a human API that converts requirements into results. It's okay if you need dependency injections--that's what a Project Manager is for--but returning low-level data structures and error codes to high-level processes will result in a system crash, and the system operator might respond by replacing the faulty component

  • Don't be passive aggressive
    If your boss asks for something that can't be done, then do three things: 1) explain why you don't think it'll work, then 2) give an honest attempt to solve the problem anyway, and 3) show them what your problems are. Even dim managers are capable of understanding that their desires can't be filled the way they want, and even though you may find it hard to express the problem in business terms (cost vs. return), they can do the calculation themselves if you help them understand. They're not afraid of failure, but they are frustrated by employees who don't give them the expertise, time and patience that they're paying you for. What an employer wants is an employee that can solve problems, especially the ones that don't seem to be solvable

  • Current earnings are not a guarantee of future growth
    The company had a good year, but the bonus was lousy. Clearly they don't respect you, right? But meanwhile, in other parts of the universe, the stock market lost 40%, Iceland went bankrupt, unemployment rates went to double digits and the bailout is going to cost more money than has ever been minted. You're not stupid; you cut back on spending, paid off your credit card and started putting more dosh in the bank. Nor is your employer stupid. They know that even a good year now isn't a guarantee of good years in the future, and the best way to protect themselves against the unknown is to cut spending and stay lean. Unless you work for Goldman Sachs, that means a small bonus or no bonus. But don't burn your bridges because you think it isn't fair. Companies are living things that want to grow, and even if you have access to the sales database and can see what's being earned, you still don't have the full picture. If the company was genuinely miserly, they'd be stingy even when there wasn't another Great Depression on the horizon

  • Do not hide work
    Six months have passed since they assigned the project, and now the boss demands access to your dev environment to see what you've done. She finds: 2 tables, 1 page of code and a class called "paulaBean". You are so totally fired. This could have been avoided, however, if you didn't just let them see into the dev environment from the beginning, but you insisted on it with requests for feedback on work in progress. Now this won't help you if you're a genuine deadbeat who wants to milk it for as long as possible under the sword of Damocles, but the general practice will help make sure you never get into a situation where the employers expectations greatly exceed what you've been able to deliver. You want the boss to expect that there'd only be 2 tables and 1 page of code, and not fault you for it

  • Deal with frustrations constructively
    You can't hide resentment forever, and eventually your boss will notice you're unhappy. Some bosses will talk to you to find out why, but others will just show you the door. Rather than seethe and grumble, take your concerns up the chain-of-command, showing why you have a problem and how you think it could be addressed. Never vent in the workplace and check your attitude at the door