Comments on: Think a little, code a little http://www.markhneedham.com/blog/2009/08/05/think-a-little-code-a-little/ Thoughts on Software Development Sat, 11 Feb 2012 23:17:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mark Needham http://www.markhneedham.com/blog/2009/08/05/think-a-little-code-a-little/comment-page-1/#comment-21369 Mark Needham Fri, 14 Aug 2009 00:25:35 +0000 http://www.markhneedham.com/blog/?p=1512#comment-21369 @David the coding frenzy you describe sounds quite similar to what Uncle Bob would refer to as 'creating a mess'! Which I suppose is exactly what it is. I'm not even sure if people consciously do it or just get dragged into that practice when they feel the pressure. @Niilo I like the idea of delaying finalizing decisions so that you can change them later on. It'd be interesting to know what techniques are useful for allowing us to do that successfully. I like your last paragraph, hadn't thought of it like that before but that's quite insightful. @David the coding frenzy you describe sounds quite similar to what Uncle Bob would refer to as ‘creating a mess’! Which I suppose is exactly what it is.

I’m not even sure if people consciously do it or just get dragged into that practice when they feel the pressure.

@Niilo I like the idea of delaying finalizing decisions so that you can change them later on. It’d be interesting to know what techniques are useful for allowing us to do that successfully.

I like your last paragraph, hadn’t thought of it like that before but that’s quite insightful.

]]> By: [ mkhairul.com ] » Think a little, code a little.. http://www.markhneedham.com/blog/2009/08/05/think-a-little-code-a-little/comment-page-1/#comment-21259 [ mkhairul.com ] » Think a little, code a little.. Tue, 11 Aug 2009 17:18:13 +0000 http://www.markhneedham.com/blog/?p=1512#comment-21259 [...] to the comment on the post by Mark Needham, Think a little, code a little. Lazy coding often also takes the form of a “coding frenzy” where the euphoria of [...] [...] to the comment on the post by Mark Needham, Think a little, code a little. Lazy coding often also takes the form of a “coding frenzy” where the euphoria of [...]

]]> By: Niilo Tippler http://www.markhneedham.com/blog/2009/08/05/think-a-little-code-a-little/comment-page-1/#comment-21174 Niilo Tippler Sun, 09 Aug 2009 18:53:22 +0000 http://www.markhneedham.com/blog/?p=1512#comment-21174 I've always been in favor of what I term "Evolutionary Engineering", where the project evolves and changes during the development cycle as problems are encountered and resolved and new ideas come about from the growth of the code. I usually like to take a fair amount of time at the beginning thinking about my coding solutions, how I'm going to structure things, and the overall architecture, then I start coding with an eye towards knowing that things will very likely change as I move forward. I build prototypes which provide me with rapid turnaround examples of specific functionality, which can then be modularized for easy implementation later, then I build the framework which allows me to test the basic framework. I always assume that a client is going to want something added that's out of scope of the original spec, so this keeps me from finalizing too much early on. Building in discrete steps allows the project to evolve. I like to consider all projects to be fluid - the spec is a guideline, but never set in stone. New ideas can come along at any time, and what looks good on paper doesn't always (in fact rarely) translate into a usable end product. I often provide suggestions to my clients during the development process of improvements to UI or functionality that have arisen from the results of prototyping and testing particular operations and overwhelmingly these changes become a part of the evolutionary process resulting in a much improved end product. The ability to think-code-think-code and allow the project spec to be fluid and malleable is essential, in my opinion, to being able to deliver not only what the client asked for in the first place, but also all those extras that turn a good project into a great one and help to generate return business. I’ve always been in favor of what I term “Evolutionary Engineering”, where the project evolves and changes during the development cycle as problems are encountered and resolved and new ideas come about from the growth of the code. I usually like to take a fair amount of time at the beginning thinking about my coding solutions, how I’m going to structure things, and the overall architecture, then I start coding with an eye towards knowing that things will very likely change as I move forward. I build prototypes which provide me with rapid turnaround examples of specific functionality, which can then be modularized for easy implementation later, then I build the framework which allows me to test the basic framework. I always assume that a client is going to want something added that’s out of scope of the original spec, so this keeps me from finalizing too much early on. Building in discrete steps allows the project to evolve. I like to consider all projects to be fluid – the spec is a guideline, but never set in stone. New ideas can come along at any time, and what looks good on paper doesn’t always (in fact rarely) translate into a usable end product. I often provide suggestions to my clients during the development process of improvements to UI or functionality that have arisen from the results of prototyping and testing particular operations and overwhelmingly these changes become a part of the evolutionary process resulting in a much improved end product.

The ability to think-code-think-code and allow the project spec to be fluid and malleable is essential, in my opinion, to being able to deliver not only what the client asked for in the first place, but also all those extras that turn a good project into a great one and help to generate return business.

]]> By: Twitted by pramatrdev http://www.markhneedham.com/blog/2009/08/05/think-a-little-code-a-little/comment-page-1/#comment-21168 Twitted by pramatrdev Sun, 09 Aug 2009 15:19:59 +0000 http://www.markhneedham.com/blog/?p=1512#comment-21168 [...] This post was Twitted by pramatrdev [...] [...] This post was Twitted by pramatrdev [...]

]]> By: Jose Noheda http://www.markhneedham.com/blog/2009/08/05/think-a-little-code-a-little/comment-page-1/#comment-21151 Jose Noheda Sun, 09 Aug 2009 08:05:31 +0000 http://www.markhneedham.com/blog/?p=1512#comment-21151 You've just named my coding strategy. I seem unable to design upfront. On the other hand coding some general idea gives me an in-depth of the failures really quick. Of course, I understand that other people may feel different and prefer formal design steps. You’ve just named my coding strategy. I seem unable to design upfront. On the other hand coding some general idea gives me an in-depth of the failures really quick. Of course, I understand that other people may feel different and prefer formal design steps.

]]> By: David Morton http://www.markhneedham.com/blog/2009/08/05/think-a-little-code-a-little/comment-page-1/#comment-20959 David Morton Tue, 04 Aug 2009 16:06:38 +0000 http://www.markhneedham.com/blog/?p=1512#comment-20959 I agree completely. Lazy coding often also takes the form of a "coding frenzy" where the euphoria of programming combined with the anticipation of the client's happiness when a project is delivered early can cause a situation where the programmer hurries in order to create the single deliverable at the expense of the clean code base. Unfortunately, this often has the opposite of the desired effect later on in the application lifecycle when the technical debt starts to catch up with you, and suddenly your maintenance time is increased and time between releases is decreased. There's most certainly a balance. One extreme assumes the future, while the other ignores it. We certainly have a limited view of what's ahead. Assume neither nothing nor everything, but assume something in between. This is what "think a little, code a little" sounds like to me. I agree completely. Lazy coding often also takes the form of a “coding frenzy” where the euphoria of programming combined with the anticipation of the client’s happiness when a project is delivered early can cause a situation where the programmer hurries in order to create the single deliverable at the expense of the clean code base. Unfortunately, this often has the opposite of the desired effect later on in the application lifecycle when the technical debt starts to catch up with you, and suddenly your maintenance time is increased and time between releases is decreased. There’s most certainly a balance. One extreme assumes the future, while the other ignores it. We certainly have a limited view of what’s ahead. Assume neither nothing nor everything, but assume something in between. This is what “think a little, code a little” sounds like to me.

]]>