Looking for programming techniques
I was wondering what program techniques people use to improve their code quality. I've been programming for a while now but I never really learned any code construction techniques. I got a book called Code Completion which seemed to help me. However, I was wondering what techniques others use. Here's what I currently do.
I write a top down design diagramming subprojects, followed by subproject classes, then subproject class methods.
I create skeleton methods initially which only return static results. I then go through the methods one at a time writing the real code.
I design my modules using program design language (PDL) which is similar to pseudocode. I design the methods in detail at a high language. The PDL acts as my comments for the program later on.
I use asserts in my code to crash the program (during development) in case a condition brings out strange events.
I just started using JUnit to do unit testing on the program.
I run my code through my debugger monitoring variables.
I currently don't use any UML to design my code. I'm wondering what other techniques other people use. Is there any techniques you think I should be utilizing. Any other ideas I can use. Hell, I just started using unit testing, which is awesome, so I'm wondering what else I should use.
Listen to your gut feeling and refactor often :)
kajbja at 2007-7-10 11:58:14 >
take your junit practices to the extreme. write the [url= http://en.wikipedia.org/wiki/Test-driven_development]tests first.[/url]
You wrote a lot about testing, which is great, but sometimes a good design
gives your code "good bones" to build on. If your design is crufty, then
you're going to struggle with it, and that stress is going to introduce problems.
Design Patterns and Refactoring!
http://en.wikipedia.org/wiki/Design_Patterns
http://en.wikipedia.org/wiki/Refactoring
I like the idea of a test-driven development approach and I can see how it's beneficial. Another thing I wanted to start implementing was utilizing interfaces a lot more in my code to define public methods in each class. This way if I write a replacement class later on I have a detailed list of exactly what I need to define in the new code so I don't break the old code.
> I like the idea of a test-driven development approach
> and I can see how it's beneficial. Another thing I
> wanted to start implementing was utilizing interfaces
> a lot more in my code to define public methods in
> each class. This way if I write a replacement class
> later on I have a detailed list of exactly what I
> need to define in the new code so I don't break the
> old code.
This might sound a bit harsh, but that isn't my intention.
It sounds like you are doing something that is total overkill (and that is something which I often see in your questions if I remember it correctly). I think you would benefit a lot by doing less design and mumbo jumbo and rely on refactoring. Don't do things that you might need in the future.
Kaj
kajbja at 2007-7-10 11:58:14 >
> > I like the idea of a test-driven development
> approach
> > and I can see how it's beneficial. Another thing
> I
> > wanted to start implementing was utilizing
> interfaces
> > a lot more in my code to define public methods in
> > each class. This way if I write a replacement
> class
> > later on I have a detailed list of exactly what I
> > need to define in the new code so I don't break
> the
> > old code.
>
> This might sound a bit harsh, but that isn't my
> intention.
>
> It sounds like you are doing something that is total
> overkill (and that is something which I often see in
> your questions if I remember it correctly). I think
> you would benefit a lot by doing less design and
> mumbo jumbo and rely on refactoring. Don't do things
> that you might need in the future.
>
> Kaj
I agree. keep both the KISS and YAGNI principles in mind (google 'em if you need to)
I was asked in an interview when I knew I'd done enough designing to start coding. "when I get itchy fingers" was universally accepted
i just googled YAGNI and the site I read had a varianton the Twisted Sister song...You Aint Gonna Need It!No! You AInt Gonna Need It!
ah, twisted sister :-) bless 'em
> I agree. keep both the KISS and YAGNI principles in
> mind (google 'em if you need to)
KISS and YAGNI are my best friends. I just love them :)
@Op.
You will later on when you are more experienced look back at this time and they "OMG what were I doing". That happens to all developers.
I do less analysis and design models these days because I usually can rely on experience. Design models can be good if you need to communicate your design to others, but don't overdo it.
kajbja at 2007-7-10 11:58:14 >
I found these books to be very useful. they all changed the way I write code forever (I've missed out the obvious XP books - I'm not an XP preacher!)
http://www.amazon.co.uk/Agile-Software-Development-Through-People/dp/0201699699
http://www.amazon.co.uk/Pragmatic-Programmer-Andrew-Hunt/dp/020161622X/ref=sr_1_2/202-1699822-2097455?ie=UTF8&s=books&qid=1174663254&sr=1-2
http://www.amazon.co.uk/Better-Faster-Lighter-Java-Bruce/dp/0596006764/ref=sr_1_1/202-1699822-2097455?ie=UTF8&s=books&qid=1174663270&sr=1-1
http://www.amazon.co.uk/Test-Driven-Development-Practical-Guide/dp/0131016490/ref=sr_1_3/202-1699822-2097455?ie=UTF8&s=books&qid=1174663286&sr=1-3
I like the refactoring concept and I will utilize it in the future. I do to a point already. I don't think most of my techniques are really overkill. In the past I've written apps that I've had to change (which broke the old code) far too many times. I've also designed as I went which caused a lot of headaches when I decided to add a new feature. That's why I'm trying to design ahead of time anymore. When you're at a higher level it's easier to follow process flow and notice mistakes. In the past, I spent too much time trying to track down small bugs that with asserts and unit tests I would've caught much easier and quicker. I wanted quality comments because in the past, when I've spent too much time away from a project, I would come back to it and try to figure out why I did something I did.
I've read in the past that everything is in the preparation. Rushing to code will get you coding faster but it might cause you more work in the long run. That's my opinion though based on my past experience.
> I like the refactoring concept and I will utilize it
> in the future. I do to a point already. I don't
> think most of my techniques are really overkill. In
> the past I've written apps that I've had to change
> (which broke the old code) far too many times. I've
> also designed as I went which caused a lot of
> headaches when I decided to add a new feature.
> That's why I'm trying to design ahead of time
> anymore. When you're at a higher level it's easier
> to follow process flow and notice mistakes. In the
> past, I spent too much time trying to track down
> small bugs that with asserts and unit tests I
> would've caught much easier and quicker. I wanted
> quality comments because in the past, when I've
> spent too much time away from a project, I would
> come back to it and try to figure out why I did
> something I did.
>
> I've read in the past that everything is in the
> preparation. Rushing to code will get you coding
> faster but it might cause you more work in the long
> run. That's my opinion though based on my past
> experience.
what's the point in all that preparation up-front if the requirements are just going to change? all requirements change, every project suffers from that. second-guessing what those changes will be is generally a waste of effort, at best. agility isn't merely "rushing into coding", a mistaken assumption a lot of people make
I really really strongly suggest you read the Cockburn book I linked to above
[quote=kajbj]This might sound a bit harsh, but that isn't my intention. [/quote]
I know it wasn't your intention it just made me think about it because your designing a structure (in a fashion) with test driven development that the code has to accommodate. Interfaces are basically structures that the code has to accommodate. That's what made me think of it!
[quote=kajbj]Don't do things that you might need in the future.[/quote]
I take it your a fan of extreme programming.
> [quote=kajbj]This might sound a bit harsh, but that
> isn't my intention. [/quote]
>
> I know it wasn't your intention it just made me think
> about it because your designing a structure (in a
> fashion) with test driven development that the code
> has to accommodate. Interfaces are basically
> structures that the code has to accommodate. That's
> what made me think of it!
I doubt he was condeming your use of interfaces. a sound design idea just don't overdo it and give every class an interface (it happens)
> I got a book called Code Completion which seemed to help me.
If you meant to say this book, ignore me, but there is a book called "Code Complete", that is absolutely excellent.
http://www.amazon.co.uk/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_1/202-0356462-4353436?ie=UTF8&s=books&qid=1174670019&sr=8-1
> I like the refactoring concept and I will utilize it
> in the future. I do to a point already. I don't
> think most of my techniques are really overkill.
They are if you always follow them. What you described in your first post is overkill in most circumstances.
> In the past I've written apps that I've had to change
> (which broke the old code) far too many times.
I have been where you are, and my experience says that you can't design a system that can stand all changes over time. You will always have to change your design because of new requirement or features that can't fit into your design.
> I've also designed as I went which caused a lot of
> headaches when I decided to add a new feature.
You should of course think ahead and create a very rough sketch of what the system must be able to do. You do also need to communicate that sketch to all project members.
> That's why I'm trying to design ahead of time
> anymore. When you're at a higher level it's easier
> to follow process flow and notice mistakes.
You only need to do that if you haven't implemented something similar before.
> In the past, I spent too much time trying to track down
> small bugs that with asserts and unit tests I
> would've caught much easier and quicker.
You should still create JUnit tests. I'm not against that.
> I wanted
> quality comments because in the past, when I've
> spent too much time away from a project, I would
> come back to it and try to figure out why I did
> something I did.
I actually think that my comments have at least a bit of quality. I've been programming in different languages for more than 20 years and I've read lots and lots of books, and seen many different designs and systems. There are actually only a few different design concepts behind most systems, and you can usually list the major drawbacks and benefits of a system with only a rough description of the system. (If you know about that type of system)
> I've read in the past that everything is in the
> preparation.
I have word. Bullshit.
You need to be agile and you can't prepare for future requirement changes. Refactoring and common sense (KISS, YAGNI, design pattern, architectural patterns etc) is what you need.
> Rushing to code will get you coding
> faster but it might cause you more work in the long
> run.
I haven't said that you should rush into coding. Create a very rough sketch (you can create it in your mind or write it down if you want to). Discuss the design, and try to list the major benefits and drawbacks (you don't have to write them down). Then try to create a small prototype where you implement those things that you think might be hard to implement.
Kaj
kajbja at 2007-7-21 19:11:36 >
> [quote=kajbj]This might sound a bit harsh, but that
> isn't my intention. [/quote]
>
> I know it wasn't your intention it just made me think
> about it because your designing a structure (in a
> fashion) with test driven development that the code
> has to accommodate. Interfaces are basically
> structures that the code has to accommodate. That's
> what made me think of it!
I often use interfaces but I don't create them from the beginning. Why? Because it's very easy to create an interface later on when you have two classes with a common behaviour. The same applies to base classes. Why create an interface or base class when you don't know if you will need it in the future? What you think is one interface might actually be several interfaces etc.
>
> [quote=kajbj]Don't do things that you might need in
> the future.[/quote]
>
> I take it your a fan of extreme programming.
I'm not a big fan of it, but I like it. I do also like Agile programming and lots of other methologies.
Kaj
kajbja at 2007-7-21 19:11:36 >
I don't think interfaces for every class are overdoing it. I look at them like document type definitions (DTD) for XML. It's a way to enforce data integrity. In this case it enforces class integrity. Designing an interface does not take long and in most IDEs if you implement an interface the IDE will ask you if you want to import the methods, if they're missing. Time wise it doesn't really take any extra time. After you write the interface providing the class adheres to it you know the class will have no problems communicating with the rest of the program. This makes it easier to add new classes later if you want to override the older ones and makes it much easier to use a modular design later.
Kaj, didn't mean anything negative by my post so I hope you didn't take it that way. I'm just trying to build strong, stable code I can build off. I agree no system can avoid change but the best you can do is write your code in a way that can accept changes easily without breaking the old system. Design will help you there. I don't work in the corporate world. Most of my projects are worked on and designed by me so I really don't need to worry about constant change. My goal with a top down design is I can work in stages. When I'm writing code all I have to worry about is making the method on hand do what it's supposed to do. When I'm working at the design level I can see everything from a bird's eye perspective which will make it easier to see pitfalls and also give me easy to read through references to what I was doing with the project later.
I meant Code Complete. Unfortunately, I only have the 1st edition of the book. I plan to get the 2nd edition later. It's one of the most useful computer books I ever got.
> I don't think interfaces for every class are
> overdoing it. I look at them like document type
> definitions (DTD) for XML. It's a way to enforce
> data integrity. In this case it enforces class
> integrity. Designing an interface does not take long
> and in most IDEs if you implement an interface the
> IDE will ask you if you want to import the methods,
> if they're missing. Time wise it doesn't really take
> any extra time. After you write the interface
> providing the class adheres to it you know the class
> will have no problems communicating with the rest of
> the program. This makes it easier to add new classes
> later if you want to override the older ones and
> makes it much easier to use a modular design later.
I'd say having every class implement an interface is definately overkill. again, it's extra work you don't need to do, for one thing. time wasting isn't really the problem, the problem is it means you're not thinking about your domain model, just applying a principle without understanding it fully. for instance, under what circumstances would an interface benefit a Money class? the Money class exists to abstract us from change - exchange rates, largely - I don't see any benefit in "allowing" yourself multiple implementations of that. an unneccesary complication if you ask me. Peter Coad would agree, it seems, in [url=http://www.amazon.co.uk/Java-Design-Building-Applets-Computing/dp/0139111816/ref=sr_1_9/202-3726981-2659065?ie=UTF8&s=books&qid=1174727494&sr=8-9]Jav a Design[/url], one of the first books to suggest the notion of using interfaces the way we do, and still fresh today. also, what about classes with only static methods? there isn't any syntax for defining an interface for them
> After you write the interface providing the class adheres to it you know the class will have no problems communicating with the rest of the program
isn't that also true of classes, though? don't get me wrong, I'm a big advocate of coding to interfaces, and often have arguments at work about this, but it's definately not necessary to define an interface for every class.
> > [quote=kajbj]This might sound a bit harsh, but
> that
> > isn't my intention. [/quote]
> >
> > I know it wasn't your intention it just made me
> think
> > about it because your designing a structure (in a
> > fashion) with test driven development that the
> code
> > has to accommodate. Interfaces are basically
> > structures that the code has to accommodate.
> That's
> what made me think of it!
>
> I often use interfaces but I don't create them from
> the beginning. Why? Because it's very easy to create
> an interface later on when you have two classes with
> a common behaviour. The same applies to base classes.
> Why create an interface or base class when you don't
> know if you will need it in the future? What you
> think is one interface might actually be several
> interfaces etc.
>
> >
> > [quote=kajbj]Don't do things that you might need
> in
> > the future.[/quote]
> >
> > I take it your a fan of extreme programming.
>
> I'm not a big fan of it, but I like it. I do also
> like Agile programming and lots of other methologies.
>
>
> Kaj
I'm supposedly in an XP team now, but it's not really working. the problem I'm seeing now is that the assumption is, if you follow XP, your code is automatically better. it isn't. there are teams-within-The-Team who follow much of the ceremony of XP religiously, with daily standups, end-of-iteration reviews at the right time, planning games and the like, but many of the developers simply aren't particularly good coders, and no amount of process is going to compensate for that. because they're not great at coding, we're finding - by accident - a lot of really dodgy code, with logic leaking between layers everywhere, unwieldy inheritance hierarchies (do we really need 11 classes called PrintFormController) and - worse - the unit tests for that code being commented out because they "couldn't get the tests to work". but because that team is visibly following XP, nobody says anything
> I don't think interfaces for every class are
> overdoing it.
I agree that having an interace for each class isn't overdoing it. It's, just plain wrong.
Each line of code and every class and interface communicates something to other developers. What do you communicate with all of your interfaces? Having an interface for each class does actually make it harder to navigate your code base and understand your design.
Just take a look at the classes in JSE or in any framework or application. Have you ever seen another application that has an interface for each class? What do you think is the reason that you haven't seen it?
The answer is not that the developers were lazy.
Kaj
kajbja at 2007-7-21 19:11:36 >
> I'm supposedly in an XP team now, but it's not really
> working. the problem I'm seeing now is that the
> assumption is, if you follow XP, your code is
> automatically better.
>it isn't.
I agree
> there are
> teams-within-The-Team who follow much of the ceremony
> of XP religiously, with daily standups,
> end-of-iteration reviews at the right time, planning
> games and the like, but many of the developers simply
> aren't particularly good coders, and no amount of
> process is going to compensate for that.
Correct but pair programming with a good developer might help them to become better.
> because
> they're not great at coding, we're finding - by
> accident - a lot of really dodgy code, with
> logic leaking between layers everywhere, unwieldy
> inheritance hierarchies (do we really need 11 classes
> called PrintFormController) and - worse - the unit
> tests for that code being commented out because they
> "couldn't get the tests to work".
Did they write the tests before they wrote the code?
> but because that
> team is visibly following XP, nobody says anything
Someone should.
Kaj
kajbja at 2007-7-21 19:11:36 >
> > I'm supposedly in an XP team now, but it's not
> really
> > working. the problem I'm seeing now is that the
> > assumption is, if you follow XP, your code is
> > automatically better.
> >it isn't.
>
> I agree
>
> > there are
> > teams-within-The-Team who follow much of the
> ceremony
> > of XP religiously, with daily standups,
> > end-of-iteration reviews at the right time,
> planning
> > games and the like, but many of the developers
> simply
> > aren't particularly good coders, and no amount of
> > process is going to compensate for that.
>
> Correct but pair programming with a good developer
> might help them to become better.
>
> > because
> > they're not great at coding, we're finding - by
> > accident - a lot of really dodgy code, with
> > logic leaking between layers everywhere, unwieldy
> > inheritance hierarchies (do we really need 11
> classes
> > called PrintFormController) and - worse - the
> unit
> > tests for that code being commented out because
> they
> > "couldn't get the tests to work".
>
> Did they write the tests before they wrote the code?
doubtful
> > but because that
> > team is visibly following XP, nobody says anything
>
> Someone should.
have done, many times. nobody listens. all these guys are contractors, and seen as more proficient because of it. also, the team is about 80% natives of a certain outsource-happy country, and stick very much together. the project has far deeper problems than what I've outlined above, and I'm not at all invested in it any more, just taking the pay cheques til I've got enough of a cash safety-net to quit and either go contracting, or take my time finding something more suitable. in the meantime, a little of my soul dies each shortcut I let management force me to take :-(
OK, having interfaces for every class isn't necessary and it is overkill. I do like them though.
Yeah, I haven't done any "Extreme Programming" yet, but from what I read I don't care for the concepts (except for test-driven code with lots of small unit tests). I'm big on modular design and writing the classes very well the first time so you don't have to worry about it again unless I need to add a feature. This idea of writing code just enough so it passes the developer's condition just seems like a bad idea. I can understand building your program as a skeleton around this to get everything in order and to give the client time to suggest changes before the big stuff needs to get done, but from what I gathered XP believes in allowing changes up until the deadline and not designing their code to be resilient to changes that can come up tomorrow.
> Yeah, I haven't done any "Extreme Programming" yet,
> but from what I read I don't care for the concepts
> (except for test-driven code with lots of small unit
> tests). I'm big on modular design and writing the
> classes very well the first time so you don't have to
> worry about it again unless I need to add a feature.
This is where you waste a lot of time in that case. Why e.g implement a dialog so that it can be resized, printed and everything else when you a few days later notice that you don't need the class at all.
Kaj
kajbja at 2007-7-21 19:11:36 >
When I write classes I want them to be high grade and very modular. If I wrote a dialog that can be resized, printed, etc. I would design it in a way so that it would be highly modular and I can trust it works very well. If I needed to do something specific for the program with it I'd subclass it. This way if I needed to do something like it in the future I can store it away for later. It might be more work now but I have a quality class for the future. Plus if I implement an old class I wrote before into my program I can cut down the time in writing another class for the program which can offshoot the time developing another high quality modular class. If you design classes to do the minimum of what you need I would think they wouldn't be very practical to reuse in the future since you probably have to do a lot of work to make sure they work right in the new project.
You said why put the work into a class if days later you notice you didn't need it. Well, to me if you designed it well from the beginning you should notice you didn't need it before you started programming. If you're accepting ideas till deadline then it seems like your opening yourself up for problems. I believe the extreme programming concepts are good to a point. Shooting out bare essential code and getting constant feedback is a good idea. You can find out how well your program works and whether it needs to be changed without heavy time put in. Consumers can see how your program performs before a lot of work goes into it which is great for getting feedback and ideas. However, I believe this should be combined with standard principles of accepting input and changes up until a specific date and then trying to make the classes complete and highly functional for reusability. That's my opinion though.
> When I write classes I want them to be high grade and
> very modular.
Quality is important to me. And I think of it all the time. A class that isn't feature complete doesn't need to be bad.
> If I wrote a dialog that can be
> resized, printed, etc. I would design it in a way so
> that it would be highly modular and I can trust it
> works very well.
Same here, I would create one that work well, but only for that project.
> If I needed to do something
> specific for the program with it I'd subclass it.
> This way if I needed to do something like it in the
> future I can store it away for later. It might be
> more work now but I have a quality class for the
> future. Plus if I implement an old class I wrote
> before into my program I can cut down the time in
> writing another class for the program which can
> offshoot the time developing another high quality
> modular class. If you design classes to do the
> minimum of what you need I would think they wouldn't
> be very practical to reuse in the future since you
> probably have to do a lot of work to make sure they
> work right in the new project.
No. My code is still modular, just not feature complete. I do still reuse code, but I add the stuff that I need when I need it.
> You said why put the work into a class if days later
> you notice you didn't need it. Well, to me if you
> designed it well from the beginning you should notice
> you didn't need it before you started programming.
No.
I don't know how long your projects are. The projects that I'm involved in are usually longer than 1-2 years. You can't design such large applications/systems in such detail that you know what classes you will need.
> If you're accepting ideas till deadline then it
> seems like your opening yourself up for problems.
I don't
>I believe the extreme programming concepts are good to
> a point. Shooting out bare essential code and
> getting constant feedback is a good idea. You can
> find out how well your program works and whether it
> needs to be changed without heavy time put in.
> Consumers can see how your program performs before
> a lot of work goes into it which is great for
> getting feedback and ideas. However, I believe this
> should be combined with standard principles of
> accepting input and changes up until a specific date
I partly agree. We work in iterations, and we accept new requirements in the beginning of each iteration. A new requirement after that means that we might have to move the release for that iteration.
> and then trying to make the classes complete and
> highly functional for reusability.
Do what you need when you need it. :)
Kaj
kajbja at 2007-7-21 19:11:36 >
> When I write classes I want them to be high grade and
> very modular. If I wrote a dialog that can be
> resized, printed, etc. I would design it in a way so
> that it would be highly modular and I can trust it
> works very well. If I needed to do something
> specific for the program with it I'd subclass it.
> This way if I needed to do something like it in the
> future I can store it away for later. It might be
> more work now but I have a quality class for the
> future. Plus if I implement an old class I wrote
> before into my program I can cut down the time in
> writing another class for the program which can
> offshoot the time developing another high quality
> modular class. If you design classes to do the
> minimum of what you need I would think they wouldn't
> be very practical to reuse in the future since you
> probably have to do a lot of work to make sure they
> work right in the new project.
>
> You said why put the work into a class if days later
> you notice you didn't need it. Well, to me if you
> designed it well from the beginning you should notice
> you didn't need it before you started programming.
> If you're accepting ideas till deadline then it
> seems like your opening yourself up for problems. I
> believe the extreme programming concepts are good to
> a point. Shooting out bare essential code and
> getting constant feedback is a good idea. You can
> find out how well your program works and whether it
> needs to be changed without heavy time put in.
> Consumers can see how your program performs before
> a lot of work goes into it which is great for
> getting feedback and ideas. However, I believe this
> should be combined with standard principles of
> accepting input and changes up until a specific date
> and then trying to make the classes complete and
> highly functional for reusability. That's my
> opinion though.
the point is, though, that designing everything up-front is just asking for trouble, since the requirements will change. it's all well and good saying "if you design it well from the beginning", but to me, a class that's only doing what is needed, but is written in such a way that adding functionality to it is easy is well-designed. a class full of functionality that may or may not be needed isn't. the discipline is writing code that can be extended easily. also, I'm not alone in thinking that subclassing isn't the solution to code reuse people once thought it was. for a start, extending a class is creating a dependency on a concrete class, and nobody likes that,do they ;-)
kajbj, I do agree with some of your ideas and if I worked on a project that could take 1 to 2 years I think your system would work better for me. However, I develop projects by myself that require a month or two of work (at most) to reach a first release. I tried developing my approach because in the past I tended to add too many features midway and I would constantly end up redefining my program because of it. Also when I talk about completing classes I don't mean adding features the user might never use, I mean bug checking the hell out of it, making it well documented and easy to update if necessary, and making sure the class takes into account for whatever can go wrong. I like to know that if I port the class to another project I can trust the code to perform consistently without unexpected consequences. For example, if I passed data to a method through a drop down menu (in program 1) and I know program 1 will never pass bad data to the method I would still validate the input that was passed to the method because in program 2 I might take raw data where I don't know what could be passed. In project 1 this might be unnecessary but in project 2 it would be. Extreme Programming wouldn't take this into account. However I believe this is easier to do now when it's fresh in my mind then stumbling over it later. This is my definition of a complete class. One that I can put into any project and know it will work all the time. Something that when I have a bug I don't have to even look into that class because I know it's good. Adding features later doesn't make it any less complete.
> Extreme Programming wouldn't take this into> account. I'm not sure about that. What you are describing is usually called being defensive. All programmers should be defensive. Error handling is not something that contradicts XP.
kajbja at 2007-7-21 19:11:41 >
I think this is merely a discussion between Waterfall and an Iterative process. The OP defends a waterfall like development process. From my experience, iterative works better. It detects flaws in design earlier and it most certainly detects misconceptions between customer and developer earlier. If you spend a lot of time designing everything up front, develop everything and then go to your customer, you're bound to come back with a set of changes. There is always a gap between the things a customer wants and what the developer thinks the customer wants.
If you deliver faster, but in smaller (functional) parts, you'll get fast feedback from a customer that something isn't quite what he wants. So working in cycles of analysis, design, test-and-develop, deliver, redesign, refactor, add new features,... will keep you closer to the real needs. (it's like drawing a circle using lines, shorter lines will give a shape that looks more like a circle than longer)
I was reading up on Agile Programming and I'm starting to be a fan. I also read some of the arguments against "waterfall" programming and I can see some of your points. My only issue with XP was my belief that they believed in just enough code to pass the test. I felt it wasn't defensive enough and it would be more work down the line. I do like the idea of creating a pilot project to find out what's really required for a project, writing small bare-minimum code (just enough to pass a test), using constant feedback and iterations in the development, refining methods later on, etc. Thank you all for your help I think I learned a lot in this thread.
Peetzore, what's funny is I wrote my last post before I read your post. A lot of stuff I mentioned seemed to follow what you said.
> I was reading up on Agile Programming and I'm
> starting to be a fan. I also read some of the
> arguments against "waterfall" programming and I can
> see some of your points. My only issue with XP was
> my belief that they believed in just enough code to
> pass the test. I felt it wasn't defensive enough and
> it would be more work down the line. I do like the
> idea of creating a pilot project to find out what's
> really required for a project, writing small
> bare-minimum code (just enough to pass a test), using
> constant feedback and iterations in the development,
> refining methods later on, etc. Thank you all for
> your help I think I learned a lot in this thread.
have a look at [url=http://www.waterfall2006.com/]waterfall 2006[/url] for some light-hearted relief
One more thing on the Incremental/Iterative approach.
You have to make sure your customers understand what the intentions of this approach are! I was in a project developed this way. We were a team in a project developed by several teams in several locations (The Netherlands, Spain, Italy...) supervised by a central project managament. With our first functional release, a lot of bugs were logged by the integration testing team. 'This doesn't work, that isn't implemented correctly' Of course this was because of the incremental approach, but the customer saw only the rather large amount of bugs, without explanation. The project management got a phone call expressing their concern about the quality of the product delivered. They hardly succeeded in explaining that this was a process of refinement of requirements and that those bugs were actually acceptable. It took 2 iterations to get their trust back and in the end we were the first team to get through acceptance tests!
georgemc, funny site I liked it. Sorry for being so thick. I got the wrong idea of XP and agile programming. I can definitely see the benefits of this style now. Peetzore, I'll make sure to keep that in mind.
> georgemc, funny site I liked it. Sorry for being so
> thick. I got the wrong idea of XP and agile
> programming. I can definitely see the benefits of
> this style now.
most people do get the wrong idea of XP/agile at first. I think it's down to a "no pain, no gain" misconception. read the Cockburn book I linked to earlier for a good insight into software processes, it's a real eye-opener
