tag:blogger.com,1999:blog-5975524006824862804.post3819898445524789590..comments2024-02-10T02:23:08.475-08:00Comments on Paul's Pontifications: An Under-Appreciated Fact: We Don't Know How We ProgramPaul Johnsonhttp://www.blogger.com/profile/07353083601285449293noreply@blogger.comBlogger39125tag:blogger.com,1999:blog-5975524006824862804.post-43788745828395676902008-07-10T11:30:00.000-07:002008-07-10T11:30:00.000-07:00I'm new to studying software engineers, but I'm no...I'm new to studying software engineers, but I'm not new to studying other professionals. My first reaction to your post is to get angry (again) that someone in software engineering thinks that software engineers are somehow special and different from everyone else - they do a job that doesn't have process. But, getting angry doesn't do much good. So, my second reaction is to think, "Huh, isn't it interesting that we assume other people's activities can be described in process documents?" <BR/><BR/>Paul, you wrote, "In every case the core of the activity is well understood: it is written down, taught and learned." That's simply not true. Professional activity can't be reduced to process documents, can't be written down, taught, and learned in the simple manner you seem to think characterizes everything from driving a car to running a company. It's not just design work that's complicated.<BR/><BR/>Please try to be more respectful of others' unique expertise. For more info on how "process" might be a word we use to describe things after the fact, see Lucy Suchman's work on plans (<A HREF="http://www.amazon.com/Plans-Situated-Actions-Human-Machine-Communication/dp/0521337399/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1215713951&sr=8-1" REL="nofollow">1st</A> and <A HREF="http://www.amazon.com/Human-Machine-Reconfigurations-Plans-Situated-Actions/dp/052167588X/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1215713951&sr=8-2" REL="nofollow">2nd</A> editions). For more on how expertise develops that has nothing to do with written processes, see Jean Lave and Etienne Wenger's work on <A HREF="http://www.amazon.com/s/ref=nb_ss_b?url=search-alias%3Dstripbooks&field-keywords=situated+action+lave&x=0&y=0" REL="nofollow">legitimate peripheral participation</A>. The midwives, tailors, and canoers they study should fall somewhere between driving and running companies. Not your cup of tea? How about professional sports and less academic writing - <A HREF="http://www.amazon.com/Few-Seconds-Panic-43-Year-Old-Sportswriter/dp/1594201781/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1215714246&sr=1-1" REL="nofollow">becoming an NFL place kicker</A>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-22844619468191776062008-05-26T20:14:00.000-07:002008-05-26T20:14:00.000-07:00I've seen plenty of people comparing to various 'c...I've seen plenty of people comparing to various 'creative' endeavors, but in reality, writing software is fundamentally an act of *writing*.<BR/><BR/>Writing spans both more and less creative acts, from the mundane grocery list through driving directions (which actually does have a creative element when you are careful to give people the directions that they actually need (turn-based vs. landmark-based, etc.)), all the way up to stories and songs (which also can be subdivided into more and less creative works).<BR/><BR/>And yet, the process of writing prose is *identical* to writing code (except you don't have a ruthless test for correctness), and the method of learning to write prose is also identical to learning to write code.<BR/><BR/>Non-coders just assume that what we're doing is equivalent to writing a grocery list (or, at most, driving directions), when really we're usually writing narratives from short stories all the way up to multi-author shared-universe anthologies, because externally it looks the same.<BR/><BR/>So, why don't non-authors make the same assumption about authors? Many actually do, until they try to write their own Magnum Opus.<BR/><BR/>Conclusion: to raise the status of programming as a creative endeavor, we need to promote the teaching of simple coding as a basic skill, exactly the way we teach reading, writing, and mathematics.Michael Bernsteinhttps://www.blogger.com/profile/17693264522707795473noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-66376392857241812682008-05-06T03:10:00.000-07:002008-05-06T03:10:00.000-07:00Programmers should know better than anybody that y...Programmers should know better than anybody that you take a big gamble by saying "my job couldn't be done by a machine", which seems to be what this article boils down to.<BR/><BR/>Just because you intuitively know that something dropped will fall doesn't mean that isn't a law of gravity that can be taught. That people got by for millennia without it doesn't negate the huge advances that were made once it was discovered.<BR/><BR/>At the weekend I was discussing with my mother the differences between the Java coding I do in Eclipse today and the punch tape programming she did in the early 1960s, including literally cutting and pasting together sections of programs with scissors and glue. There are so many fundamental principles of modern programming that are inherent in the language and the IDE that we take for granted and which just didn't exist 40 years. I am sure in another 40 years time my son will be amused by the clumsiness and naivety of the way we do things today.<BR/><BR/>Nietzsche recognised this truth in the 1880s:<BR/><BR/>"All beings so far have created something beyond themselves; and do you want to be the ebb of this great flood and even go back to the beasts rather than overcome man? What is the ape to man? A laughingstock or a painful embarrassment. And man shall be just that for the overman: a laughingstock or a painful embarrassment. You have made your way from worm to man, and much in you is still worm. Once you were apes, and even now, too, man is more ape than any ape."<BR/><BR/>It may be safer not to say "It can't be taught" but rather "I couldn't teach it".Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-36717767038699449962008-05-05T21:50:00.000-07:002008-05-05T21:50:00.000-07:00I disagree, with very much you wrote. At first bui...I disagree, with very much you wrote. At first building houses is a variation of one theme. Sure there are different houses but the principles are "dictated" by sheer needs. For not wasting material you try to centralize things. One central point in many houses is where the heating takes places you hardly find the heating room on one side and all the consumers on the other side. <BR/><BR/>However another example is farming. You can do follow every rule but may fail, there are things one can not control. If e.g the weather turns out to be bad, you loose a whole year of work. <BR/><BR/>Or see craftmanship. One can surely automate let's say building a chair, but if you ever have the luck ot find a masterpiece of a cabinetmaker you hopefully get the difference.<BR/><BR/>Or yet another example, why are Bach, Beethoven and the like are so famous? Why not you if "making" music would be that easy....?<BR/><BR/>I'm sorry, but your first impression was the right one. <BR/>"How could anyone be so dumb as to suggest that?"<BR/><BR/>That does not mean that this is absolutly pointless, but you can send the programmers to as many course about design. If he does not care about his work and "just slaps together code" without appreciating than, he also will underperform. <BR/><BR/>If you find someone enthusiatic about programming and keen on learning then course might help. But be aware of:<BR/>http://www.joelonsoftware.com/items/2008/05/01.html<BR/><BR/>Regards<BR/>FriedrichFDominicushttps://www.blogger.com/profile/16626953518570086182noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-44979780644297515112008-05-05T20:28:00.000-07:002008-05-05T20:28:00.000-07:00As to the suggestion that mathematicians are good ...As to the suggestion that mathematicians are good programmers, I've seen no such correlation. There is too much arcane knowledge and peculiar trivia involved in software development for anyone with an exceptional grasp of logic to have much of an advantage. It is a sad fact that when working on software, patience and general creativity often get you further than sound reason. As an aside, in hiring for our own team we have found those with applied physics backgrounds have the best academic foundation for software engineering.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-89970861529658322442008-05-05T20:14:00.000-07:002008-05-05T20:14:00.000-07:00This reminds me of the moment I decided to leave m...This reminds me of the moment I decided to leave my job and look for a better opportunity. I was sitting down in a meeting with my boss discussing a particular project that I was about to start working on. Then he asked me to explain to him (a non developer...never was never will be) exactly how I was going to solve the problem at hand. He wanted right then and there a step by step plan of how I planned to solved the problem. That was the moment I realized he didn't get my job and never would.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-290516665884766862008-05-05T14:31:00.001-07:002008-05-05T14:31:00.001-07:00I thought this was fairly obvious, but nobody seem...I thought this was fairly obvious, but nobody seems to have mentioned it. Imagine you're trying to write software to solve some problem - e.g. adding two numbers. Let's pretend there exists some "process" to write an algorithm to solve said problem. What would it look like? (at a fairly high level)<BR/><BR/>1.) tell computer to accept two numbers as input.<BR/>2.) tell computer to add second inputed number to <BR/>first inputed number (How/what level you do this at isn't really important)<BR/>3.)tell computer to output the number resulting from this addition.<BR/><BR/>Something is fishy about this, of course. It's that imbedded in our "process" is exactly the algorithm that we wanted to write. In other words, any "process" one might follow to write an algorithm is going to contain the algorithm to begin with. How you actually go about commanding the computer to do this is a question of syntax. This should look familiar from Theory of Comp.Unknownhttps://www.blogger.com/profile/06838308729625751791noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-3282952418422995762008-05-05T14:31:00.000-07:002008-05-05T14:31:00.000-07:00There is another profession that trains by copying...There is another profession that trains by copying ever previous works. Starting with small exercises and working upwards. It's called art school.<BR/><BR/>And the reason is simple.<BR/><BR/>Most of the skills that most professionals use are basically analysis skills. They have a bunch of rules for breaking things down and then reacting. Be it visual recognition of road signs, or a set of rules of thumb for negotiating a balance sheet and a cash flow statement.<BR/><BR/>But all design is synthesis. Take a set of inspirations and a set of constraints and create something new that fits in the hole. <BR/><BR/>That is why programming is unpredictable. Some people can see the solution, and some can't. And a whole lot of variation on the quality of the solution envisaged by those who can.Anonymoushttps://www.blogger.com/profile/07555989787959778978noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-12614235210859255382008-05-05T13:45:00.000-07:002008-05-05T13:45:00.000-07:00I also think that using a process analogy to other...I also think that using a process analogy to other professions, you ignore the concept of quality. There may be a structure and process to creating a legal brief or a medical diagnosis, but following that process does not insure a quality legal brief or medical diagnosis. It can mask a poor quality solution. Just as a working application can mask poor coding.planetmcdhttps://www.blogger.com/profile/00107197218778096498noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-13760465719557199322008-05-05T12:01:00.000-07:002008-05-05T12:01:00.000-07:00There's actually a very popular book written, that...There's actually a very popular book written, that describes how WRONG the author of this article is... <BR/><BR/>http://www.pragprog.com/the-pragmatic-programmer/extracts/coincidenceAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-43593221752130963572008-05-05T11:53:00.000-07:002008-05-05T11:53:00.000-07:00Culture, I think, is the key reason why we don't w...Culture, I think, is the key reason why we don't want to admit that we know how to program. Another common problem is that most programmers make it harder by over-thinking their solutions. It is 'harder' until you learn that it isn't. <BR/><BR/><A HREF="http://theprogrammersparadox.blogspot.com/2008/04/creatively-speaking.html" REL="nofollow">Some more thoughts on creativity</A><BR/><BR/>Paul.Paul W. Homerhttps://www.blogger.com/profile/02349253120538728302noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-58084278555091875842008-05-05T10:51:00.000-07:002008-05-05T10:51:00.000-07:00There seems to be a hidden assumption in your post...There seems to be a hidden assumption in your post - that we all have the same mental hardware, but some are lacking in mental software. I am pretty sure that the first part is not true.<BR/><BR/>As a culture, we have no problem accepting that people are born with different physical potentials. I once heard an exercise physiologist talk about Lance Armstrong. He said the average person could train for years, while Lance sat on the beach and Lance would still beat them.<BR/><BR/>The way I would explain the 10:1 ratio is that natural mental potential in programming, along with hardwork, motivation and a passion for programming, creates kind of a snowball effect on ability.<BR/><BR/>I also strongly disagree that this phenomena is limited to just a few disciplines. I think it is the case in most disciplines. What sets programming apart is the observability of the results. <BR/><BR/>One of the many hats I wear is in marketing. There are so many factors that affect the success of a product, it is difficult to figure out how much a marketer contributed to the process.<BR/><BR/>All that said, I agree with the others who have mentioned the importance of motivation. At my company, top producers are dis-incented. Top producers do not get paid that much more than bottom producers, yet over time the company expects (needs) the top producers to keep producing at a high rate. This can be really stressful. Every time you do something amazing, that becomes the expectation for you. After a while, there is a strong incentive to stop doing amazing things. Maybe instead of looking for ways to make the programming process more teachable, companies would have more luck creating incentive structures that would encourage higher productivity.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-12299159124714735332008-05-05T10:46:00.000-07:002008-05-05T10:46:00.000-07:00Coincidentally, software design is also by far the...Coincidentally, software design is also by far the hardest thing (and somewhat underestimated) to master. Rather than all the processes and algorithm stuff at university, I would really have appreciated design and architecture (patterns, anti-patterns etc.) as a first-class... class.Casper Banghttps://www.blogger.com/profile/09493174484116672294noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-85549712237678458462008-05-05T09:39:00.000-07:002008-05-05T09:39:00.000-07:00Most of the posts appear to confirm the 'hand wavi...Most of the posts appear to confirm the 'hand waving theory' of software development: stare into space, become enlightened, commit abstract thoughts to symbols on a screen, cross ones fingers that it is a functional program.<BR/><BR/>When I do software development, it is something similar to the 'scientific method. <BR/><BR/>Step zero point one: spend time learning about data structures and program flow<BR/><BR/>Step zero point two: spend time how a specific language implements tis flavour of data structures and program flows<BR/><BR/>First step: what is it that needs to be accomplished?<BR/><BR/>Second step: what are the user actions, what is the data source and format, how does it need to be manipulated, and what is the output?<BR/><BR/>Third step: by selecting appropriate data structures to match data inputs, calculations, and outputs, program statics can be implemented<BR/><BR/>Fourth step: Figure out the sequence of steps to get the data in, calculate on it, and then get it out.<BR/><BR/>Fifth step: test the theory and confirm that it matches the specification provided in step one.<BR/><BR/>Sixth step: pat your self on the back for successfully writing a program.<BR/><BR/><BR/>Does that satisfactorily define the methodology one uses to program?<BR/><BR/>Of course, the secret is in the appropriate definition of the question, the successful selection of appropriate data structures, and the proper ordering of program flow statements. But each of those should be able to be defined in a recursively more detailed manner.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-61519541791270602008-05-05T09:36:00.000-07:002008-05-05T09:36:00.000-07:00I thnik mamny people, when faced with a design pro...I thnik mamny people, when faced with a design problem, freeze up in there thinking and right afterr hearing teproblem relaize theydont knw whatt dod net. Pnac ensues and finally end up settiflt hing thmi comnd ds mind. Tm sequo fques tions rto ffollow bllaaa blaaaaaaaaa wwwwwzzzzzzzzzzzAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-61402553247851150702008-05-05T09:20:00.000-07:002008-05-05T09:20:00.000-07:00It's easy to make assumptions about other professi...It's easy to make assumptions about other professions. Your point is well taken that non-programmers just don't get how it really works. I'm with you there. But then you proceed to apply a double standard and assume you know how every other profession works to make your claim that programming is different than everything else. <BR/><BR/>As an entrepreneur, I've worn a lot of hats. I can tell you that the "absence of a process" phenomenon is a lot more common than you'd think. Marketing, consulting, sales... none of these have learnable, repeatable processes. Sure -- there are frameworks, but they're just that. They spell out what you do but not how you do it. <BR/><BR/>Good read, though. Thanks for posting.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-40079287458047917312008-05-05T09:14:00.000-07:002008-05-05T09:14:00.000-07:00Test Driven Development is a process for programmi...Test Driven Development is a process for programming. So is Dijkstra's method of Correctness by Construction. There are similar processes for design at that level of detail in a variety of disciplines. <BR/><BR/>You may not know how you program, but I certainly do.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-7742620675388475812008-05-05T09:02:00.000-07:002008-05-05T09:02:00.000-07:00As an architect, I feel obliged to point out that ...As an architect, I feel obliged to point out that most McMansions are not designed by architects, they are designed by builders.<BR/><BR/>The former are focused on a myriad of factors: aesthetics, quality of space, sustainability, etc.<BR/><BR/>The latter are focused on: $. Which is why their houses usually suck.<BR/><BR/>More to the point, here is a "process" for solving problems (the little intersecting area in the Venn diagram of programming and architecting):<BR/><BR/>1) Define the problem in a manner which can be measurably solved.<BR/><BR/>2) Imagine as many solutions to that problem as possible. <BR/><BR/>3) Define the client's priorities. (speed, cost, style, etc.)<BR/><BR/>4) Choose the best solution and implement it.<BR/><BR/>5) Profit !!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-14835865507652890622008-05-05T08:55:00.000-07:002008-05-05T08:55:00.000-07:00There is actually a "program". Aristotle wrote abo...There is actually a "program". Aristotle wrote about it - but it has been a taboo since the church banned his description of the thinkable process of how we create in the middle ages. I have the vital ingredients in my digestion from 2005: Get Rid of Our Final Taboo! - The Human Ability to Create is Thinkable:<BR/><BR/>http://home4.swipnet.se/~w-44374/hyperdialog/download.htmUnknownhttps://www.blogger.com/profile/05213790075128905798noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-21032248347949336822008-05-05T08:38:00.000-07:002008-05-05T08:38:00.000-07:00Excellent point you've made here. I'm trying to c...Excellent point you've made here. I'm trying to come up with a way of describing the process of programming and I'm drawing a blank. The best I can say is that it either happens right away, or first I do some Googling on the parts I'm not sure of, read some things, and then it happens eventually when I've learned enough to synthesize together to solve the problem.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-4018846358198456852008-05-05T08:26:00.000-07:002008-05-05T08:26:00.000-07:00Software is a design activity, not a production ac...Software is a design activity, not a production activity. And that does make it impossible to proceduralize.<BR/><BR/>But we can <A HREF="http://leansoftwareengineering.com/2008/05/05/boehms-spiral-revisited/" REL="nofollow">break it down a little</A>, to help people understand and get better at it, as you hoped for.<BR/><BR/>Of course, this kind of breakdown is still only a small part of the picture. It's still all magic in the end. :)Bernie Thompsonhttps://www.blogger.com/profile/02565183479538803193noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-54592414836816836612008-05-05T08:23:00.000-07:002008-05-05T08:23:00.000-07:00Jack Reeves said the same thing back in 92 - the s...Jack Reeves said the same thing back in 92 - the source code is the final design: <A>http://www.developerdotstar.com/mag/articles/reeves_design_main.html</A><BR/><BR/>Also, <A>http://softwareindustrialization.com/TheTruthAboutSoftwareEngineering.aspx</A>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-50297619039358742442008-05-05T07:59:00.000-07:002008-05-05T07:59:00.000-07:00I beg to differ, good sir! There is a clear proces...I beg to differ, good sir! There is a clear process for programming, and it was discovered for Feynman:<BR/><BR/>1. Write down the problem<BR/>2. Think very hard<BR/>3. Write down the answer<BR/><BR/>(Your mileage my vary on #3)Jake Voytkohttps://www.blogger.com/profile/15856566300563136831noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-40258137779025869972008-05-05T07:52:00.000-07:002008-05-05T07:52:00.000-07:00When I program, I sit there, staring into space fo...When I program, I sit there, staring into space for a while, and then I write.<BR/><BR/>I'm visualising how the code needs to flow. And visualising isn't really the right word - I don't see shapes and colours. I see what-ifs and when-ifs.<BR/><BR/>And I don't think it has anything to do with mathematics. They do overlap in places, yes, but they are different disciplines.Nekohttps://www.blogger.com/profile/03859610469016917704noreply@blogger.comtag:blogger.com,1999:blog-5975524006824862804.post-22451977732522468862008-05-05T07:51:00.000-07:002008-05-05T07:51:00.000-07:00I can't believe all the people saying all the offi...I can't believe all the people saying all the offices are all the same. I picture my mom saying Ubuntu and Windows are the same because they both have shortcuts on the desktop, drop down menus, off button ...Anonymousnoreply@blogger.com