tag:blogger.com,1999:blog-6893032696317132921.post342783842011845463..comments2024-03-11T08:01:37.469-04:00Comments on Gabriel's software development blog: Questions, only questionsAnonymoushttp://www.blogger.com/profile/17525961934302794120noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-6893032696317132921.post-63266192694708089822021-07-16T03:49:45.573-04:002021-07-16T03:49:45.573-04:00British Dissertation Consultants offering best dis...British Dissertation Consultants offering <a href="https://www.britishdissertationconsultants.co.uk/about-us.php" rel="nofollow">best dissertation writing services</a> for over a decade, ensuring to deliver the best quality dissertation drafts.<br />Daniel Paulhttps://www.blogger.com/profile/07030220054085984880noreply@blogger.comtag:blogger.com,1999:blog-6893032696317132921.post-72033571892869968542008-07-01T13:28:00.000-04:002008-07-01T13:28:00.000-04:00I have been pondering a lot of these questions mys...I have been pondering a lot of these questions myself, but more at a systems level. My approach to the problem has been "Why is software development so different than other time-proven technical tasks?"<BR/><BR/>Through several accidental job assignments I have learned a lot about how to control the process through Configuration and Change Management, which helps reduce scope creep and code drift dramatically. The problem with it is that is must be fully embraced at the start of a project to have the desired effect, and most projects just starting up are not thinking about such things. <BR/><BR/>M@M@https://www.blogger.com/profile/01037655020380850392noreply@blogger.comtag:blogger.com,1999:blog-6893032696317132921.post-15194606742085202172008-06-06T07:44:00.000-04:002008-06-06T07:44:00.000-04:00This comment has been removed by a blog administrator.Binaryhttps://www.blogger.com/profile/00084187969951357756noreply@blogger.comtag:blogger.com,1999:blog-6893032696317132921.post-81979684466754586662008-06-05T23:24:00.000-04:002008-06-05T23:24:00.000-04:00@StephenOk, "every" is too strong, but code is inf...@Stephen<BR/>Ok, "every" is too strong, but code is information, and is subject to entropy: you need to spend energy to reduce it. That normally means refactoring of the code or some alternative like that. I've worked on codebases that improved over the time too, but that is not something you get for granted or cheap. 99% of the time, is less effort to change the code than change the code AND maintain integrity (and a significant amount less than change the code and increase integrity). Of course, is better (and I would strongly recommend it) but it doesn't come for free, and that was somehow what I intended to say :) <BR/>(for sure, I didn't want to express any certainty in my post ;) )Anonymoushttps://www.blogger.com/profile/17525961934302794120noreply@blogger.comtag:blogger.com,1999:blog-6893032696317132921.post-59536560184687707802008-06-05T17:10:00.000-04:002008-06-05T17:10:00.000-04:00Every code base starts to degrade and loose integr...<I>Every code base starts to degrade and loose integrity as evolves.</I><BR/><BR/>Simply not true. Some projects start with ill defined goals. As the goals become clear, often the interfaces are restructured to reflect reality. They gain integrity as they evolve. I've worked on several that behaved this way.<BR/><BR/>Sometimes, you have to give up on backward compatibility to make this happen. It's certainly OK when you have 100% of the dependent code at hand.<BR/><BR/>You'd think that once you release something in the wild, your hands would be tied. However, several open source projects have been very aggressive at making changes to the interfaces, often justified by just these issues.<BR/><BR/>Ritchie wanted to change the operator precedence in C after adding the shortcut operators (&&...). But, programs had been written on three systems, and he didn't want to break them. Had he made the change (which in retrospect would have been manageable) then this too would have been a change increasing integrity.Stephenhttps://www.blogger.com/profile/03934169832326108710noreply@blogger.comtag:blogger.com,1999:blog-6893032696317132921.post-20952300400999446462008-06-03T00:04:00.000-04:002008-06-03T00:04:00.000-04:00You're right, small bits help a lot (they can be m...You're right, small bits help a lot (they can be managed more accurately too). And yes, scope creep is probably is caused by the difficulty of exactly defining the problem to be solved and again, "No silver bullet" says that's one of the essential complexities of software development... there's no easy way out. Iterative/incremental process help to improve the solution stepwise, getting closer to the "target"on each cycle...Anonymoushttps://www.blogger.com/profile/17525961934302794120noreply@blogger.comtag:blogger.com,1999:blog-6893032696317132921.post-22818007368793724382008-06-01T13:46:00.000-04:002008-06-01T13:46:00.000-04:00I think small bits are important because they limi...I think small bits are important because they limit scope creep. Scope creep is really the most pernicious problem, and it happens on both sides--developer and customer. Both learn new things as the project progresses and it's hard not to incorporate the learnings. <BR/><BR/>A trivial but fun example: <A> http://www.mysoftwarefilm.com/ </A> This started out as a movie theme-based landing page for Intel's Software Partner Program and morphed into this. Yikes.Ponobillhttps://www.blogger.com/profile/05853278731598972832noreply@blogger.com