HN Explorer

Ask HN: Do you spend more time coding or debugging?

84 points by WillKirkby ↗ HN
I find myself spending most of my time debugging older code, and I'm curious as to how other people's time is split at work, between developing new code, extending existing code, and maintaining existing code. Anyone care to share?

76 comments

[ 2.1 ms ] story [ 163 ms ] thread
id122015
Not employed. As a hobby programmer I spend more time debugging. The larger the project the more debugging.
return0
I wonder if there is a study about the percentage of time spent debugging as you become more experienced.
vbtemp
I used to spend the vast amount of my time debugging.

Fast forward a few years - Experience, good programming habits, and the gratuitous use of assertions. Now I spend a negligible amount of time debugging, and it never ceases to amaze me how frequently things just work the first time.

Edit: I guess I want to say that there is one, and only one, bottom line: the relentless, ruthless pursuit of quality. It takes time to develop the good habits and watch for the pitfalls, but once you're there you develop your software products in a quarter as much time, with one tenth the stress, and everyone on your team feels proud of themselves and each other. Then with your free time you can focus on what's really important - your business and your life

agopaul
This. And I'd add that the type and complexity of the workload your application sustains is almost proportional to the amount of time spent debugging it
closed
Agreed, but with the addition of some periodic, many hour, something-completely-unanticipated-happened-and-I-am-so-perplexed debugging sessions.
davismwfl
This but let's also define debugging. From reading some of the comments left throughout the thread it seems like people don't think that a test failing and you having to go back and fix code (or even the test) is debugging but IMO it is. There is a bug, you are going back, finding it and fixing it. It usually means it is easier and faster to find/fix, but it is still time spent "debugging".

I spend more time creating then debugging when I write the code from scratch, but I still say I spend probably at most 70% coding if it is a new project. The rest is in failing tests and finding those weird screwed up errors that take multiple days of a debugging session to find. For existing code I take over, it is probably usually more like a max of 50-60% coding depending on the original authors skill.

VOYD
"Quality? But how does that affect our bottom line?" :)
dandelany
I know you're joking... But it really does affect the bottom line! I've learned the hard way that taking twice as long to do something the right way will be more economical in the long run than doing it quickly, and cleaning up the bugs that manifest themselves over the following months.
vbtemp
Yes, but this is also a false dichotomy. In my experience doing something the "right" way is generally no overhead over doing it the "quick" way. Adding a check, or a log message, or making sure you're using consistent styling, or an assertion before/after some kind of operation... these things don't add time or complication to something
dandelany
I strongly disagree. Thinking through and handling all of the edge cases that could break my code inevitably takes more time than getting it to work for the few examples I know of and calling it a day. For example, I just wrote a function to generate a rolling average from a timeseries dataset with one data point per day. All of my sample data has exactly one datum per day. But I just know that eventually there will be an issue that causes data gaps, and of course writing code to handle gaps when they occur takes more time than not doing so and ignoring the consequences. And that's not even mentioning the time required to write unit tests.

Furthermore, a lot of the extra time comes not from the initial coding exercise, but the diligence and follow-up required. ie. Cool, I've implemented a feature, but did I go through carefully and ensure that I've removed all my console.logs and commented out experiments? Did I leave dead code anywhere? Did I make any changes that require renaming or refactoring of other parts of the codebase? I never submit a PR these days without carefully going through my own git diff and double-checking myself. I almost always catch something when I do. These things take time.

franklinho
I remember the first time I wrote an entire controller and everything worked exactly like it did in my head. There was a lot of whooping and dancing to be had.

Not that it happens much.

hodwik
I think a lot of debugging activities end up laying the framework for new features, so it's unclear how to separate the two.
rurban
debugging. esp. not my code.
busterarm
Between developing, extending and maintaining code, I'd say about 20%, 60%, 20%.

That said, I'd say only about one-third of my time is spent on code. I spend significantly more of my time doing operations work and having meetings.

LarryMade2
Lot of planning then Coding and Debugging - theres a lot of refinement going on during the debugging process. So I cant call it just debugging.
Krakulf
Roughly equal, probably debugging takes more time (or at least it feels that way!).

Usually can get through a chunk of code no problems but when that 1 inevitable bug arises it will take up a lot of time through trial and error, stack overflow and just generally googling to find a solution.

[deleted]
(comment deleted)
serg_chernata
Sometimes I feel like I'm not writing code at all, just debugging till it works. :)
Joeri
Implementing a feature is fixing a missing functionality bug, fixing a bug is completing a feature. There is no real difference between feature dev and debugging, except in how they are perceived.
kyriakos
debugging the platform so i can get 10 lines of my code to run
pbnjay
I think it will really depend on the role.

- One project is in active development, and I probably spend about 70-80% of keyboard time coding with 20% debugging.

