08:20 am, 28 Jun 04
version control
"Now some 40 percent of teams in the U.S. don't use version control at all. 76 percent don't unit test, and 70 percent don't have a daily build."
It's really weird to work "in the industry" now because I'm getting a glimpse of how companies work on the inside. (Though my company is known for its unconventionality...)
It's really weird to work "in the industry" now because I'm getting a glimpse of how companies work on the inside. (Though my company is known for its unconventionality...)
Unit testing seems to start out with the concept that you don't really write a software 'product', but just a bunch of functions that do small things, or a library that acts on data you pass it. But take MS word (I know, I know...) as an example: how do you unit test this?
On a low level, I'm sure it has routines to check if a word is in a dictionary and to write files etc, which could be unit tested, but once past that... How do you "unit test" the code that combines 15 chapters each in a different word file into a master document (e.g. for a book)? Sure you can have some example files and run them through a test cod ethat does this, and compare the outcome to a reference document but each time you change even the slightest thing in any code that alters just one byte in the result, the comparison will tell you something is now different. So then what? how do you know if this is wrong or right?
maybe i'm way off but: 40% of teams in the u.s. are barely cogent cut-and-pasters. you can't run a unit test if you don't know what one is. 70% of teams in the u.s. just put it on the server, and that's a daily build, isn't it? that's a minute-by-minute build!