tag:blogger.com,1999:blog-5246987755651065286.post1569689323725671956..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 01-13-10 - Oodle Revisitedcbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-5246987755651065286.post-83814011918884537312010-01-14T07:44:05.097-08:002010-01-14T07:44:05.097-08:00Yeah, the Not-Invented-Here disease is just crazy ...Yeah, the Not-Invented-Here disease is just crazy (my employer also suffers from this), since the right reasons for doing this are pretty rare. There is a potentially huge opportunity cost of losing an in-house engineer to a non-core aspect of your product. For the peripheral stuff, of course you should try to benefit from the economies of scale.<br /><br />That calculus also lacks a measure of risk. Even if the 20 hour estimate were accurate, it is almost certainly not precise. It is probably like 20 +/- 50 hours.<br /><br />There's also this "race to the bottom" problem, where maybe the manager asks a few engineers how long it would take to do something. Invariably, the shortest estimate heard is what goes into the schedule.won3dhttps://www.blogger.com/profile/09787472194187459747noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-80291129380580287042010-01-14T06:25:29.595-08:002010-01-14T06:25:29.595-08:00Yeah, well some managers are just hopeless.
What ...Yeah, well some managers are just hopeless.<br /><br />What I'm talking about is even reasonable managers. They often do some computation like :<br /><br />we can write that in 20 man hours. A man hour costs us $300 , so if it costs $6000 or more, we'll just write it ourselves.<br /><br />No! You feel all analytic because you did some math, but you aren't including all the factors correctly.<br /><br />One issue I believe is that people overvalue the benefit of having written the code themselves. They imagine this means they will know it better, it will be better quality, etc. Yes, in some cases that's true, but in others the opposite is true. <br /><br />Obviously code that's at the core of your project you want to write yourself, but super peripheral edge stuff has very little value.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-86215617296355728212010-01-13T16:23:20.356-08:002010-01-13T16:23:20.356-08:00"The game industry has always suffered from t..."The game industry has always suffered from the mistaken thinking of "I could write that myself, so I won't pay for it". "<br /><br />This is so true. At a leading mobile gaming publisher (that I won't cite) I used to work at for 6 years, they're doing exactly that:<br /><br />They're in big need to unify their audio work, because they make the same games on lots of different machines. Fmod + Designer would be very handy => they sound designers would do the work once and it would all be ported almost magically to the other consoles/iPhone/whatever, plus a lot of the work is taken out of the hand of programmers (no more begging the programmer for varying the pitch of a sound randomly for example).<br /><br />They really don't want to spend $3000 on this because it's too expensive. So what are they doing instead? The obvivous "cheaper" alternative: trying to make a custom audio engine + tools from scratch. Which is going to be more expensive than Fmod from the first month of development, and will do 0.01% of what it does.<br /><br />Now that's their mindset for just about everything, 3d engines, tools, servers. EVERYTHING. In the end, everything they make/use costs 10 times more than existing, proven solutions, works 1/100th as well, and offers 1/100th of the possibilities.<br /><br />There's no point trying to think rationaly in some game companies. They're just retarded.Nino Mojohttps://www.blogger.com/profile/14761941491077975645noreply@blogger.com