4 ms·

So, as someone who works at a giant drone-filled corporation, my guess is that the answer to your question is no. My experience, based on the state of our own c

So, as someone who works at a giant drone-filled corporation, my guess is that the answer to your question is no. My experience, based on the state of our own codebase, is that mediocre programmers tend to write code that's brittle, unmaintainable, untestable, etc... such that you end up with some classic anti-pattern like big ball of mud. The more people you have, the more you exacerbate this problem (see: Brooks' Mythical Man Month). Plus, with more programmers likely you have more churn, thus more who are relatively new to the codebase and liable to make mistakes, etc... There are probably unique situations where the above doesn't apply. Perhaps something where you can parcel out relatively routine chunks of code that would otherwise be difficult to automate. Say, an ETL system that has different file formats, where each format requires a custom module. Still, even in such a case I could envision a template system or gui tool that a non-programmer could use instead. So I'm hard pressed to come up with a good example. Perhaps a craftsman/artist metaphor is apt here: could 50 drone painters pool their talents to create a Mona Lisa? That said, sometimes folks rise to the occasion. Perhaps some drones are only drones because they've been given boring work. I feel like there's a fair amount of stymied talent in the enterprise.

bartonfink 15y ago
I used to work in a company where the drone approach did work out well. We wrote screen scrapers for insurance websites that ran in a framework that would kill them if they went off the rails, handled serious errors, and was the major interface between our component and the front end products the company actually sold. The scrapers weren't terribly technically challenging, and at the time I left, I could crank one out in roughly 3 days which was a pretty good pace. When I left, I mentioned in the exit interview that, for my salary and benefits, the company could hire 4 interns and put them to work. Even if they were twice as slow as I was, which was unlikely given all the work that went into the framework, the company would have a net productivity win, not to mention the benefits that come with having interns around to recruit from. Last I heard, they took me up on that suggestion and picked up 10 interns who are all writing and maintaining scrapers and freeing up full-timers to work on less routine work. It can work, but you need a steady supply of relatively routine work that's set up in such a way that nobody can break the system with a simple bug or logic error.
- diminium 15y ago
  What kind of framework was this? Who designed it? So it sounds like if I build a big enough fence, it can work out pretty well?
  - bartonfink 15y ago
    It wasn't an off the shelf framework. "Scraping engine" may be a better phrase to describe what it actually did. External components would make a call, saying something like "I need the data for this particular patient from this particular hospital". The engine would then spawn off a thread containing the scraping code for that particular hospital, and it would run off, scrape the website and then return a well formatted version of that data or one of a series of error messages. If the thread got hung up, the engine killed it and returned an error. We built the engine when we realized that these scrapers were a competitive advantage for the company and we'd be writing a lot of them (when I left, we had around 250 of them with a backlog of near 1000 to be written). It became worth the investment to write the framework because there were features we wanted that would have been hell to integrate any other way - for instance, killing long-running scrapers that may have been hung up. The engine bought us lots of other niceties too - for instance, centralized error reporting. If one particular scraper returned lots of errors, odds are that the site changed and we knew to give the code some attention. When you describe it as a "big enough fence", that's only partially true. It's more about a series of independent tasks that don't depend on each other. When you have that and those tasks have only minimal impact to the system as a whole that you have a scenario which suggests drone programming.
diminium 15y ago
Probably not the Mona Lisa but they did create The Simpsons.

bartonfink 15y ago

I used to work in a company where the drone approach did work out well. We wrote screen scrapers for insurance websites that ran in a framework that would kill them if they went off the rails, handled serious errors, and was the major interface between our component and the front end products the company actually sold. The scrapers weren't terribly technically challenging, and at the time I left, I could crank one out in roughly 3 days which was a pretty good pace. When I left, I mentioned in the exit interview that, for my salary and benefits, the company could hire 4 interns and put them to work. Even if they were twice as slow as I was, which was unlikely given all the work that went into the framework, the company would have a net productivity win, not to mention the benefits that come with having interns around to recruit from. Last I heard, they took me up on that suggestion and picked up 10 interns who are all writing and maintaining scrapers and freeing up full-timers to work on less routine work. It can work, but you need a steady supply of relatively routine work that's set up in such a way that nobody can break the system with a simple bug or logic error.

diminium 15y ago
What kind of framework was this? Who designed it? So it sounds like if I build a big enough fence, it can work out pretty well?
- bartonfink 15y ago
  It wasn't an off the shelf framework. "Scraping engine" may be a better phrase to describe what it actually did. External components would make a call, saying something like "I need the data for this particular patient from this particular hospital". The engine would then spawn off a thread containing the scraping code for that particular hospital, and it would run off, scrape the website and then return a well formatted version of that data or one of a series of error messages. If the thread got hung up, the engine killed it and returned an error. We built the engine when we realized that these scrapers were a competitive advantage for the company and we'd be writing a lot of them (when I left, we had around 250 of them with a backlog of near 1000 to be written). It became worth the investment to write the framework because there were features we wanted that would have been hell to integrate any other way - for instance, killing long-running scrapers that may have been hung up. The engine bought us lots of other niceties too - for instance, centralized error reporting. If one particular scraper returned lots of errors, odds are that the site changed and we knew to give the code some attention. When you describe it as a "big enough fence", that's only partially true. It's more about a series of independent tasks that don't depend on each other. When you have that and those tasks have only minimal impact to the system as a whole that you have a scenario which suggests drone programming.

diminium 15y ago

Probably not the Mona Lisa but they did create The Simpsons.