A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
I just finished the book
"Notes To A Software Team Leader"
I really enjoyed the book. There were many references to TDD, and Agile Software Development principles. I guess I have been living in a bubble for the last 15 years, because I never heard of either of these.
I looked them both up
Does anyone here do this?
Can you share your experiences with us?
I've been trying to adopt TDD. It's a really nice methodology, but it's hard to keep using it when you want instant gratification or don't have the spec of what to build.
Nowadays I separate the interface logic from business logic, by creating an "engine" and using TDD to ensure the engine is working as it should as I improve the application.
Sunday, March 09, 2014
> I guess I have been living in a bubble for the last 15 years, because I never heard of either of these.
Wow, I find that bubble quite interesting, in that you can subsist (and thrive) in the software ecosystem fully without it, yet I have I heard of both of those a great deal online as some of the main buzzterms I tend to encounter, for many years now. It also often seems that the most common idea one encounters on software related blogs, etc. now is: if you don't do TDD (or something like that), your approach is unacceptable.
I've yet to work somewhere that fully embraced TDD. Usually, unit tests are the first thing to be chucked when schedules get tight. The result is often buggy and barely working, but meeting schedule is usually deemed to be more important. Also, everyone claims to be following "Agile" these days, but in reality many are just flailing about with no real processes in place and calling the resulting chaos "Agile." Because it sounds cool.
I do write unit and/or integration tests when working on my own projects, but I'd be lying if I said I had anything close to 100% test coverage -- because I like to actually finish projects :)
Monday, March 10, 2014
I too have never worked anywhere that did either Agile or TDD.
In my own stuff I've got automatic regression tests on a very few core objects, but that's all. It would be nice, but I have a very hard time justifying the 3X or 4X time it would take to write all the tests and create all of the mocks for TDD. For doing nice self-contained libraries it could make a lot of sense though. Once lots of mocks are involved, uggh :(
For the TDD fans that will assume my code must be absolute crap, out of ~500K lines of code, I probably get 2-3 minor bug reports per week. So far the time to market trade off has been well worth it. YMMV.
"hey just zip files up when they want to be able to roll back"
And that IS in fact a source control system, allowing both backups and reversions.
It doesn't directly allow merges though or looking at change sets.
However, it's considerably easier to use than most systems, and thus might be more likely to be used reliably.
I'm glad it isn't just me that doesn't use TDD and Agile. I've been a developer for over thirty years, so I've seen a lot of buzzwords come and go, but in the end all that matters is communications skills.
If you can't communicate effectively with the client/employer, then your project will never succeed.
Failing in an Agile way is underwhelming at best.
As an aside, my favourite "methodology", if you can call it that, was JFDI, which found favour in the 90's. It was refreshing as it stripped away all the self-justifying, buzzword-bingo BS.
As always, IMHO, YMMV, etc.
I saw this interesting link on Twitter, from Dave Thomas:
I recently moved from an IDE to a text editor.
When using the IDE I would typically walk through the code in the debugger and examine some vars along the way. If everything looked as expected I was done.
With the editor I have to put print statements in place to view the goings on. I find it faster to write a test that calls a function rather then winding my way deep into an application to print some vars to a screen. Once I have the driver function it's much easier to vary the input to give better coverage.
I've noticed it's a really common thing among skilled developers to find printf debugging used a lot, and debugger not so much. Heavy debugger users are often random guessers.
Debugger can be useful for analyzing unfamiliar code. Especially dealing with the virtual dispatch stuff where it's nearly impossible to tell what will happen when a line is executed just from examining the source code. Like the code where "x += 2" does some freaky thing due to operator overloading and virtual overrides which eventually involves network and file access that takes 750ms.
IDEs are good for maintaining make files. Wow, it's 2014 and make is still the same piece of crap it was in 1972. Sheesh.
Scott: "I've noticed it's a really common thing among skilled developers to find printf debugging used a lot, and debugger not so much. Heavy debugger users are often random guessers."
I use a debugger sometimes, but often, I find it gets in the way.
Much of my programming is in Microsoft Visual FoxPro. When I am debugging regarding event firing order, sometimes, the debugger changes things. <sigh> This is the time when I really could use a good debugger.
Executing code within a method is straightforward, and I sometimes use the debugger for that, but when the problem is buried deep, getting to the problem area with the debugger can be difficult. This is particularly the case when the problem is a later iteration. (I do not want to wade through the first umpteen iterations which are correct.)
The advantage of print statement debugging is that it does not change things (much). Another is that one can often add code to not print anything unless <arbitrary condition>.
Tuesday, March 11, 2014
You may also wish to read "Why Most Unit Testing is Waste":
and the discussion on HN:
Wednesday, March 12, 2014
I've read all this thread, and just now I'm reading the "Why Most Unit Testing is Waste" paper, and I have a question for you:
If you don't use automated unit testing, how do you test your applications, when they're written with interpreted languages like PHP, Ruby or Python?
I mean: When I develop a Delphi or Java application, only building the project I can find syntax errors (typos), functions with wrong number of parameters, etc. With a simple compile-link cycle you get lots of "feedback", but what can I do when I'm building a PHP application? Test any page one by one, and any condition? Or when using interpreted languages unit and functional testing is a good idea?
Wednesday, March 12, 2014
> If you don't use automated unit testing, how do you test your applications, when they're written with interpreted languages like PHP, Ruby or Python? ... ... I mean: When I develop a Delphi or Java application, only building the project I can find syntax errors (typos), functions with wrong number of parameters, etc.
I can only speak for my use of Python for desktop apps, but, for "syntax errors (typos), functions with wrong number of parameters, etc.", I see these every time I run the program within the IDE, since the interpreter will catch them at runtime and show them in my IDE's tracebacks or errors tab. These are usually pretty easy fixes.
The real problems are errors that allow the program to run but give a bad/wrong user experience (wrong values, database write errors, GUI glitch ugliness, etc), which I have been testing manually, in the "role of the user".
@mcs: The point of that paper is not that one should not use unit testing at all, but that one should use it wisely.
Thursday, March 13, 2014
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz