[/caption]This is a very simple rule that I have for solving problems at work, solve them forever. Its not always practical and sometimes you need to bend the rule, but its a great guideline. When I'm presented with a problem at work, I take it as a personal insult, someone could have solved this before and made my life easier but they chose not to and burdened me with it, and I refuse to do that to anyone else.
This has some downsides, you have to put in a lot of effort, and sometimes little things take a lot longer than the "man" thinks they should. There are some upsides though, you avoid technical debt. A lot of coverage has been given recently to the idea of technical debt, how you define it, how you avoid it, should you avoid it and so on. It is one of those nebulous concepts that everyone has a different definition for, we all know what it feels like to run up against some technical debt, its that situation where something that should be simple is needlessly difficult.
Technical debt is not complexity, sometimes doing seemingly simple things within a complex system can be cumbersome, but that's the price you pay for some other benefit (dynamic forms, automatic mapping, etc.) You know that you've hit some technical debt when something is complicated and difficult, but there is no upside.
Boss: Change the text on that button
Dev: Ok, I'll just update the html
...several hours later...
Boss: Why'd that take so long?
Dev: You see that text is pulled from an i18l file, which is populated dynamically by a database table, that table is autorouted by the orm layer, so I had to change a bunch of configuration entries, then I had to run an update across several tables, some tables were using the name as a foreign key relationship, even though they didn't declare that formally to the rdbms, so I had to go track down what tables were doing that, and once all that was through I had accidently made a typo and had to go through the whole damn process again.
Debt like this is incurred when you solve a problem for now, not thinking about the future. Solving a problem forever means that as long as the problem domain remains the same that you don't have to do anything. The issue is that many people misinterpret solving a problem forever as solving all problems forever, and that is not what I wish to promote.
There is an important difference, you should solve the problem domain thoroughly, but your solution should be specific to that domain, don't try to do too much. There are innumerable problems that someone will take the time to solve for themselves, but give no thought to what happens to the next guy. Coming onto a new project I've come face to face with an age old developer problem, rolling on.
Rolling onto a new project is often an exercise in navigating technology to set up a development environment, navigating the corporation to integrate yourself into it, and navigating the team to find a place. All this navigation seems to be on the shoulders of the new person, there are people you need to talk to to get mainframe access. Which people? Where are they? When do I talk to them? How? There are often answers locked up inside someone's brain, and if you ask the right people you can, like a detective slowly unraveling a mystery, find the answers and get your email and passwords and id badges.
This is a problem that should be solved forever, once the first guy joined the team he should have documented what he did, when, how, why, and that document should be part of team cannon, available as a helpful guide to the next new guy. This rarely happens though, it is a shame, but understandable, new people are struggling to get up to speed on a project they don't have time for the meta-project of documenting their up-to-speed-getting project.
That is just an example, the next time you are guts deep in a problem that you've encountered before think about your fellow developer, and think about how you can solve it forever. The more problems you permanently put to bed, the smoother development can go and the faster you can get your project done.
I whole-heartedly agree with this well written post. As a consultant who recently joined a project, I also know the woes of having absolutely no documentation. This project has been running for several years and I JUST wrote the first piece of documentation last week.
ReplyDelete[...] solve it forever | ihumanable – Solving a problem for today is really aggravating. I'd much rather solve the problem once, even if it takes me twice as long to do it. I'm lazy, I don't want to fix it again in a month… or three. [...]
ReplyDelete