Comment by danielecook
7 years ago
Efficiency is also more important than it seems. You can have lots of low quality, half-baked output. How much forethought do we put into what we will work on to begin with? Some projects and ideas are not worth the effort. Or an alternative solution to a problem is preferable over one you’ve been hammering away at for days, and would be easier to implement.
And in the realm of programming, it’s often easy to take shortcuts even though later on they wind up costing more time for you or others involved: omitting documentation, not making something reproducible, poor code quality, etc.
Having spent most of my career in academia I see a lot of the work makes this trade off: efficiency is sacrificed for a sloppy, immediate “speedy” solution. You need to find a balance and think through problems, considering not only what is immediately in front of you but also what you’ll be doing in a month or year. Otherwise you’ll wind up with a project or codebase that begins to drag your productivity and output with it.
Not every product is maintained for years. In many cases it's good to be able to choose between a quick solution and a good solution, as long as these are concious decisions and some record of accrued technical debt is kept.
Rarely if ever in the beginning of the project it's 100% sure or guaranteed how long the project will be maintained. There might be some estimates, but in the long run upper management might change their minds at any time and then you are fucked if you didn't build robust architecture from the start.
At least according to my experience and everyone I know in the industry.
But there are so many counterexamples to that too. I worked on a project following CI practices with a release every two weeks, and I can think of plenty of examples where we developed a feature, tested it with users, and scrapped it within a month. That team leaned toward strict practices, and we wasted so much time on code review and documentation of small details which only existed for a couple of weeks.
I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.
5 replies →
If you work on legacy code you can be sure that your code will be used for years if not decades.
1 reply →
Often, the difference between a quick solution and a good solution isn't technical debt! (So long as there isn't an impediment to adding them in the future.) Missing features aren't technical debt.
Technical debt manifests in a code base, most generally as various forms of pain that occur when trying to add features. That's how the company "pays interest" on the technical debt. Coding so that you can always change your mind, however that is accomplished, is the key there. (This is one place where the "Law of Demeter" really shines!)
I think it's somewhat paradoxical: The software that gets delivered, produces value gets to live. The market prefers just-good-enough software
There is also a possibility that your predictions about the future turn out to be wrong.
It's definitely a balancing act.
One extreme is always going for the instant gratification, paying no attention to how things fit into the overall design.
The other extreme is trying to design everything up front with no feedback and getting more and more divorced from the practical reality as time without implementation goes on.
Even worse, the correct balance depends on the project. Sometimes everything around you is well understood and set in stone; in that case it's beneficial to plan meticulously ahead. In other cases everything is in flux and nobody knows what the requirements even are; then you just have to incrementally build towards a solution with frequent refactoring. But knowing where on that spectrum you are is crucial.
When I feel progress goes slow, or a task is too hard, I will use test driven development: Just implement the bare minimum in order to make the test pass, basically dividing the task up into many small steps.