I made a surprise amount of progress truth be told. I've got nodes, arcs, and connecting dots. I don't have the ability to connect things yet, nor is there any functionality in the back end. But when I actually get around to making the functional back-end, that will go rather quickly I feel. I know exactly how I want to do that.
This was an experiment of will. Can I just sit down and decide "I'm going to make this" and try to just simply make it? I certainly can. It is kind of nice to finally get a little bit of a handle on creating GUIs with python. I've learned quite a bit this evening and I've got a lot to ponder as I push forward with Facere. But I'm pleased with what I've got thus far.
Tuesday, January 31, 2012
Code Rush
I'm going to try something silly and ridiculous and probably won't work. But here it goes. I've come up with an idea for a universal editor. I'm going to teach myself Tkinter in python and create this program in 5 hours. it isn't a complex program so it has potential. but Really thinking I could teach myself Tkinter and make a program in the next 5 hours is foolishness. but here we go! Facere coming down the pike.
Thursday, January 19, 2012
SOPA & PIPA
I suppose it is about time I give my two bits on SOPA and PIPA. Not suprisingly I am greatly opposed to it. I also Really do believe that piracy is bad. But Twenty sided had a point. If you are a company that has one channel of making money and then protecting/sustaining that channel comes to cost more than the channel is worth, you should drop it.
For example, Telegraph is dead. Truth be told it was much cheaper to have a telegraph line than a phone line, but the public has spoken, or at least they litterally wanted to and telegraph died. The postal system is another one. There was a big out cry when some one proposed that the postoffice only deliever 3 out of the 6 days of the week, to cut costs by reducing the number of mailmen dramatically. I don't blame mail men, nor am I suprised by the massive opposition they put forth. But think about it. Bank statements, bills, and almost all leters come digitally anymore. its faster, cheaper, and more reliable. Tell me. If something was faster, cheaper, and more reliable, wouldn't you toss the old one?
My point with the mail system is that times are changing. We don't use the mail system as a vital life line of information anymore. It has been replaced. Times are changing with computer games too. The days where you actually buy physical media is dying out. Now publishers don't like this for a couple reasons.
1. it is what they are used to. For a few decades everything was done by buying floppies, CD's, DVD's, Cartigages, etc etc. This was a simple system and easy to control.
2. They loose their advantage on barrier to entry. In order to make money selling a video game you have to sell a large quantity of copies. With DLC, the cost of each additional copy is negligable. But when you are selling physical media, each additional copy can cost you 2$ or so. Publishers use this to their advantage, previously you couldn't make any money with out a huge investment. Now the app store, steam, android market, etc, just take a small royalty, meaning there is no barrier to entry. and this means indie games are rising. And big time publishers don't like that extra competition.
Why SOPA and PIPA are bad is that they are backwards and close minded. They are bills that are trying to protect an out dated system. Do I think piracy is good? no. But obviously people aren't using the postal system, so why defend it? I understand defending out dated systems because that is where your income is from. I don't have any problem with people thinking they should, it is your lively hood. But you know what the really smart and successful people do? Rather than try to help an out-dated industry limp along, they find ways to take advantage of the new industries that come around.
A fantastic example of this is the dot com boom. Thousands of start ups came around. But after all has been said and done, we have Amazon and eBay, that's it. There were dozens of companies that did exactly what Amazon and eBay did, but they did it right, they did it better, the competition died out and left just the two. The dot com boom happened when everyone decided that putting everything on the internet was a fantastic idea. well suprise suprise, the internet has its limits, just as any other medium. Walmart clobers lots of litte stores, but some how every little town in Iowa still has its own grocery store. why? because walmart isn't sufficent, walmart can't do everything. particularly, walmart can be in every small town.
I'm just kind of rambling at this point so I'll bring this to a close. SOPA and PIPA, they are backwards and narrow sited. the DRM problem with video games will cease to exist when all video games are just stored on the cloud. Do I think that that is what's going to happen? Probably, I'm not 100% certain, but it certainly seems like it is probable. And guess what happens when everything is stored in the cloud? You can't pirate it.
For example, Telegraph is dead. Truth be told it was much cheaper to have a telegraph line than a phone line, but the public has spoken, or at least they litterally wanted to and telegraph died. The postal system is another one. There was a big out cry when some one proposed that the postoffice only deliever 3 out of the 6 days of the week, to cut costs by reducing the number of mailmen dramatically. I don't blame mail men, nor am I suprised by the massive opposition they put forth. But think about it. Bank statements, bills, and almost all leters come digitally anymore. its faster, cheaper, and more reliable. Tell me. If something was faster, cheaper, and more reliable, wouldn't you toss the old one?
My point with the mail system is that times are changing. We don't use the mail system as a vital life line of information anymore. It has been replaced. Times are changing with computer games too. The days where you actually buy physical media is dying out. Now publishers don't like this for a couple reasons.
1. it is what they are used to. For a few decades everything was done by buying floppies, CD's, DVD's, Cartigages, etc etc. This was a simple system and easy to control.
2. They loose their advantage on barrier to entry. In order to make money selling a video game you have to sell a large quantity of copies. With DLC, the cost of each additional copy is negligable. But when you are selling physical media, each additional copy can cost you 2$ or so. Publishers use this to their advantage, previously you couldn't make any money with out a huge investment. Now the app store, steam, android market, etc, just take a small royalty, meaning there is no barrier to entry. and this means indie games are rising. And big time publishers don't like that extra competition.
Why SOPA and PIPA are bad is that they are backwards and close minded. They are bills that are trying to protect an out dated system. Do I think piracy is good? no. But obviously people aren't using the postal system, so why defend it? I understand defending out dated systems because that is where your income is from. I don't have any problem with people thinking they should, it is your lively hood. But you know what the really smart and successful people do? Rather than try to help an out-dated industry limp along, they find ways to take advantage of the new industries that come around.
A fantastic example of this is the dot com boom. Thousands of start ups came around. But after all has been said and done, we have Amazon and eBay, that's it. There were dozens of companies that did exactly what Amazon and eBay did, but they did it right, they did it better, the competition died out and left just the two. The dot com boom happened when everyone decided that putting everything on the internet was a fantastic idea. well suprise suprise, the internet has its limits, just as any other medium. Walmart clobers lots of litte stores, but some how every little town in Iowa still has its own grocery store. why? because walmart isn't sufficent, walmart can't do everything. particularly, walmart can be in every small town.
I'm just kind of rambling at this point so I'll bring this to a close. SOPA and PIPA, they are backwards and narrow sited. the DRM problem with video games will cease to exist when all video games are just stored on the cloud. Do I think that that is what's going to happen? Probably, I'm not 100% certain, but it certainly seems like it is probable. And guess what happens when everything is stored in the cloud? You can't pirate it.
Thursday, January 12, 2012
Generic Asset Editor
I had an idea a while back that it would be nice if you could have one program that you use for all of your asset creation. one program you can use for pictures, sound, models, etc.. Now, obviously, if doing such was an easy endevour, it would have been done long ago. But nothing has really come close to being an editor like that. its hard, think about all the things blender has in it and it can manipulate only a small set of what is needed to make a game.
So I stopped, and I thought "what does an editor do?" and put as simple as it possibly could be, an editor reads a file, changes values, and writes a file. That is as simple as it comes. Looking at blender's node system for compositing, I thought "what if an editor could work this way?" meaning, instead of making a tool that can edit all sorts of things and then having to add functionality for each new type of file, why not make a program that can't edit anything, but can be made to edit everything?
Like blender's nodes, there would be inputs and outputs from a node. what the node actually does is entirely liquid. inside a node there would just simply python code. so image a file reader node. it takes a file name as its input and a string as its output. you can make a decoder node that reads from a file and translates the values into variables that you can work with in other nodes.
Now, this is all good but there is one peice that remains for this to make sense. Editor nodes. These are nodes that the user would have to create using a UI painter inside of this editor which could be made to edit anything. This node I'm still not entirely sure of how its made, but the idea is compelling. One of the things I see having a huge potential here is pipelines. where you want to work on one asset, or group of assets, but you open them up and the pipe line runs until it hits an editor node.
Its a rough idea that I'll probably post more about later. but for now sleep.
So I stopped, and I thought "what does an editor do?" and put as simple as it possibly could be, an editor reads a file, changes values, and writes a file. That is as simple as it comes. Looking at blender's node system for compositing, I thought "what if an editor could work this way?" meaning, instead of making a tool that can edit all sorts of things and then having to add functionality for each new type of file, why not make a program that can't edit anything, but can be made to edit everything?
Like blender's nodes, there would be inputs and outputs from a node. what the node actually does is entirely liquid. inside a node there would just simply python code. so image a file reader node. it takes a file name as its input and a string as its output. you can make a decoder node that reads from a file and translates the values into variables that you can work with in other nodes.
Now, this is all good but there is one peice that remains for this to make sense. Editor nodes. These are nodes that the user would have to create using a UI painter inside of this editor which could be made to edit anything. This node I'm still not entirely sure of how its made, but the idea is compelling. One of the things I see having a huge potential here is pipelines. where you want to work on one asset, or group of assets, but you open them up and the pipe line runs until it hits an editor node.
Its a rough idea that I'll probably post more about later. but for now sleep.
Wednesday, January 4, 2012
The Process Pt.2
So I've spend the last 2 hours writing down everything I can think of in terms of how the library should work. Its proven to be incredibly insightful. I now actually know what I'm building. I wanted to comment to a revision in my little methodology as I realized I have left something out:
1. Think of every of all the common uses of your program. what is the intended uses? Write down what those uses need. Now, with the time you have left, abuse it. What are some of the edge cases you can think of for your program? what might be some of the un-intended yet still very viable uses of your program? How can you accomidate for these to keep your program robust? or how can you prevent these uses if they are security or performance pitfalls?
2. Pretend that your program is down. write down some examples of using it. Describe its behavior. What are the characteristics of the implementation. If you think of any further needs while you are doing this, jump back to step one and add them in.
3. Figure out what are the atomic peices. What is it impossible to cut any smaller? start building your architecture there. don't be specific in how these peices are made, just describe them. start putting the peices together to make ever larger peices until you've encompassed everything.
4. Test Driven Development goes here:
a. write a test that checks for one of the needs from step 1.
b. run the test. if it passes, go back to step 3.a.
c. write code to satisfy that test.
d. run all tests. if any fail, step back to step 3.c.
e. clean up your code and repeat untill all requirements listed from step one are being tested for.
5. take a break.
On to step 3!
1. Think of every of all the common uses of your program. what is the intended uses? Write down what those uses need. Now, with the time you have left, abuse it. What are some of the edge cases you can think of for your program? what might be some of the un-intended yet still very viable uses of your program? How can you accomidate for these to keep your program robust? or how can you prevent these uses if they are security or performance pitfalls?
2. Pretend that your program is down. write down some examples of using it. Describe its behavior. What are the characteristics of the implementation. If you think of any further needs while you are doing this, jump back to step one and add them in.
3. Figure out what are the atomic peices. What is it impossible to cut any smaller? start building your architecture there. don't be specific in how these peices are made, just describe them. start putting the peices together to make ever larger peices until you've encompassed everything.
4. Test Driven Development goes here:
a. write a test that checks for one of the needs from step 1.
b. run the test. if it passes, go back to step 3.a.
c. write code to satisfy that test.
d. run all tests. if any fail, step back to step 3.c.
e. clean up your code and repeat untill all requirements listed from step one are being tested for.
5. take a break.
On to step 3!
The Process
Figures that this comes right after I posted about Test Driven Development. I'm starting a new project today, its rather a classic type of program, I'm making a concurency library. So I'll be making a lot of base classes and very testable units. I'm taking this project as a chance to walk through the whole development process. I'm going to give a little over view of it here:
Requirements - Determining the needs or conditions to be meet.
Specification - The documentation that describes the requested behavior of the system.
Architecture - the set of structures needed to reason about a system. The software elements, relations among them, and properties of both.
Design - the process of problem solving and planning for a software solution.
Implementation - the actual process of writing code and debugging. what we typically think about when we think about coding.
Testing - Running automatic tests, manual test, and anything else that can be used to varify that it meets requirements, works as expected, and can be implemented with the same characteristics.
Deployment - All that is done to make the software available for use. executables, zip files, web sites, etc..
Maintenance - modification of a product after delivery. basically Implementation after Deployment.
Mythical Man Month, be it 40 years old, has a word to say on this topic. Particularly the balance of these 8 items. the first 2 we will categorize into pre-production. the second 2 into design. 3rd 2 into Development. and last 2 into maintenance. According to MM-M, the first 2 should take 25% of your time each! that means you will spend half of your time on this project just simply preparing to write the program and won't actually write a single line of code. I know that sounds strange, if I was a construction work and told my boss I need to stpend half of the time just preparing for the project, I'd be fired. But the thing is, Construction projects do spend a large amount of time in preparation, its just that by the time it gets to the construction worker, all of the preparation is complete. it isn't a very good analogy as construction tends to speend far more time in production than preperation compared to software development, but my point remains. You need to spend a lot of time planing and designing, it will actually save you time in the long run.
The 3rd category, Development, will win exactly 1/6th of the time on your project. Yea, again, tiny. The reason being is that by the time you get here, you will know so well exactly what you need to do that you will sit down and just write out code at a frightening pace. You won't have to go back and rework things as much because you'll get it write the first time. you'll spend less time thinking about what needs to be writen as you know exactly what needs to be written already.
The 4th category gets the remaining 1/3 of your time, maintenance. The good thing about this though is that you will have spent so much time carefully writing designs and specifications that maintenence won't be the horrific nightmare we all know. You'll have every detail marked out and batteries of tests to keep everything in tip top shape.
That's the breif summary of the process, now on to my actual attempt at it!
I know I won't finish this library in the time I am home. That's ok, but because of that I am going to cut some of those time frames a little short because I want to fit this all into a day and I know I'm not going to write this all in a single day. So I'm alotting 2 hours pre-production, 2 hours for design, and then 2 hours for deveopment. I don't really have a deployment or maintenance, so I'm not going to concern myself with that.
I've read over a couple of programing methodologies, and I get the feeling that people are far to focused. a lot of the methodologies, iterative, TDD, really are just focusing on the imlementation step. Agile, Scrum, waterfall, and the like however focus on the entire system as a whole. To each their own, I know that a lot of these work and they all have their advantages. But they are also focused on large projects with multiple people. For example, I'm not going to have a stand up meeting with myself. So I'm not using agile. This is what I plan on doing, introducing! the Littlefoot methodology:
1. Think of every of all the common uses of your program. what is the intended uses? Write down what those uses need. Now, with the time you have left, abuse it. What are some of the edge cases you can think of for your program? what might be some of the un-intended yet still very viable uses of your program? How can you accomidate for these to keep your program robust? or how can you prevent these uses if they are security or performance pitfalls?
2. Pretend that your program is down. write down some examples of using it. Describe its behavior. What are the characteristics of the implementation. If you think of any further needs while you are doing this, jump back to step one and add them in.
3. Test Driven Development goes here:
a. write a test that checks for one of the needs from step 1.
b. run the test. if it passes, go back to step 3.a.
c. write code to satisfy that test.
d. run all tests. if any fail, step back to step 3.c.
e. clean up your code and repeat untill all requirements listed from step one are being tested for.
4. take a break.
I believe in occam's razor. My entire development process can be described in 3 steps. When you actualy write your program, remember that. if there are two ways to accomplish something, the most simple one is the best one. keep programs as simple as you can, modular programing really helps with achieve this.
Alright. I'm going to probably post again later today, But that will be after steps 1 and 2. Time to go ponder in a big cushie chair away from my computer with nothing but a pencil and paper to program with. ^_^
Requirements - Determining the needs or conditions to be meet.
Specification - The documentation that describes the requested behavior of the system.
Architecture - the set of structures needed to reason about a system. The software elements, relations among them, and properties of both.
Design - the process of problem solving and planning for a software solution.
Implementation - the actual process of writing code and debugging. what we typically think about when we think about coding.
Testing - Running automatic tests, manual test, and anything else that can be used to varify that it meets requirements, works as expected, and can be implemented with the same characteristics.
Deployment - All that is done to make the software available for use. executables, zip files, web sites, etc..
Maintenance - modification of a product after delivery. basically Implementation after Deployment.
Mythical Man Month, be it 40 years old, has a word to say on this topic. Particularly the balance of these 8 items. the first 2 we will categorize into pre-production. the second 2 into design. 3rd 2 into Development. and last 2 into maintenance. According to MM-M, the first 2 should take 25% of your time each! that means you will spend half of your time on this project just simply preparing to write the program and won't actually write a single line of code. I know that sounds strange, if I was a construction work and told my boss I need to stpend half of the time just preparing for the project, I'd be fired. But the thing is, Construction projects do spend a large amount of time in preparation, its just that by the time it gets to the construction worker, all of the preparation is complete. it isn't a very good analogy as construction tends to speend far more time in production than preperation compared to software development, but my point remains. You need to spend a lot of time planing and designing, it will actually save you time in the long run.
The 3rd category, Development, will win exactly 1/6th of the time on your project. Yea, again, tiny. The reason being is that by the time you get here, you will know so well exactly what you need to do that you will sit down and just write out code at a frightening pace. You won't have to go back and rework things as much because you'll get it write the first time. you'll spend less time thinking about what needs to be writen as you know exactly what needs to be written already.
The 4th category gets the remaining 1/3 of your time, maintenance. The good thing about this though is that you will have spent so much time carefully writing designs and specifications that maintenence won't be the horrific nightmare we all know. You'll have every detail marked out and batteries of tests to keep everything in tip top shape.
That's the breif summary of the process, now on to my actual attempt at it!
I know I won't finish this library in the time I am home. That's ok, but because of that I am going to cut some of those time frames a little short because I want to fit this all into a day and I know I'm not going to write this all in a single day. So I'm alotting 2 hours pre-production, 2 hours for design, and then 2 hours for deveopment. I don't really have a deployment or maintenance, so I'm not going to concern myself with that.
I've read over a couple of programing methodologies, and I get the feeling that people are far to focused. a lot of the methodologies, iterative, TDD, really are just focusing on the imlementation step. Agile, Scrum, waterfall, and the like however focus on the entire system as a whole. To each their own, I know that a lot of these work and they all have their advantages. But they are also focused on large projects with multiple people. For example, I'm not going to have a stand up meeting with myself. So I'm not using agile. This is what I plan on doing, introducing! the Littlefoot methodology:
1. Think of every of all the common uses of your program. what is the intended uses? Write down what those uses need. Now, with the time you have left, abuse it. What are some of the edge cases you can think of for your program? what might be some of the un-intended yet still very viable uses of your program? How can you accomidate for these to keep your program robust? or how can you prevent these uses if they are security or performance pitfalls?
2. Pretend that your program is down. write down some examples of using it. Describe its behavior. What are the characteristics of the implementation. If you think of any further needs while you are doing this, jump back to step one and add them in.
3. Test Driven Development goes here:
a. write a test that checks for one of the needs from step 1.
b. run the test. if it passes, go back to step 3.a.
c. write code to satisfy that test.
d. run all tests. if any fail, step back to step 3.c.
e. clean up your code and repeat untill all requirements listed from step one are being tested for.
4. take a break.
I believe in occam's razor. My entire development process can be described in 3 steps. When you actualy write your program, remember that. if there are two ways to accomplish something, the most simple one is the best one. keep programs as simple as you can, modular programing really helps with achieve this.
Alright. I'm going to probably post again later today, But that will be after steps 1 and 2. Time to go ponder in a big cushie chair away from my computer with nothing but a pencil and paper to program with. ^_^
Monday, January 2, 2012
Test Driven Development
Test Driven Development, or TDD. Its hailed as one of the best approaches to programing. not many people truely enjoy doing it, but the results can't be argued with.
I've shifted gears from Delta for a little bit. I'm working on a project I've been making for a prof at school. Ceranubis, a distributed processing program. I've tried several times to do test driven development for it, but I've never seemed to get it to work the way I want. Ceranubis deals a lot with networking, and it is hard to make a test class for a class that deals with networking. That's when what should have been obvious final struck me, test driven development should be used in only certain cases, and not in others.
Lets reason through this idea. What does test driven development do?
1. Accuracy first and alwasy: Test driven development allows programers to think only once of the edge cases of a program. You program the whole possible range of input for a class into the test class, you then proceed to work out by hand what the results /should/ be. When you know what they should be, you can then run your test class and see if the class your testing is giving the same results. this ensures program accuracy under all conditions. if you go back and change something and it breaks one of the tests, then you know right away that you broke something and you won't have to spend hours later trying to find the bug. this improves code maintainability and stability during growth.
2. Clearity of design: TDD forces programers to think at least once about all edge cases of a program. This means that when the programer actually goes about writing the program, he has a much clearer idea of what the class is supposed to do. I found that when I was doing the TDD that my data structures teacher required, I would look at the provided tests to get an idea of what I was supposed to be doing.
These are all good things, but what does TDD not do?
1. Test large systems: could you make unit tests for an entire application? not likely. TDD is limited to testing the functionality of base classes. high level classes and the entire application tend to have far to many variables to be accounted for in a test, trying to do so will lead to huge over bearing tests that take far to much time to program and you'd be better off debugging by hand.
2. Test libraries to lower level systems: This, again, is mostly due to the large number of variables, but there's more. This is the one that really got me, how do you make a test for a class that interfaces with networking or threading? Not saying it can't be done, but the complexities are daunting. Aside from the fact that most of the problems that could occur in this class you'll probably be handling at run-time anyway. If the thread fails to start, if the network socket fails to bind, those are probably not logic errors as much as they are things like "the port is in use". One of my difficulties with the TDD on my network class is that exactly, everything that could be wrong with the class is handled at run time. and you say "well, don't you want to know that the exception handling is going to work correctly?" yes, of course i do. What I don't want to do is spend large amounts of my time writing test that recreates the entire enviorment of my system and then ensuring that that test itself is accurate. I know you should spend time writing tests, they are supposed to be about 50% of your development time. but that is just a bit ridiculous. i would be spending way more time than debugging by hand would take, and this is one case where debugging by hand might even get more accurate results.
What are the pros of TDD?:
1. Dependable code
2. Clearity of design
3. Makes is easier for more than one programer to work together.
4. Catches most edge cases
What are the cons of TDD?:
1. Extra time spent writing tests.
2. You have to know your design before you can write tests.
3. Passing lots of tests may give you a false sense of security.
4. Should the test writter miss an edge case, then you loose your dependability.
So where should TDD be used?:
low level systems and base classes. Things that are entirely self contained. Data structures, parsers, and the like.
Where should TDD not be used?:
high level systems nad entire programs. Things that have lots of variables and a lot of interconectivity.
I've shifted gears from Delta for a little bit. I'm working on a project I've been making for a prof at school. Ceranubis, a distributed processing program. I've tried several times to do test driven development for it, but I've never seemed to get it to work the way I want. Ceranubis deals a lot with networking, and it is hard to make a test class for a class that deals with networking. That's when what should have been obvious final struck me, test driven development should be used in only certain cases, and not in others.
Lets reason through this idea. What does test driven development do?
1. Accuracy first and alwasy: Test driven development allows programers to think only once of the edge cases of a program. You program the whole possible range of input for a class into the test class, you then proceed to work out by hand what the results /should/ be. When you know what they should be, you can then run your test class and see if the class your testing is giving the same results. this ensures program accuracy under all conditions. if you go back and change something and it breaks one of the tests, then you know right away that you broke something and you won't have to spend hours later trying to find the bug. this improves code maintainability and stability during growth.
2. Clearity of design: TDD forces programers to think at least once about all edge cases of a program. This means that when the programer actually goes about writing the program, he has a much clearer idea of what the class is supposed to do. I found that when I was doing the TDD that my data structures teacher required, I would look at the provided tests to get an idea of what I was supposed to be doing.
These are all good things, but what does TDD not do?
1. Test large systems: could you make unit tests for an entire application? not likely. TDD is limited to testing the functionality of base classes. high level classes and the entire application tend to have far to many variables to be accounted for in a test, trying to do so will lead to huge over bearing tests that take far to much time to program and you'd be better off debugging by hand.
2. Test libraries to lower level systems: This, again, is mostly due to the large number of variables, but there's more. This is the one that really got me, how do you make a test for a class that interfaces with networking or threading? Not saying it can't be done, but the complexities are daunting. Aside from the fact that most of the problems that could occur in this class you'll probably be handling at run-time anyway. If the thread fails to start, if the network socket fails to bind, those are probably not logic errors as much as they are things like "the port is in use". One of my difficulties with the TDD on my network class is that exactly, everything that could be wrong with the class is handled at run time. and you say "well, don't you want to know that the exception handling is going to work correctly?" yes, of course i do. What I don't want to do is spend large amounts of my time writing test that recreates the entire enviorment of my system and then ensuring that that test itself is accurate. I know you should spend time writing tests, they are supposed to be about 50% of your development time. but that is just a bit ridiculous. i would be spending way more time than debugging by hand would take, and this is one case where debugging by hand might even get more accurate results.
What are the pros of TDD?:
1. Dependable code
2. Clearity of design
3. Makes is easier for more than one programer to work together.
4. Catches most edge cases
What are the cons of TDD?:
1. Extra time spent writing tests.
2. You have to know your design before you can write tests.
3. Passing lots of tests may give you a false sense of security.
4. Should the test writter miss an edge case, then you loose your dependability.
So where should TDD be used?:
low level systems and base classes. Things that are entirely self contained. Data structures, parsers, and the like.
Where should TDD not be used?:
high level systems nad entire programs. Things that have lots of variables and a lot of interconectivity.
Subscribe to:
Posts (Atom)