- A separate project is in maintenance mode, and obviously most of my time on it is debugging as bugs come in. So probably opposite, 70-80% debugging there.

- Sometimes feature extension requests come in, in which case it's probably closer to 50/50 on that project.

phamilton
Debugging tests. It's the worst because the feTure took an hour to add with ita own tests, but a day and a half of debugging how the changes broke other tests.
democracy
40% - coding 50% - unit testing 10% - debugging
tombh
I'm not sure there's much than can be concluded by someone's ratio. I definitely wouldn't assume that someone who spent more time debugging was a "worse" programmer.

There are certainly practices that reduce the amount of debugging, but it's all relative. Personally, the question for me is nearer something like;

> When is the right time to let go of my current approach?

eric_h
> I definitely wouldn't assume that someone who spent more time debugging was a "worse" programmer

I believe that more time spent debugging, the worse the code you're debugging is. Now if you're spending most of your time debugging your own code, then likely you're a novice who hasn't learned the many ways to write quality code that "just works".

If, on the other hand, you inherited a codebase from someone who did not follow the tenet of "develop your code as if the next maintainer is an axe murderer who knows where you live", then spending a great deal of time debugging is understandable and likely unavoidable.

Personally, during the time that I get paid for programming, most of my time is spent writing tests and developing features.

On the side, however, I have a project that I inherited from someone who clearly never intended to have another person look at the code, and most of my time is spent spelunking and debugging (and slowly replacing every last line).

WillKirkby
I find myself doing the exact opposite. The time I get paid for is mostly spent fixing bugs in a codebase of variable quality that I've inherited. The hobby projects I get up to are entirely my own code and thus I get to spend the majority of that time implementing new features.
eric_h
Well - my "hobby" project is running the league website for a pool hall that was written in PHP ~12 years ago. There are 4 different leagues, each on their own database, all running very similar (but not the same) versions of the code on similar but not the same db schemas.

