tag:blogger.com,1999:blog-5304409.post4120592377624109607..comments2024-03-17T16:17:20.145-07:00Comments on Amit's Thoughts: Diminishing returns in a projectAmithttp://www.blogger.com/profile/12159325271882018300noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-5304409.post-52864427947287872632012-04-20T22:49:14.586-07:002012-04-20T22:49:14.586-07:00That's a good point Bemmu. A small change in a...That's a good point Bemmu. A small change in a widely used or long lasting project can have more impact than a large change in a little used or short lived project.Amithttps://www.blogger.com/profile/12159325271882018300noreply@blogger.comtag:blogger.com,1999:blog-5304409.post-65638481504603394492012-04-20T18:26:03.979-07:002012-04-20T18:26:03.979-07:00The more important the project becomes, the bigger...The more important the project becomes, the bigger the gains from small improvements. If you start on a project that makes $1k / month and expect it to exist at least two years, spending a month to accomplish a 15% improvement might be justified.<br /><br />If you managed to make five such improvements and got the project to bring in $2k / month, then after that even a 7% improvement would be worth chasing after. As you would improve it more and more, even though gains would become more difficult to achieve, they would also be more worthwhile.Bemmu Sepponenhttp://www.bemmu.comnoreply@blogger.comtag:blogger.com,1999:blog-5304409.post-55368076896305253202010-10-14T07:19:23.129-07:002010-10-14T07:19:23.129-07:00This theory would apply to all activities in gener...This theory would apply to all activities in general?JALhttp://www.ideaindia.comnoreply@blogger.comtag:blogger.com,1999:blog-5304409.post-32049730493828938252010-10-09T11:22:39.961-07:002010-10-09T11:22:39.961-07:00Anonymous, yes, I agree. I hadn't been thinkin...Anonymous, yes, I agree. I hadn't been thinking about the game development model. Most games are developed, shipped, and then forgotten about, whereas a lot of other software is maintained for a long time, with periodic updates. It's for software like Microsoft Word that I produced that graph — you start with basic features that everyone needs, like entering text, paragraphs, formatting, etc., and later on you end up working on more features that are less important, such as dialog boxes that let you change the color of the squiggles.Amithttps://www.blogger.com/profile/12159325271882018300noreply@blogger.comtag:blogger.com,1999:blog-5304409.post-82041961806494335232010-07-13T07:53:15.251-07:002010-07-13T07:53:15.251-07:00I suppose this model depends on the type of projec...I suppose this model depends on the type of project worked on. <br />In game development, you would never consider optimizing code until you are near the end of development since you won't know until then what are the true bottlenecks. Then there's also finding and eliminating remaining bugs. These two tasks are very important and beneficial to any game, it can make or break the project. <br />Also, things that are riskier are usually done earlier in the projects, this way if the feature fails there is time to recover from it.<br />For these reasons I believe that your 3rd diagram is flawed. With over 10 years as a dev guy on games, I've always found that team sizes explode as you approach the end of the project.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5304409.post-28490559527616708842010-05-19T06:58:11.741-07:002010-05-19T06:58:11.741-07:00Amit, I like the simplicity of the "who times...Amit, I like the simplicity of the "who times what = output". There is class of projects that this describes quite well. I'd suggest a third multiplier, "motivation". Even if you don't know the exact point to switch, your model at the very least helps qualitatively classify projects into those that require faster switches and those that don't.Nikhil@Tedhttps://www.blogger.com/profile/13848347407504602452noreply@blogger.comtag:blogger.com,1999:blog-5304409.post-10458156962716562782010-04-19T03:10:43.185-07:002010-04-19T03:10:43.185-07:00I completely agree with this assessment. I'm ...I completely agree with this assessment. I'm a travelling computer consultant, and when I get plugged into a long running project, there's some acclimatization, then some hard work, lots of progress. This ties into getting things working and general interest because it's new. Once functionality is reached, interest wanes. People forget it's "incomplete". Daily activity isn't usually impeded. Etc.<br /><br />Occasionally, there's a bigger dip on the left side of the curve due to technological roadblocks, but in reality, the curve should extend to the right substantially. The fade off is about as steep, but the last, say, 10%, is easy to drag out over 10x the duration of the whole project.<br /><br />So the key is to know where to focus your energies, and to have an exit strategy. Usually, that involves having administrative or operational staff begin taking over about 25% down the backslope. By about 50% down, they should be doing everything, and just talking to the initial project folks for occasional questions. Once you're 75% down, the admin/ops staff should be running everything.MaxiPadhttps://www.blogger.com/profile/04650660045425350918noreply@blogger.comtag:blogger.com,1999:blog-5304409.post-73394470329220596402010-04-18T21:14:26.158-07:002010-04-18T21:14:26.158-07:00interesting! i've only switched projects volun...interesting! i've only switched projects voluntarily a couple times now, as opposed to at artificial points in time (e.g., finished school, sold a company), but i can definitely identify with the idea.<br /><br />incidentally, i <a href="http://snarfed.org/space/2010-03-13_new_job" rel="nofollow">recently switched projects again</a>. i'll see how ramp-up feels on my new project, and if i can identify when i hit different points on the curve.Anonymousnoreply@blogger.com