Too early implementation
I am not a very disciplined person. Usually I rush to my next assignment and code furiously, hoping that my initial understanding of the stated problem will be just fine. And Python does very little to stop me ;-) If I had to do something in C++, I know I would have to write all those header files, fill stubs, etc., which is a lot of work, which I don't want to do twice. So I take a while and start to think, because it's better to be safe, than sorry. With Python you rarely are sorry, because you can do everything so quickly. And yet, at some point you see, that flaws in design get so annoying, that you need to do something about them. Usually at that point it's a bit problematic ;-) So, do you know some good methods to prevent myself from just starting coding (which I like very much) and do some thinking about the problem (which I like a little less ;-))? -- Filip Gruszczyński -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
Filip Gruszczyński wrote: I am not a very disciplined person. Usually I rush to my next assignment and code furiously, hoping that my initial understanding of the stated problem will be just fine. And Python does very little to stop me ;-) If I had to do something in C++, I know I would have to write all those header files, fill stubs, etc., which is a lot of work, which I don't want to do twice. So I take a while and start to think, because it's better to be safe, than sorry. So, do you know some good methods to prevent myself from just starting coding (which I like very much) and do some thinking about the problem (which I like a little less ;-))? Well, you can force yourself to write tests first... -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
On Apr 18, 9:48 pm, Filip Gruszczyński grusz...@gmail.com wrote: With Python you rarely are sorry, because you can do everything so quickly. And yet, at some point you see, that flaws in design get so annoying, that you need to do something about them. Usually at that point it's a bit problematic ;-) So, do you know some good methods to prevent myself from just starting coding (which I like very much) and do some thinking about the problem (which I like a little less ;-))? Try test-driven development: http://en.wikipedia.org/wiki/Test-driven_development -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
On Apr 18, 12:48 pm, Filip Gruszczyński grusz...@gmail.com wrote: So, do you know some good methods to prevent myself from just starting coding (which I like very much) and do some thinking about the problem (which I like a little less ;-))? Well you know, the thing is that according to Pike Kernighan in The Practice of Programming, your first implementation of a program should be scrapped and rewritten from scratch, so your approach might not be that wrong after all. The trouble is that if you overthink your code, you'll end up losing interest in the project and write bloated code that may be too generic for what you need. So either way there can be trouble, although it is right to try to balance yourself in between these two extremes... -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
In article f317e00e-042c-4894-83dc-bdd83fbbe...@y7g2000yqa.googlegroups.com, stephane.bisin...@gmail.com wrote: Well you know, the thing is that according to Pike Kernighan in The Practice of Programming, your first implementation of a program should be scrapped and rewritten from scratch, so your approach might not be that wrong after all. This observation was originally made in _The Mythical Man-Month_ by Fred Brooks, which ought to be required reading for all programmers. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ If you think it's expensive to hire a professional to do the job, wait until you hire an amateur. --Red Adair -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
On Apr 18, 4:44 pm, a...@pythoncraft.com (Aahz) wrote: This observation was originally made in _The Mythical Man-Month_ by Fred Brooks, which ought to be required reading for all programmers. I miss that one, yet :( Nice to know, though -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
Yep, I have heard a lot about test driven development. I am now programming a lot using DJango and I would like to use its test framework to try it. However, I have little experience with this (as most people I know). I also have no idea, how to apply this, when I write code heavily focused on user interface. I thought, that prototyping is cool, especially with python, where you can create something functional pretty quickly. But recently I was met with a situation, when after writing 1k lines of prototype and then writing main program 3k lines I noticed, that there is something really wrong with the design. It was then, that I started wondering: maybe I should first prepare some good design documents, I don't know some SAD or something. -- Filip Gruszczyński -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
On Apr 18, 5:54 pm, Filip Gruszczyński grusz...@gmail.com wrote: Yep, I have heard a lot about test driven development. I am now programming a lot using DJango and I would like to use its test framework to try it. However, I have little experience with this (as most people I know). I also have no idea, how to apply this, when I write code heavily focused on user interface. One of the most complete testing suites I know of is jUnit, even though you don't know Java, it may still be useful to you understand how the thing works. There is also a pyunit framework, but I fear that jUnit has a better overall documentation - anyway the concepts are similar. I thought, that prototyping is cool, especially with python, where you can create something functional pretty quickly. But recently I was met with a situation, when after writing 1k lines of prototype and then writing main program 3k lines I noticed, that there is something really wrong with the design. It was then, that I started wondering: maybe I should first prepare some good design documents, I don't know some SAD or something. My experience with design documents and all is that you end up not following them anyway because when you start to code you also start to realize you forgot something. Software Engineering would have you fall back to redesign to include the new stuff in, but I've hardly ever seen that happen. Of course you can try, because what works for me could not be working for you... The thing with software engineering is that nobody has found a good answer to these problems yet, no matter what they claim. Every approach has its advantages and its drawbacks, it is up to you to find your own way to deal with this kind of problems -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
2009/4/18 Filip Gruszczyński grusz...@gmail.com: Yep, I have heard a lot about test driven development. I am now programming a lot using DJango and I would like to use its test framework to try it. However, I have little experience with this (as most people I know). I also have no idea, how to apply this, when I write code heavily focused on user interface. There are many testing frameworks to choose from with regards to interface, but at least starting with unit tests (which don't need to interact with the interface) will still gain you something, and help guide the design probably a little better than interface tests at that. My style of TDD is to alternate somewhat between the code and the tests. When that idea pops into my head about how to do something, I will either write a test OR write the code to make it work, depending on what my inspiration is. If the inspiration is API related, then the test gets written first, because what is in my head are really interface stuff and not implementation. On the other hand, if my inspiration is code/implementation related, I will write the code. Afterward, I will switch and write the other piece, which sort of backs up whatever my decision was (or doesn't). I don't follow this exactly, it's just my general coding style when I am using tests. Sometimes I don't use tests at all (they aren't quite as helpful in game programming as in other domains), and in those cases I generally try to refactor or clean up my code before a script gets too long, where too long means I am getting frustrated at not being able to find where to fix problems or add features fast enough. In practice, this usually means writing about 800-1000 lines of code in one script, and then exploding one script into several. I thought, that prototyping is cool, especially with python, where you can create something functional pretty quickly. But recently I was met with a situation, when after writing 1k lines of prototype and then writing main program 3k lines I noticed, that there is something really wrong with the design. It was then, that I started wondering: maybe I should first prepare some good design documents, I don't know some SAD or something. It's pretty hard to design very much up front, because when you get into the code things change. Maybe if you do some coding and then start designing as you go to keep yourself on the right track. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
Start to like blogging about your ideas, results and findings. Writing is a process of clarification of the mind. It doesn't matter much whether you design upfront, or mix coding and writing in an incremental process. If I could I'd just write specs, draft my ideas in Python in order to verify that I really know what I'm talking about and let others work out the details. Of course I'm not in the splendid position of a university professor or an intellectual capitalist. -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
On Apr 18, 7:48 am, Filip Gruszczyński grusz...@gmail.com wrote: So, do you know some good methods to prevent myself from just starting coding (which I like very much) and do some thinking about the problem (which I like a little less ;-))? There are a lot of ideas, some you've seen earlier in this thread. Below is a sketch of the approach I prefer. 1) Know exactly what problem you are trying to solve. Describe the problem to the client and make sure the client agrees with your definition. 2) Code up the solution in the simplist possible way. (Document the strategy with an architectural outline, maybe). 3) Write tests to exercise/debug the code and make sure you solved the problem. Also demo the prototype to the client and make sure the client agrees you solved the problem. Usually at this point the first time through you realize that you didn't solve the problem, or didn't solve the right problem, so you should start over at (1) ideally making use of the bad implementation you have for reference only (except for parts which can be included without modification). [Thank yourself you didn't try to optimize your wrong solution and that you implemented it in the simplist possible way.] If you did solve the right problem then... (4) Okay, now you solved the problem. Do you need to optimize anything? If so, optimize, using the test cases to make sure your optimizations don't break anything. If not, you are done: don't optimize anything. (5) Now document your APIs, and other interfaces. (Ahem). For example WHIFF http://whiff.sourceforge.net is a descendant of a lot of libraries and tools I've written to help me and people I've worked with build web sites over the years. It's been some months but I think I started/restarted 3 times before I was happy with the basic approach and could move forward past step (3). -- Aaron Watters http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool === Software time estimation rule: How long could it possibly take? Double that. Switch to the next higher time units (days..weeks etc) -- http://mail.python.org/mailman/listinfo/python-list
Re: Too early implementation
On Sat, 2009-04-18 at 13:48 +0200, Filip Gruszczyński wrote: So, do you know some good methods to prevent myself from just starting coding (which I like very much) and do some thinking about the problem (which I like a little less ;-))? The Method (If you can call it that) that I use is to have users throw requests at me so fast that they normally have to get backlogged for months at a time (I've got several years worth of backlogged work at the moment). That way by the time I actually start coding I've normally read over the issue several times and approached the problem from various angles ;-) Tim Wintle -- http://mail.python.org/mailman/listinfo/python-list