So I'm trying to modernize it by building a separate app that can interoperate with the 4 different schemas and do all the same things that the old app did. It's an interesting exercise in replacing legacy code piece by piece while still using it (all the leagues would not function if the site didn't work, and there's basically 3 weeks out of the year when the leagues aren't playing).

Professionally, on the other hand, I work at a startup where I've more or less had my hands in the code from day one.

edw519 

                Analysis Programming Debugging Overhead
  ------------  -------- ----------- --------- --------
  My Own Stuff    30%       60%         10%       0%
  Others' Code    50%       10%         30%      10%
  Enterprise      10%       10%         10%      70%
pc86
I get your point but my guess is the lack of analysis is only exacerbating the problem on the Enterprise end.
bitshepherd
That's where you schedule a meeting to talk about scheduling a meeting to talk about Where We Went Wrong With Analysis.
pc86
You joke but the meeting meetings are pretty common, and as awful as you would expect.
malux85
If he means reading code and documentation as the only activities of analysis, then I'd say the ratios are about right.

The overhead consists of endless meetings that never reach consensus, but arguably this could be filed under analysis

imdsm
Meetings, discussions about meetings, pre-meeting discussions regarding discussion to be had in meeting, logging all time spent in meetings, discussing meetings, discussing discussions to be had in meetings, logging time lost to "noise" to figure out why nothing gets done on time, meeting to look at time spent on "noise", planning what to do with remaining time, having a meeting to discuss what to do with remaining time, updating numerous workload management tools with tasks to do with remaining time, spend time trying to get back into work, get pulled off to do something of far less value but which is "much more urgent", log time spent on that, have a meeting to discuss all upcoming urgent and unscheduled things, have a discussion about what wont get done, goto 1.
lossolo
Coding is only the tool, i don't spent much time coding, i spent a lot of time designing/analyzing then i spent time debugging/testing which takes more time than coding.
sitkack
I am currently integrating a handful of open source big data systems and frameworks, the breakdown of my time is

    60% debugging
    15% stack overflow
    25% email archives
    15% commit logs
    10% navigating code, spelunking
    12% jira
     5% writing tests to confirm config/state/feature availability
     3% coding
twunde
I spend most of my time debugging or extending old code, but then again I'm personally responsible for about 600,000 lines of undocumented code without any tests (but there are a lot of daily reports which act as monitoring checks). I will say that I rarely need to debug my own code, it's usually old code that needs to be updated due to a data change or business logic change
wyc
From The Mythical Man-Month by Fred Brooks:

  """
No parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test. Furthermore, the time required depends on the number and subtlety of the errors encountered. Theoretically this number should be zero. Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore testing is usually the most mis-scheduled part of programming. For some years I have been successfully using the following rule of thumb for scheduling a software task:

  1/3 planning
  1/6 coding
  1/4 component test and early system test
  1/4 system test, all components in hand.
      This differs from conventional scheduling
      in several important ways:
1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.

2. The half of the schedule devoted to debugging of completed code is much larger than normal.

3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.

  """
cannam
and from Robert L Glass, Facts and Fallacies of Software Engineering (2003, but I think a self-reference from Building Quality Software, 1992):

"The data on the percentage of time spent in error removal has varied over the years, but the usual figures are 20-20-20-40. That is, 20 percent for requirements, 20 percent for design, 20 percent for coding (intuition suggests to most programmers that here is where the time is spent, but intuition is very wrong), and 40 percent for error removal."

ChrisBland
Neither, I spend more time writing or thinking about tests. When I was earlier in my career I used to insert debug comments, run code, look at output to figure out what was going on. Now, I try to write my tests that will eliminate the need to debug. If I'm trying to fix a bug, the first thing I do is write tests for what should happen if the tests don't already exist and work backwards from there. If you get in a good habit of this, it just becomes natural and with today's toolchains you can re-run tests with a watcher to achieve a real time feedback loop, which is better than a debugger IMO. The plus side is going forward you always know that the code works vs just seeing it work that one time. As your application grows, something may change what the value of the debug statement output and you'll never catch it, but your test will. /old man rant
existencebox
I'd shift your statement slightly, "I spend my time Thinking" (elided "about test"), but agree entirely with the thrust of your point.

My reason for the truncation is that the thinking isn't just about what tests to write to validate the semantics you want, but what semantics do you even WANT? Happy path may take an hour to figure out, but getting to a point (for a reasonably complex system) where I feel confident that I've enumerated the "perimiter" of the mental model such that there are fewer surprises, gotchas, odd edge cases, usually takes significantly more contemplation of the problem space than modern big-co "DELIVER FEATURES NOW NOW NOW" would often like, certainly more time than spent actually implementing, by and large.

(you may sense some bitterness, it is largely because a respected mentor of mine made significant effort to stress to me that if I'm leaning on a debugger, or having to printf a lot, I probably don't UNDERSTAND what's going and and can fall prey to far more severe logical issues; and despite my observation that I became a far more robust engineer utilizing this strategy, it's often hard to incentivise balancing this against simply shipping, especially given the difficulty of empirically justifying "I need a day to think really hard about this problem to make sure it's not subtlety wrong" against the rebuttal of "what's the ROI")

dibanez
Agreed. I used to debug large "integration tests". Now with unit testing, I'm only debugging a bit of new code atop a foundation that is regularly unit tested.
koolba
Neither. I spend most of my time procrastinating and/or day dreaming.
richmt
Same here. I often spend time wondering if it's simply that this field isn't for me, 40hrs a week kills my drive, or if it's a bigger issue like depression.

Only thing I enjoy now are exercise and music.

jgsteven
Have you ever coded for a project you were excited about? Where you could feel really good about delivering a quality, useful product? If possible, try and find that at your current job. If not, a new job may be the best route. Management and bureaucracy are great at squashing good vibes here.

Also, see if you can find some satisfaction in expanding your programming skills through reading and learning. Not sure your experience level here, but I would recommend that to anyone -- it has made a huge difference to me personally.

richmt
Pretty early in my career. I've held two jobs that both sound wildly better than any other option in the near area (small startups with tons of work vs. big businesses where nothing gets done).

I intend to spend no free time on my career outside of work. There are far too many other things in life I would prefer to work on and experience, hence why I wonder if this is the right field for me.

Sorry if I sound so negative, it's just how I've felt since first starting out in my field.

gaius
On the other hand I bet your .bashrc and .emacs are amazing
koolba
> On the other hand I bet your .bashrc and .emacs are amazing

Nope, but my .vimrc is a work of art.

zhte415
Implementation (existing code) - 30%

  Maintaining - if this means soft feature creep, then 10%

  Maintaining - if this means bug fixes and other things, put in implementation, 5%
Creating nice PPTs and control documents about stuff - 30%

  I genuinely like this

  New functionality 20%, including sitting with users for new functionality requests, seeing their workflow
My main job. Having whittled this down to 20% of my day, I need to start ramping it up again. It is nice to have 10% time, and I loved 50% time, but 80& time may get discovered (though all time is dedicated to the company)

Other stuff. Like filling in timesheets, which assume hours can accurately be attributed to discrete tasks for discrete people any and all of the time.*

* Just set goals for staff. Do staff achieve their goals? If so, why timesheet? Or just timesheet roughly, my hour-by-hour 7 day per week sheet is a pain.

cindy68
Am spend more time on debugging.
beardog
you need to debug this comment
MaulingMonkey
Missing capitalization, and terminating semicolon.

I mean period. Terminating period.

lisivka
I am spending most of the time on coding. Debugging is "waste".