3 ms·

"It doesn't take very long to 'build' the software or the website (obvious 'large scale' projects like OSes excepted)." A lot of assumptions have to be met for

"It doesn't take very long to 'build' the software or the website (obvious 'large scale' projects like OSes excepted)." A lot of assumptions have to be met for that to be true. It shouldn't take very long provided: 1. The programmers are very familiar with the tools. 2. The programmers are very familiar with all necessary 3rd party components. 3. The 3rd party components account for 99% of functionality. 4. The programmers have built that exact project before, preferably more than once. I usually work in a best-case scenario for development: I'm building projects with limited scope, solo and with no other decision makers involved in the project. I'm also experienced enough to know how complex things will generally be from a high level standpoint. And I have never once met my own estimate for complexity and the amount of time something will take. Exactly 100% of the time silly, seemingly inconsequential things add up to an extra 30% or more. It doesn't matter if you can write 1000 shippable lines of code in a day because tomorrow you'll spend most of your time hunting a bug in an external library. Suddenly your machine-like pace has been cut in half. This happens on every project I've worked on and I would assume all software projects. I agree that poor planning adds to the amount of time needed. Of course it does. But there really is no "best case" scenario where you and a couple of buddies could hammer out Facebook in three weeks.

bigiain 14y ago
"It doesn't matter if you can write 1000 shippable lines of code in a day because tomorrow you'll spend most of your time hunting a bug in an external library. Suddenly your machine-like pace has been cut in half. " I'm there right now - why doesn't this Concrete 5 ecommerece plugin's Paypal addon work this week, when nothing's changed since last week??? It's not just you…
- mbenjaminsmith 14y ago
  I was thinking a bit lower level than that but yeah, I guess you get my point. I spent a day with a bug that I found in OpenCV (a computer vision/machine learning library) that spooks me to this day. How it works internally is that for images to be processed you create a header (with usual image header info) which contains a pointer to the actual image data. There are two ways to do it: one you create the header and then create the image data separately and the other you create the image all in one go. I ended up in a situation where the image (it was going through a couple of different filtering algorithms) would get processed and be displayed regardless of whether or not I had set the pointer to the image data. That image data was already in memory since it was getting read from disk in a separate step, but there was really no way for the library to know its location in memory. I spent a day trying to sort out what was going on -- and threw my own schedule -- because I had to assume something was seriously wrong and would lead to other unintended consequences. I never did figure out what it was but after a lot of testing I decided it wouldn't cause any other problems (it never did, the library I was writing is still the core of a product I'm selling today). If you don't know it OpenCV is about as mature as a software project can get. It was most likely the best tool for the job I had to tackle. But even with the library's stability and widespread use there was just plain voodoo that set a project I was working on back. Other 3rd party tools can be much worse. I don't do any web stuff but I have had to integrate Facebook Connect into products. Interfacing with Facebook can be a nightmare. Their API changes fairly regularly and the documentation can be a mess. Even using a 4th party, regularly updated, helper library I've seen bugs that took ages to sort out. And that's just talking about integrating 3rd party, hopefully mature, components. I don't care how good you are, writing new code means a lot of testing and debugging. I've never seen new code that didn't introduce some voodoo of its own into a project.
  - ansgri 14y ago
    I wouldn't call OpenCV 'about as mature as a software project can get,' as it's actively developed library with lots of contributors in yet experimental domain (more about mid-level pattern recognition than low-level image filtering). And the documentation was not up-to-date last I checked (~2 months ago). Bugs in really mature software (i.e. libtiff, libxml, sqlite) are very rare.
    - mbenjaminsmith 14y ago
      That's probably more accurate. I was conflating a long history with maturity/stability. I would guess most ~13 year old libraries are broadly more stable and bug-free than something a few years old but I guess anything that is being actively adapted to new problems will have inherent instability. I seriously doubt the code for reading images into an OpenCV-native format is being actively developed though. Anything being done in pattern recognition would likely not effect the library's basic IO stuff. What I was actually using it for (their RDP implementation, image thresholding) were likely pretty stable as well.
jakejake 14y ago
I tend to agree that the actual code writing phase is easy if the spec is very thorough. But the spec can never specify everything and tons of little decisions are left up to the developer. There are always people on the team who will create little messes. Those messes start to pile up unless there is a very strong leader who refuses to let any inconsistent code through (and is given the time to do so)

bigiain 14y ago

"It doesn't matter if you can write 1000 shippable lines of code in a day because tomorrow you'll spend most of your time hunting a bug in an external library. Suddenly your machine-like pace has been cut in half. " I'm there right now - why doesn't this Concrete 5 ecommerece plugin's Paypal addon work this week, when nothing's changed since last week??? It's not just you…

mbenjaminsmith 14y ago
I was thinking a bit lower level than that but yeah, I guess you get my point. I spent a day with a bug that I found in OpenCV (a computer vision/machine learning library) that spooks me to this day. How it works internally is that for images to be processed you create a header (with usual image header info) which contains a pointer to the actual image data. There are two ways to do it: one you create the header and then create the image data separately and the other you create the image all in one go. I ended up in a situation where the image (it was going through a couple of different filtering algorithms) would get processed and be displayed regardless of whether or not I had set the pointer to the image data. That image data was already in memory since it was getting read from disk in a separate step, but there was really no way for the library to know its location in memory. I spent a day trying to sort out what was going on -- and threw my own schedule -- because I had to assume something was seriously wrong and would lead to other unintended consequences. I never did figure out what it was but after a lot of testing I decided it wouldn't cause any other problems (it never did, the library I was writing is still the core of a product I'm selling today). If you don't know it OpenCV is about as mature as a software project can get. It was most likely the best tool for the job I had to tackle. But even with the library's stability and widespread use there was just plain voodoo that set a project I was working on back. Other 3rd party tools can be much worse. I don't do any web stuff but I have had to integrate Facebook Connect into products. Interfacing with Facebook can be a nightmare. Their API changes fairly regularly and the documentation can be a mess. Even using a 4th party, regularly updated, helper library I've seen bugs that took ages to sort out. And that's just talking about integrating 3rd party, hopefully mature, components. I don't care how good you are, writing new code means a lot of testing and debugging. I've never seen new code that didn't introduce some voodoo of its own into a project.
- ansgri 14y ago
  I wouldn't call OpenCV 'about as mature as a software project can get,' as it's actively developed library with lots of contributors in yet experimental domain (more about mid-level pattern recognition than low-level image filtering). And the documentation was not up-to-date last I checked (~2 months ago). Bugs in really mature software (i.e. libtiff, libxml, sqlite) are very rare.
  - mbenjaminsmith 14y ago
    That's probably more accurate. I was conflating a long history with maturity/stability. I would guess most ~13 year old libraries are broadly more stable and bug-free than something a few years old but I guess anything that is being actively adapted to new problems will have inherent instability. I seriously doubt the code for reading images into an OpenCV-native format is being actively developed though. Anything being done in pattern recognition would likely not effect the library's basic IO stuff. What I was actually using it for (their RDP implementation, image thresholding) were likely pretty stable as well.

jakejake 14y ago

I tend to agree that the actual code writing phase is easy if the spec is very thorough. But the spec can never specify everything and tons of little decisions are left up to the developer. There are always people on the team who will create little messes. Those messes start to pile up unless there is a very strong leader who refuses to let any inconsistent code through (and is given the time to do so)