How do you balance your dev time between debugging existing issues and new feature dev?
Manisha Malla
19 replies
Replies
Maciej Cupial@maciej_cupial
Fix for existing issues has to go first. I can't build anything new if the old features don't work.
Share
@maciej_cupial Absolutely, especially for the P0s. The trickier ones to prioritize over new features are the smaller ones - which then keep piling up over time.
Journaleo
We dedicate specific days to fixing bugs - squashing small bugs saturdays and the occasional fixing fat bugs fridays 😂.
@allison_mui This is a good way to keep the team focussed through the week. Except when some priority customer issues suddenly surface midweek. BTW, I like 'fat bugs fri-days' :)
@allison_mui Dedicating certain days a week for bug fixing does seem like a good idea.
Intersting topic to discuss Manisha. Usually during our initial stages of testing (say in Beta) time taken to fix the issues reported is lesser as the issue reproduction & fix is straight forward. As the product starts maturing and our customers starts using the product, then we start seeing issues which are hard to replicate internally and becomes tricky. Here we spend lots of time to fix such tricky issues. Some issues takes days to understand why it happend. Looking at zipy now, i feel we shall start getting precise and useful information from zipy and tricky issues would be less tricker to resolve :)
@bhargavamnn Absolutely. Bugs get trickier to solve as the product matures.
I know how issues can impact project plans? I have spent lot of time in reproducing and debugging issues. It takes a lot of time and energy too. With Zipy I am sure we will be able to get the critical scenario information and it will save lot of time of developers :)
@nidhi_jindal1 Yes, some bugs are very difficult to reproduce. Finding the relevant information about them is what becomes critical.
I found this post very interesting and informative. Thank you for sharing your special thoughts with us. I definitely share this with my peeps.
@anhuijiuxin123 Glad to know that, Keven.
I always start my day with work on new feature development as the mind is estatic and full of energy and when I have accomplished enough on the set day I switch to my full pro debugging mode which specially
supercharges when at my personal space in the evening to night time as it is always more peaceful and quiet that time and hence sometimes I dream of them😂😂😂 too...
@rahul_kumar_pandey True. It's always tough to prioritize between the two.
Great question. Normally I start my day with the development of new project. When I complete 50% of the new project I switch to the debugging mode like now I will do fixation of https://prourdu.pk/hesco-bill-on... . When it is fixed then again I will start the remaining 50% of the new project. So this schedule is quite good for me.
@grayson_leo Interesting. Any challenges you face in switching context to debugging and then back to feature dev?
This is a very interesting question. In our team we take the approach of "sprints", where we work on brainstorming, preparing and actually creating new features. Then between every "sprint" there is a period (that can vary in its duration), when we patch the holes and work on correcting the existing issues. Of course it also involves prioritisation - how urgently does a current issue need to be resolved? Does it interfere with the main idea of the project? How important is the feature that isn't working correctly? Sometimes you need to correct an issue urgently before proceeding to create new ones, but if an issue is not pressing, I think it is important to allow yourself room to create new things and not only focus on correcting the existing issues, because something will never be entirely perfect. In this case, it is important to not pressure yourself with perfectionism in order to have room to grow in multiple directions.
@manishamalla Thanks! A lot of times the process of correcting the issues is a gap filler between sprints of work related to developing the product or particular features, but that depends on the overall stage the team is at. After a completing particular goal oriented set of sprints, we can have another sprint that is dedicated to another goal. For example, to evaluating the efficiency of existing technology, its usability, impressions etc and correcting the issues/bugs. I believe it is important to take time from developing new to critically reflecting on the existing work to be able to move forward accordingly :)
@konstantin_sharespace This is a really interesting approach. Would be interested to know more. How long is the period between the sprints when you correct the existing issues - is it a sprint in itself or a gap filler?
We always use the management software for balancing the dev time. As our software assign time for each project and we have to complete that work in the assign time. Let's support if software assign us 1 hour for https://fantaserye.su/pinoy-tamb... page development and we don't complete it in 1 hour. Then we will do it the next day or in the break time. So that the other project is not get disturbed.