Bloody developer tools. Bugtrackers, Wiki’s, blogs, build farms, testing frameworks, monitors, compilers, frameworks, environments, debuggers … Some times I feel like they’re controlling me rather than the other way around. I started my computer-career because I was good at writing code. First this bit, then that bit. Link together as such. Here’s your path. Now do.
And now look at me. I’ve gone from “getting the job done” to “getting done by the job”, where processes, instructions, frameworks and complex machinery (and I include the coffee-machine in this, one of the more important parts of the system these days) have throttled and taken over my old days of neat small programs or scripts semantically bound together by my cleverness.
Working on big and small projects always demand some kind of rigor, and these tools help us have some degree of control. So we’re being told. We try them out, we use them, integrate them, extend them, all to somehow get some control over our overgrowing systems. We believe that this is the right way, the true way to being enterprisey. Maybe this even is correct, that the true definition of “enterprise” is huge and unwieldy. But that’s not the result we were after. “Enterprise” is not a result, but a symptom.
Another crazy thing is that no matter how we simplify and makes things easier through project management, we still need to duplicate our cleverness into system so that they can be documented and dumbed down. A typical example is how we write little post-it notes with work-tasks, and move them along a board so everyone can see who’s doing what. And then we duplicate our notes in the bug-tracker. And then we duplicate the hours spent in our Excel sheets, and our other internal timekeeping system. It’s like taking a step forward, and then two back, but because the first step is more visual we think we’re doing progress.
Why doesn’t these tools work the way my brain works? Why don’t these tools integrate better? I must search the bug-tracking database to find the module in which the bug I just struggled with could be found, only to find 10 slightly different but similar-sounding bugs, and choose one, and perhaps later create links between them to create a sentiment of what the bugs all are? How many clicks and web pages did I just go through to report my one bug?! And if bugs are this hard to define, you’ve got bigger problems than that bug, I can tell you! I don’t know about you, but I see more places of error and maintenance nightmares from that scenario than solutions.
Where I before used common sense I now use the Factory Pattern. Where I used to document the interesting bits in my code with clever puns and humor, I now use JavaDoc at every intersection, method and class with prose that my English teacher would be ashamed of and I myself fall asleep over. How did I get to here?
Another example of “tools” gone bad is “meetings because there must be a meeting” (daily or weekly meetings, for example) bringing the distribution of people to a central point for communication and possibly solutions. If these people we’re distributed in the first place … *sigh* And because these are circular event, people adapt to their circular nature, and soon find they can fake any meeting. It becomes a meeting to simply get over with. What was the point again?
Then there’s cross-departmental systems design and implementation, where the service bus is an integrated part of domain integration. Bah, I can’t believe I just said that, because what I really mean is “stuff your WSDL here, your classes there, UML over there and config files here, and try to verify that your serialized objects come out right and do the right thing, and then serialize them onto somewhere else, rinse, repeat.” I feel I’m becoming detached from enterprise speak as I’m believing less and less in the problem space.
I guess at this point you’ve guessed I’m no fan of enterprise architecture and the way that SOA is promised these days. Often we’re made to believe that we need synchronized, mediated, transaction-baked and bus-delivered systems full of dependency injected objects over a FOP, sprinkled with mock objects, where it passes integration and unit tests, and are linked to the cruise control, all in the name of a friggin’ form in a webapp somewhere. The problem is over-engineering.
The tools we use suffer the same inane over-engineered and under-humanized thinking. I mean, have you given BugZilla or JIRA to your normal users, without telling them exactly what to do (basically writing a separate document with lots of specific instructions) and how your setup of that system is meant to work? Where do things go in, and where do they come out? What am I working on? No, I’m not working on that! And what about source-control? How many different systems are there? How do we fork, and more importantly, how do we merge them? What do you mean my file isn’t in synch with the repository? I AM the repository!
Bloody tools written for and by geeks to give the illusion of progress, that’s what they mostly are. I’m so sick of these tools not helping me be effective. Is that so much to ask? We’re so focused on our bloody tools that we’re forgetting how to do the one thing we thought we were good at to begin with; writing good code. And good things come in small packages. Small packages usually denotes small domains. Doesn’t everyone know this?
Friday developer tools blues, I call this. Now go and have a great weekend.