Comments on: How I work with code http://www.morkeleb.com/2009/09/08/how-i-work-with-code/ Simple design for advanced constructions Mon, 06 Feb 2012 03:50:10 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Building Blocks » Test-list http://www.morkeleb.com/2009/09/08/how-i-work-with-code/comment-page-1/#comment-290 Building Blocks » Test-list Mon, 07 Dec 2009 09:16:16 +0000 http://www.morkeleb.com/?p=594#comment-290 [...] thing. Some might remember my how I work with code, where you keep a list of issues you figure out as you work with the [...] [...] thing. Some might remember my how I work with code, where you keep a list of issues you figure out as you work with the [...]

]]> By: Building Blocks » Getting things done with teams http://www.morkeleb.com/2009/09/08/how-i-work-with-code/comment-page-1/#comment-221 Building Blocks » Getting things done with teams Sat, 24 Oct 2009 20:15:38 +0000 http://www.morkeleb.com/?p=594#comment-221 [...] this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my [...] [...] this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my [...]

]]> By: Building Blocks » How I work with code the unit test part http://www.morkeleb.com/2009/09/08/how-i-work-with-code/comment-page-1/#comment-176 Building Blocks » How I work with code the unit test part Thu, 10 Sep 2009 17:17:47 +0000 http://www.morkeleb.com/?p=594#comment-176 [...] wrote a blog post about how I work with code. The basic idea is that I record actions that I need to take as I work with the code in a format [...] [...] wrote a blog post about how I work with code. The basic idea is that I record actions that I need to take as I work with the code in a format [...]

]]> By: admin http://www.morkeleb.com/2009/09/08/how-i-work-with-code/comment-page-1/#comment-173 admin Wed, 09 Sep 2009 07:24:41 +0000 http://www.morkeleb.com/?p=594#comment-173 The core benefit here is ofcouse focus for the developer. The core benefit here is ofcouse focus for the developer.

]]> By: admin http://www.morkeleb.com/2009/09/08/how-i-work-with-code/comment-page-1/#comment-172 admin Wed, 09 Sep 2009 07:23:15 +0000 http://www.morkeleb.com/?p=594#comment-172 As described in Getting Things Done, you often get new ideas as your current idea is reflected back to you. Tracking these ideas, you can build on them and produce new ones. Now if you have to solve a specific task, you can finish that task, but still have a set of ideas or new knowledge about the design or even in the case of Lean software development need to stop the line. Now the purpose of "keeping track of issues", or incidents if that is better word, is to quickly finish the task so it can be tested and accessed by others relying on it. Most of these incidents are thrown out, and not kept track of. Or solved at within two minutes after the original task is solved. These are not issues on the user scale but questions raised during the development. Once you have a working skeleton at place you can go back and fix "the issues" that are clearly visible to all. And especially those that were missed during automated testing. But also get new ideas, that might be better solutions to the given problem. "Ugly code in need of refactoring" is subjective, and should be handled with care. Not refactored on the fly, in a Lean pespective, "Ugly code in need of refactoring" requires a stop the line, in order to raise the issue. The line stop might infact result in the response that it is not changed, since noone has a better idea at the time. Automated tests assist in refactoring. They do not prevent you from the need of refactoring, nor do they automatically imply good design. Automated tests are not a silverbullt for building quality software. As described in Getting Things Done, you often get new ideas as your current idea is reflected back to you. Tracking these ideas, you can build on them and produce new ones. Now if you have to solve a specific task, you can finish that task, but still have a set of ideas or new knowledge about the design or even in the case of Lean software development need to stop the line.

Now the purpose of “keeping track of issues”, or incidents if that is better word, is to quickly finish the task so it can be tested and accessed by others relying on it. Most of these incidents are thrown out, and not kept track of. Or solved at within two minutes after the original task is solved. These are not issues on the user scale but questions raised during the development.

Once you have a working skeleton at place you can go back and fix “the issues” that are clearly visible to all. And especially those that were missed during automated testing. But also get new ideas, that might be better solutions to the given problem. “Ugly code in need of refactoring” is subjective, and should be handled with care. Not refactored on the fly, in a Lean pespective, “Ugly code in need of refactoring” requires a stop the line, in order to raise the issue. The line stop might infact result in the response that it is not changed, since noone has a better idea at the time.

Automated tests assist in refactoring. They do not prevent you from the need of refactoring, nor do they automatically imply good design. Automated tests are not a silverbullt for building quality software.

]]> By: anna forss http://www.morkeleb.com/2009/09/08/how-i-work-with-code/comment-page-1/#comment-171 anna forss Wed, 09 Sep 2009 06:19:40 +0000 http://www.morkeleb.com/?p=594#comment-171 One of the purposes of automatically tested code should be that this shouldn't be an issue. But I agree in principle with the statement that a issue should be raised and reported. But this should really be done independent of the task being completed at that time. By raising the issue you can discuss the reason for the problem arising in the first place with the team and you can better keep track of how time is spent. By the latter I don't mean that you should count minutes, but more get an overview of which tasks has been addressed. But then we come to the question of fixing or not fixing. Having become even more of a believer in Lean Software Development I cannot help becoming troubled of the idea of keeping track of bugs and problems instead of fixing them. Keeping problems on a queue is not preventing the same type of problem arising again and again. Yes, you should differ between bugs and "ugly code in need of refactoring" but unreadable code can also be seen as a risk and an impediment for improvement. Well worth discussing, though, and that is perhaps the most important challenge for a team. Knowing how to handle this question. One of the purposes of automatically tested code should be that this shouldn’t be an issue. But I agree in principle with the statement that a issue should be raised and reported. But this should really be done independent of the task being completed at that time. By raising the issue you can discuss the reason for the problem arising in the first place with the team and you can better keep track of how time is spent. By the latter I don’t mean that you should count minutes, but more get an overview of which tasks has been addressed.

But then we come to the question of fixing or not fixing. Having become even more of a believer in Lean Software Development I cannot help becoming troubled of the idea of keeping track of bugs and problems instead of fixing them. Keeping problems on a queue is not preventing the same type of problem arising again and again.

Yes, you should differ between bugs and “ugly code in need of refactoring” but unreadable code can also be seen as a risk and an impediment for improvement. Well worth discussing, though, and that is perhaps the most important challenge for a team. Knowing how to handle this question.

]]>