The first thing you have to realize is that everyone else in the business is scared to death of software development. If you allow your development to be driven entirely by fear, then you’ve got a one-way ticket to maintenance hell. But how do you get control of the development process if your authority and influence is limited? The direct approach will not work. Your arguments for investing in skills, design, and refactoring will fall on deaf ears. Your only hope is to combine an array of guerilla tactics with an understanding of the terms with which those in control view reality.
There’s only three units of time that register in the consciousness of project managers: 5 minutes, two days, and two weeks. For most programmers, there’s been many times that these little “5 minute” changes have exploded into hours of pain, so most developers never let on that it’s possible to get anything done that fast. So really, the smallest unit of development time that a project manager is going to hear is going to be in the two day range– no one’s going to let on that anything faster is possible, and (in the tradition of Mr. Scott) everyone will pad their estimates by at least a factor of four.
“Two weeks” is a code phrase signifying that the people involved in the problem really have no idea how difficult the problem is or how long it should take. If there’s ever something really hard that has to be done, a manager will assume that two weeks is plenty of time to accomplish it. Anything that *you* want to do that will take two weeks or more to accomplish is going to be immediately rejected. The trick is to never ask to take on anything that’s that ambitious in scope, but rather to focus your efforts over time to gradually increase what’s possible in the “5 minute” range. Once you have a framework in place, the general demands of the users will allow you enough leverage to take on more sophisticated tasks that can take up to two days or so to implement. That’s the general idea, anyway. Below are some specific techniques and maxims you can use to work your way up and take control of the development process:
* While no manager will listen to your crazy ideas, they generally don’t care how you accomplish your tasks. This is the leeway you’ll have to leverage to turn things around in your IT department– at the start it’s your only avenue for improvement.
* If something actually does turn out to take the “five minutes” that you thought it would, use the extra time that you’ve scored to improve the elegance of the code or to learn a better way to accomplish the same task. (How this impacts the project is irrelevant: you’re doing this to invest in *yourself*.)
* When other developers are wasting time playing solitaire, trading stocks, or surfing the web, invest your time in developing tools that help you manage your tasks, problems, code, and data.
* How do you know what tools you should build? Look at where the friction is. Anything that’s tedious, irritating, and boring is something you should look at automating or tooling up for.
* A quick-and-dirty tool can help you get a job done in about the same time as the other fellow that does it the hard way. Tasks that you have to get done weeks or months down the road will give you an excuse to improve your tool(s).
* The thing that’s going to give you an edge is the fact that you’ll have a whole library of tricks, a framework that integrates them, and a “sense” for what fancy-smancy techniques are worth learning and applying on the fly.
* At some point, someone’s going to come in with a task that you’ve pretty much already solved. This is your chance! Basically, you can throw together a simple GUI, code a couple of routines, and suddenly you have pretty sophisticated solution that’s much more robust than what the other guys would have thrashed out as a hand crafted one-off. The trick is that your GUI is just a thin veneer on top of the tools you’ve been using for yourself all along!
* Your solution is not something you could have proposed at the very beginning. You just didn’t know enough back then. So don’t fault your manager for not listening to you back at the start!
* People’s ears will perk up when you say, “I’ve actually got something pretty close to that built already.” The fact that you’ve been the primary user for your stuff for a long while will mean you’ve got a lot of confidence in it. And nobody’s going to take a chance on “vaporware” or “castles in the sky.” “This is practically done,” you say, “I’ve just got to make a couple of quick modifications and we’re there.”
* The fact that you can solve an entire class of problems in 5 minutes that would take your peers two days is what will get people’s attention. Nobody cares what you can do in two weeks time. They don’t even care what you can do in two days time. Five minutes is all anybody’s going to care about at this point.
* Once your solution is deployed, there’s a whole world of forces that your pride and joy will be subjected to. The users are going to be a great resource for new ideas, though. Go watch them work and keep talking to them until they can give you some real constructive feedback. After one minute they’ll assure you that everything’s fine. After five they’ll mention a couple of things that could be better. After ten or so, they’ll be telling you what you really want to know: “Now I don’t know anything about computers, but what I really need is….”
* The worst thing about in-house development is that applications only have to be “good enough.” Once they get that far along, the creativity stops and everything freezes into maintenance mode. You can identify a complete lack of design in an IT department when you see a proliferation of forms, screens, procedures, and programs. You’ve got a lowest common denominator philosophy because nobody’s taking the time to find the common denominator to all of these forms, screens, procedures, and programs.
* If you’re *designing* software, you’re not just adding new screens or modifying existing ones. Real design is going to incorporate subtraction and abstraction as well. A good abstraction is a technique that allows you to synthesize many ideas at once– and once it’s implemented, you’ll be able to subtract away a lot of unnecessary code.
* As your users begin to get the hang of your application, be “jonnie-on-the-spot” when it comes to all of their “5 minute” type requests. If they feel like you’re listening to them and taking care of them, they’ll be more willing to give you a chance to invest in the stuff that will provide the real payoffs.
* Anything that the users ask that’s more in the “two hour” range” should be put on hold until you have at least a dozen such requests. List them all on a whiteboard and kick ideas around with the one person at the company that’s willing to listen to you. Then wait some more and let these ideas percolate a while.
* Code up proof-of-concepts for some of the hard stuff and expose it inside your application with little regard for design. Walk some of your power users through special “previews” of these features so that you can have a chance to soak up as many good ideas as you can from them.
* Now go back and look at the white board. Erase it and reorganize everything into related “buckets” of functionality. In the bottom half of the board, sketch out the GUI for something that could address the bulk of the requirements. Underline the stuff you can address right away with only a minor reorganization of existing code along with new GUI elements. Separate out stuff that appears to be hardest.
* There are undoubtedly areas of the code that have known quantities of suckage in them. There’s areas that really irritate you every time you have to go in to modify them. Avoid wasting time fixing this sort of thing until they’ve had time to fester for a while. As you’re about to go in and fix everything up for your users, be sure to invest some time in cleaning these things up for yourself while you’re making such big changes. If there’s a huge visible leap in the functionality, your users will at least have something they can blame it on. “By the way, when you added this hot feature that I use every day now, this minor thing over here stopped working the way I want it to.” You’ll never have time to work on something just to make it objectively cleaner for “no reason”, though.
* If this takes longer than what folks want, don’t sweat it. Remember, in-house software only has to be “good enough.” You’ve already addressed all of the critical stuff that people absolutely have to have to do their jobs. This reorganization of the code combined with a dozen sorta-optional type features just isn’t as urgent. It’s more important for you to control the growth of the application in a sustainable way. Listen to them as if they’re the first person to suggest whatever feature it is that they’re asking for, but remind them that as long as the code is “good enough” for them to do they’re jobs, they’re just going to have to wait. If you have to respond to these demands immediately, make sure that whatever they’re asking for fits in to your overall scheme for how the application should be structured. Better yet, use some of the time you spend focusing on their needs to flesh out, extend, or improve areas of the code that you can use to nail down your vision further down the road.
* You’ve gotten this far by investing in tools first and foremost for *yourself*. You’ve consolidated your power by training the users to think in terms of tools they can use to solve their problems– as opposed to a screen with buttons on it that they just go in and push.
* You may not always have managerial support for each new order of magnitude increase of functionality in your application. If you’re in doubt of this, build it anyway. Do it on your on time if you have to. Roll the application out on a “Beta” basis to a few of your more savvy users. When your managers find out about the application, they’ll more than likely make you stop everything and load it up on their machines and pester you like crazy for new features.
* Each order of magnitude of increase in application functionality will take more time to develop than the one before– but each one will put more and more features within the “five minute” range of your grasp.
* The final coup de grâce is when you’ve developed your application so much that you’ve gone through several refactorings and paradigm shifts. Your design is so clean and your code so expressive… you’ve rolled with anything the users could throw at you and made something truly beautiful. Then someone comes by and mentions that folks in another department have very similar needs as the ones you’ve been coding for. You listen to their requirements for a while, stroke your chin thoughtfully and say, “I’ve actually got something pretty close to that built already. If I make just a few modifications to the framework I’m using for this other application, I think we’d really only be a day or two away from having something that could work for them.” And so, you get the green light for another project and you are able to justify ever more ambitious features and refactorings because each hour of effort you invest in either can be harnessed to benefit both projects.
* Once you’re this far along, the question will come up as to what the company will do when you “get hit by a bus.” If you get cornered on this, just start talking about how they really have a good point on that. Explain how you’ve had to sacrifice code quality in order address all of those urgent feature requests– and they’re some areas of the code that even you’ve forgotten how they work. Really, the company would benefit greatly if you spent a month or so polishing and cleaning up that stuff. Even better, you should take some time to write articles about the trickier stuff you’ve done in the application. Once published, the articles will generate valuable feedback from more sophisticated developers that simply cannot keep quiet when they see a technical flaw or innefficiency. Those articles can then be folded back into the project documentation for whoever inherits the code. (Cue maniacal laughter….)
* Of course, you and I both know that no matter how great your application is, all it takes is one random IT manager to come in two years down the road and insist that 6 mediocre developers get hired to rewrite everything in the latest Blub IDE or whatever. More than likely, your application will remain “good enough” for quite some time and the average developers that come after you will make only surface changes to it. What will probably happen is that the creative integration of various requirements will cease and the new developers will gradually get bogged down as they create one lame hand crafted form/screen/procedure after another and begin to spend all of their time on maintenance instead of design. But that’s okay. They only needed to make something that was “good enough” for the moment. By the time the company fails because of their negligence, no one will suspect how much they were responsible for so many folks losing their jobs….