tag:blogger.com,1999:blog-11788780.post3876282299292211503..comments2023-12-29T13:22:33.104-08:00Comments on JJinuxLand: Software Engineering: Agile Programming and IDEs Considered Harmfuljjinuxhttp://www.blogger.com/profile/03270879497119114175noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-11788780.post-61133333307029465842008-07-24T13:28:00.000-07:002008-07-24T13:28:00.000-07:00> Perhaps with terse languages, it might become...> Perhaps with terse languages, it might become worthwhile to debug on paper again.<BR/><BR/>I think one attraction of pencil and paper is that it's very flexible, but it forces you to slow down and think.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-27362401273904279752008-07-24T13:26:00.000-07:002008-07-24T13:26:00.000-07:00> But few teachers would interrupt a student wh...> But few teachers would interrupt a student who was busily writing.<BR/><BR/>Very nice ;)jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-40943655922442140932008-07-24T12:24:00.000-07:002008-07-24T12:24:00.000-07:00We may be coming back to a day of pencil and paper...We may be coming back to a day of pencil and paper, hearalded by the acceptance of terse languages like Python.<BR/><BR/>In college, I would often write exact code on paper. Then I found myself getting used to idioms, and only writing difficult sections of code. Writing on paper took too long. <BR/><BR/>I might as well type "RM_Patient *pat; RM_Record *rec; for (pat = RM_FirstPatient(); pat = RM_NextPatient(pat); pat != NULL) { ...". Or I might write pseduocode: "for pat in patients:". I would often find myself typing in the pseducode, looking it over, and then expanding it line by line.<BR/><BR/>Perhaps with terse languages, it might become worthwhile to debug on paper again.Unknownhttps://www.blogger.com/profile/11493817627819491043noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-68955789916932634652008-07-24T10:58:00.000-07:002008-07-24T10:58:00.000-07:00That's funny. In the early 80's I would write mos...That's funny. In the early 80's I would write most of my programs with paper and pencil. And a lot of the time they worked first try, too. (I'm sure they were not as complicated as Mr. Bensoussan's were.)<BR/><BR/>This was a necessity: coding during high school classes, it would have been too conspicuous to set up my Apple ][ on my desk and start typing. But few teachers would interrupt a student who was busily writing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-21076304043612846182008-07-23T23:34:00.000-07:002008-07-23T23:34:00.000-07:00> The error is assuming that one set of practic...> The error is assuming that one set of practices works for all situations...<BR/><BR/>Excellent comment.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-22265001646239269242008-07-23T23:09:00.000-07:002008-07-23T23:09:00.000-07:00I remember a great, short lecture on Agile, Scrum,...I remember a great, short lecture on Agile, Scrum, and the like. The crux of the lecture was that these were all methods for correctly specifying the level of quality and depth required for differing features of a product. They worked only in areas where immediate client feedback was possible and features were separable into discrete work units. The result was a product, rapidly developed, with high quality in the features actually cared about by the customer.<BR/><BR/>This to me is crux of hitting the constantly evolving requirements target.Unknownhttps://www.blogger.com/profile/11493817627819491043noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-26465164755282065182008-07-23T07:22:00.000-07:002008-07-23T07:22:00.000-07:00The error is assuming that one set of practices wo...The error is assuming that one set of practices works for all situations. If you are designing a tight algorithms like shortest path or sorting, thinking hard about the solution will get you further along than just starting to code. On the other hand if you have to demo a user interface or check that business rules have been completely specified the best thing is to just implement it and have the user test it against real data.<BR/><BR/>And while good thinking and design make things like quicksort possible even Knuth is aware that careful design is no guarantee of perfection, after all didn't he say once: "Beware of bugs in the above code; I have only proved it correct, not tried it."?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-18933031470606056932008-07-22T14:20:00.000-07:002008-07-22T14:20:00.000-07:00> Bill Karwin said...Yep.> Bill Karwin said...<BR/><BR/>Yep.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-32286323478707260602008-07-22T14:04:00.000-07:002008-07-22T14:04:00.000-07:00Methodologies like agile can be used for good or e...Methodologies like agile can be used for good or evil purposes. I've worked at a couple of companies that claimed to be "agile" but that was just a euphemism for, "we don't like to write down requirements."<BR/><BR/>It doesn't mean agile is harmful, because you can certainly have the same irresponsible habits in a waterfall project or while using any other methodology.<BR/><BR/>I would even argue that if one does no engineering documentation, then one is not using a methodology. At that point, it can't be called engineering, or science, or even art. It can only be called "play," or at best, "labor."<BR/><BR/>If anything, agile techniques help mitigate the damage when you're stuck doing software development in a mode without project planning. At least agile principles like continuous integration and frequent interaction with the users can correct an errant course of action sooner.<BR/><BR/>The role of IDE tools is to reduce the cost of doing repetitive work. They are not a substitute for analysis and design, which are non-repetitive. But too many developers start any task by opening their IDE, instead of getting up at a whiteboard or using a pencil.Bill Karwinhttps://www.blogger.com/profile/13004667086865377598noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-62304533076772133222008-07-22T13:55:00.000-07:002008-07-22T13:55:00.000-07:00> Indeed, it can...provided that your requireme...> Indeed, it can...provided that your requirements don't change after you've begun coding.<BR/><BR/>So true.<BR/><BR/>> The man Edsger Dijkstra recommended teaching 'a language not implemented on any computers at the University'<BR/><BR/>Wow.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-23433742329308948152008-07-22T11:07:00.000-07:002008-07-22T11:07:00.000-07:00"Get it right the first time. It can be done."Inde..."Get it right the first time. It can be done."<BR/><BR/>Indeed, it can...provided that your requirements don't change after you've begun coding. Good luck making *that* happen. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-25195000115459769002008-07-22T05:05:00.000-07:002008-07-22T05:05:00.000-07:00The man Edsger Dijkstra recommended teaching 'a la...The man Edsger Dijkstra recommended teaching 'a language not implemented on any computers at the University', so students wouldn't be tempted to test their programs before they finished them. This was in an essay called 'On The Cruelty Of Really Teaching Computer Science'. That one also contained the gem: 'Software Engineering takes as it's charter: How To Program If You Cannot'.SDChttps://www.blogger.com/profile/06074492906736058141noreply@blogger.com