* The Business of Software

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!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

TDD, and Agile Software Development

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
http://en.wikipedia.org/wiki/Test-driven_development
http://en.wikipedia.org/wiki/Agile_software_development

Does anyone here do this?
Can you share your experiences with us?
C. Stark Send private email
Saturday, March 08, 2014
 
 
Alex Vasilevsky Send private email
Sunday, March 09, 2014
 
 
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.
Mauricio Macedo Send private email
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.
Racky Send private email
Sunday, March 09, 2014
 
 
It doesn't surprise me, I was talking to a developer last week who told me his employer doesn't use source control, they just zip files up when they want to be able to roll back.
Ducknald Don Send private email
Monday, March 10, 2014
 
 
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 :)
James A. Send private email
Monday, March 10, 2014
 
 
I'm not sure 100% test coverage is that useful, I don't bother unit testing the majority of my user interface because it's difficult to test automatically and easy to test manually.
Ducknald Don Send private email
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.
Doug Send private email
Monday, March 10, 2014
 
 
"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.
Scott Send private email
Monday, March 10, 2014
 
 
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.
Scorpio Send private email
Tuesday, March 11, 2014
 
 
I saw this interesting link on Twitter, from Dave Thomas:
http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
Scorpio Send private email
Tuesday, March 11, 2014
 
 
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.
Oh to be anon again! Send private email
Tuesday, March 11, 2014
 
 
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 Send private email
Tuesday, March 11, 2014
 
 
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>.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Tuesday, March 11, 2014
 
 
You may also wish to read "Why Most Unit Testing is Waste":

http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

and the discussion on HN:

https://news.ycombinator.com/item?id=7353767
Dmitry Leskov Send private email
Wednesday, March 12, 2014
 
 
Hi all,

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?
mcs Send private email
Wednesday, March 12, 2014
 
 
@mcs,

> 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".
Racky Send private email
Wednesday, March 12, 2014
 
 
@mcs: The point of that paper is not that one should not use unit testing at all, but that one should use it wisely.

The issue you are referring to is not really interpreted vs. compiled languages. One can write an interpreter for C, and modern JavaScript implementations include JIT compilers. It's about static vs. dynamic typing, and one workaround is to write your program in a statically typed language and have it compiled to the dynamic one dictated by the requirements. E.g. TypeScript compiles to JavaScript.
Dmitry Leskov Send private email
Thursday, March 13, 2014
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz