|
Another (bad) Analogy for Outsourcing
In a recent thread, someone makes an analogy between "outsourcing" architectural drawings and offshoring software development.
I'm not sure whether that analogy is a good one or not, but coming up with bogus analogies is fun. How about this one?
Consider "The Simpsons". The writing, the storyboards, the original character design, the voice talent, all that stuff is done in North America. The actual tedious animation is offshored (to Korea IIRC.)
The "design" is all in North America, the "coding" is in Asia, and they've made buckets of money for thirteen years. And yet, successful comedy character animation is a difficult craft, very culturally dependent, and quite non-standardized -- every frame of every episode is unique.
I've seen a lot of blogs lately on how design and coding are not separate activities, and if they're right, then this analogy is bogus. What's wrong with this analogy? (I can think of lots of things, but I'm curious as to what aspects other people pick up on.)
Eric Lippert
Tuesday, March 9, 2004
It takes 24 frames of animation to create one second of video. So if Groenig creates keyframes every 1-2 seconds, someone else can create and color the other 23-47 tween frames.
What would the coding equivalent be of those 23-47 frames?
Philo
Philo
Tuesday, March 9, 2004
Why is the animation outsourced? Because it's boring and tedious to draw frame after similar frame.
Why is software development outsourced? Because it's boring and tedious!
Even if there wasn't the threat of losing our precious software development jobs to outsourcing, I'd still be looking at other options. Why? Because writing software is very boring.
It was exciting when I was 15 and liked spending hours in front of the QB45 compilier I got for Christmas. It's not exciting to spend hours fixing yet another bug in some boring business software.
Plus, due to outsourcing or not, the real money is made by the project managers and other business-side people.
So, I'm trying to move towards project management or another non-technical area and I'm not looking back.
Blargo
Tuesday, March 9, 2004
Philo:
Here's a try at the missing frames.
I write a stubbed class. The "developers" simply fill in the blanks.
Elephant
Tuesday, March 9, 2004
Design is iterative- you can go spend 2 months coming up with a design, toss it over the wall to the coders, and a week later they will come back to you and say "What about X?", and you say "Oh sh--!", and you have to go back the the ol' "drawing board".
Knowing nothing about animation, I purport that you can do the storyboards, then toss it over the wall to the artists, and they draw it. You may not like what they draw, but there's nothing stopping them from taking your storyboard and bringing it to life.
ken
Tuesday, March 9, 2004
But "the blanks" usually can either be filled in by a CASE tool or else that's where the magic happens.
I've long been a believer that there's room in IT for master/apprentice type relationships - a senior coder basically gets code functional, makes it "work", etc. Then comes the part we all hate - providing for boundary cases, unit testing, bullet-proofing the code. To me, that's the 23-47 frames part.
However, I also think that handing it off requires such a massive knowledge transfer that it's almost not worth it. But if you have an apprentice that's involved in the project and knows the master coder, it's easier for him/her to pick it up and finish it. In time, the apprentice learns enough to start leading projects on his/her own.
But I don't think it works if the master and apprentice are 8000 miles apart.
Philo
Philo
Tuesday, March 9, 2004
elephant:
the problem with that is that the stubbed class is often more like saying "i give them a box of pencils in the 5 colors i want to use, they fill in the rest"
what I want to not do? error handling and the like! the gobs of code you have to write to run on some obscure configuration when the simple API call just doesn't work. all the non-fun stuff, really, but it's not repetitive.
a lot of repetitive work can be automated. it's done for animation today just like it is for coding.
mb
Tuesday, March 9, 2004
> a senior coder basically gets code functional, makes it "work", etc. Then comes the part we all hate - providing for boundary cases, unit testing, bullet-proofing the code
If it doesn't provide boundary cases, hasn't passed unit tests, and isn't bullet-proof, then what do you mean by "work"? And, how could a senior coder write like that?
> What's wrong with this analogy?
Incremental design and development: I develop software by writing code that fully implements a subset of the functionality. I then add code, to add more functionality. Adding functionality changes the structure of the code. In other words, with software when you 'fill in the blanks' you also want to change the 'keyframes'.
I wondered whether Elephant's 'subbed classes' might be more plausible than Philo's 'non-bullet-proofed' code. The advantage of stubs is that they don't have any coding bugs. A problem with stubs is that (except perhaps with a CASE tool) they can't be executed and in that way they can't be tested: and so they may contain design bugs.
For example, yesterday I wrote some code to get sampled data from a 'stream', write the data into a 'array of plots' class, and display this 'array of plots' in a 'graph' component. Today I had to design and implement a little detail: how to normalize the plots (convert them from e.g. "3000" to e.g. "0.3", according to the physical dimension that the digitized sample represents). Therefore I had to decide which class was going to implement this functionality, and contain the data which describes the physical dimensions of the sample: the stream reader class? the array of plots class? or the graph class?
When I think of large-system architectures being defined, I think that the architecture defines the interfaces to major components (for example, in Win32 the architect says: "we'll invoke your application by calling your WinMain routine, after which you can call these API functions ... and we'll push WM_ messages at you"). But the architecture doesn't specify (or, constrain) the internal design of each such module. The architect doesn't say "I'll define every 24th line of code for you." And, when the architect DOES say that, e.g. in an MFC-framework program, then...
Christopher Wells
Tuesday, March 9, 2004
Your analogy works in more ways than one -- first we outsource it because it's overly manual (cell animation), then we computerize it, eliminating even the outsourcing.
Dennis Forbes
Tuesday, March 9, 2004
"If it doesn't provide boundary cases, hasn't passed unit tests, and isn't bullet-proof, then what do you mean by "work"? And, how could a senior coder write like that?"
SELECT SUM(TravelExpenses + LodgingExpenses) FROM Travel WHERE [condition]
Do data entry, run reports, demonstrate end-to-end functionality. Everything works fine.
Until there's a null in LodgingExpenses. That's what I meant by "boundary cases"
In my experience an application can be delivered that satisfies all the requirements (when run by the developer) in the first 20% of dev time. The remaining 80% is dealing with all the exceptions, validation, etc, etc, etc.
In other words, I can make it work in a week, but it'll take another four weeks to make it deliverable. ;-)
Philo
Philo
Tuesday, March 9, 2004
The biggest problem that I can think of is that animation (unlike software) allows for a certain amount of latitude in regards to correctness, yet can only be correct in one way.
If the lines aren't perfect, or a shape isn't perfectly in proportion from one frame to the next, it will still pass as acceptable. In software, if I ask for 3/2 and the computer stores it as 1.499999999 due to an Intel floating point percision error or something, this is unacceptable.
As far as being correct in only one way, as long as Homer starts with the beer full and finishes with it empty, then the animator has succeeded in the task. There are no bugs; there is no room for error. There is mostly only one logical means from getting from cell A to cell B. The inputs are guaranteed, and the outputs are guaranteed. The rest is just filling. The possiblity of Moe pulling the beer out of Homer's hand because he hasn't paid his tab need not be considered. One doesn't have to worry about the glass having a hole in the bottom causing the beer to drain out onto Homer's lap before it ever makes it to Homer's lips. With software, these types of things need be considered. The animators don't have to have come up with defensive animations just in case the glass has a hole in it or Moe decides to collect the tab.
Software is more of like trying to animate an open ended RPG without a fixed story line without knowing what path the gamer will take through the game. You'd have to address every situation that could possibly occur, and situations that probably won't ever occur. Kind of like the Myst approach of pre-rendering every cell but with an open ended story line and with infinite choices. It's clearly impossible to do this. And there is a reason no one tries. Pre-rendering is accepted only for things like movies and cartoons where the incomes and outcomes for a series of events are predetermined.
Software may have an idea what the most likely incomes and outcomes are, and what the desired behavior is, but it's more of a living breathing thing. You can't know everything that it might do, and for that reason, you can't just specify the income and the outcome and expect someone to fill in the blanks.
Not knowing the nature of the beast but still accomplishing the goal is what makes software development a difficult task. It's also what seperates the bad from the good from the best. It's also why it can't be outsourced very easily or effectively. With so many unknowns and variables in the equation, doubling the quantity by eliminating the "big picture" almost guarantees some degree of failure.
My first post was my best guess as to a reasonable analogy for the missing frames, but it was largely spoken in sarcasm.
Elephant
Tuesday, March 9, 2004
"Then comes the part we all hate - providing for boundary cases, unit testing, bullet-proofing the code."
But the ability to do that is what seperates the good developer (the "master" in your lingo) from the average developer (the "apprentice").
You're handing off the difficult (but tedious) bit after having done the easy (but more enjoyable) bit to the person less qualified to do it!
Sum Dum Gai
Tuesday, March 9, 2004
2D animation is quite different from software development.
The work that's outsourced is called tweening, and has always been regarded as mechanical drudgery. Animators would draw key frames, perhaps every 20th frame. Those set the animation. Then mechanical artists would draw the minor variations between the key frames.
Software development doesn't have that clear differentiation between tasks. The "mechanical" part of software development has already been done, and consists of the libraries and tools we use. All the rest of it is design and development. At least in the jobs I do.
x
Tuesday, March 9, 2004
I read an article about the Simpsons animation procedures several years ago. Groening, the show's creator, said that the Koreans sometimes get the colors wrong, since they aren't familiar with American material culture.
Outsourced programming has many more degrees of freedom than outsourced animation, which makes following specifications more difficult.
Julian
Wednesday, March 10, 2004
Animation:
easy requirements specification: Keyframes + storyboard
easy acceptace checks: just watch the result
Linear & predictable investment to result time: X frames takes Y time and Z resources
Software:
Hard to specify the requirements: vague, iterative, incomplete
Hard acceptance checks: thorough testing of complex system in many dimensions (correctness, performance, ...)
Big upfront investment to result. Butterfly effect: small changes in spec can possibly require arbitrary large changes in investment.
That said there is a lot of software systems that could be created with good and stable spec, good acceptance tests and architectually finegrained enough to get workable unit investment size. There is also a lot of work that will never be able to meet those 3 criteria.
Just me (Sir to you)
Wednesday, March 10, 2004
Outsource Java to the Jython team. Buy a code library. Write macros and outsource their code expansions to the virtual world. Code that writes code that makes a coder redundant is the happiest code of all.
Tayssir John Gabbour
Wednesday, March 10, 2004
 Recent Topics
Fog Creek Home
|
