heusserm's Journal http://use.perl.org/~heusserm/journal/ heusserm's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:22:24+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 heusserm's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~heusserm/journal/ Agile Project Management http://use.perl.org/~heusserm/journal/26796?from=rss I'm reading APM, the new Highsmith book. I really stuggled with this book - Highsmith spends the first hundred pages or so hitting us over the head with the concept of agility. Blah blah blah, the factory analogy doesn't work, blah blah blah the best products come from self-organized teams, blah blah examples, blah blah more Philosophy I allready agree with. <br> <br> Then he finally gets to the good stuff. Most of it is recompiling and repacking the existing body of knowledge, but after sixty more pages, I do have a couple of ideas to take home and reconsider. <br> <br> Overall, I'd say the book is best framed as an introduction to agile methods for people only familiar with old-school PMI/Waterfall projects. The intended audience for this book actually _do_ need a gentle introduction. That just makes me<nobr> <wbr></nobr>... very sad. heusserm 2005-09-20T05:40:36+00:00 journal Emerson http://use.perl.org/~heusserm/journal/26795?from=rss I just read the two articles by Brian Marick on Emerson, Methodologies and Ontology. Really Interesting Stuff, but it was dense. It deserves a second and third read. Marick points to Kent Beck, who wrote that, essentially, when the code is trying to tell you what to do, try to follow it. According to Marick, developers are in a dance of agency with the software we write, as the software emerges. (You can read it for yourself, it's good stuff: <a href="http://www.testing.com/writings/methodology-and-ontology.pdf">this</a> and <a href="http://www.visibleworkings.com/papers/agile-methods-and-emerson.html">this</a>) <br> <br> Now, I used to be a huge Issac Asimov Fan, and I remember one essay where he talked about how his characters essentially 'take over' the story. One moment, he is directing the stoy, the next, the characters are simply doing what they would do next. That's flow for Asimov, getting to the place where story is writing itself, and he's a kind of passenger. I think this is what Marick means by unreflective actions "actions people take because they are the obvious things to do in <br> <br> I think Emerson was trying to get at the incredible potential of humanity - I know that Asimov was. I don't see any big disparities between the Emersonian worldview and my own faith - for example, we Catholics believe that creativity is an attribute of God's Character, and thus expressing that attribute is an act that is essentially divine. "Joyous" is about as close as you can get in secular terminology. <br> <br> Which brings me to why I love what I do. I love it so much that don't want to stop, even on a Sunday at 9:30AM over the rockies. If development is a road race, the "Process Improvement" folks found a single road rut and then created a process which must always be followed, regarless of weather or not your particular road had a rut. In the end, driving around those extra gates and cones can take more time than driving through. The agile folks are focusing on removing the cones and gates that don't make sense; they want the simplest commute that could possibly work. <br> <br> IMHO, The next step will be a methodology that puts a better engine in the car - and that reads more like mentoring and coaching and skills improvement, combined with a light-weight, description ("how we generally think about problems here") framework over a prescriptive ("do it this way or else") methodology. <br> <br> What's my point? What we're doing here, all this talk about constant improvement and how to do it better - that _is_ the methodology. Expanding our experiences and knowledge. Sharpening the saw. I'm having a blast. Thanks for being along for the ride. heusserm 2005-09-20T05:39:14+00:00 journal BusinessWeek, PeopleWare, Microsoft ... http://use.perl.org/~heusserm/journal/26794?from=rss Joel Spolsky wrote that when he went to the supply cabinet as an intern, there was a large stack of copies of PeopleWare right next to the pens and paper and staplers. The company was Microsoft. Criticize MS for it's monopolistic or anti-competitive or closed-source behavior all you want, they knew how to hire the best and keep them productive. <br> <br> I picked up BusinessWeek because the cover story was on the brain drain at Microsoft. The article claims that Microsoft is becoming a big company - slow, process-heavy, hard to get anything done. Steve Ballmer recently cut health benefits, cut vacations for new employees, stopped the free towel service at the on-site fitness club, proposed seven-figure salaries to key VP's, mid-Six figure salaries to group managers, and pegged staffer's salaries to the industry average. Also, he had an interview with BusinessWeek where he talked like a press release and didn't answer pointed questions. His answers weren't completely evasive -- at least, not all of the time. I've seen worse, but it was disappointing. <br> <br> Which tells me that senior brass at Microsoft is now behaving as if they never read PeopleWare. Maybe they never have. Who knows. The article said that Ballmer was trying to transform the company as described in Jim Collins "Good To Great." News Flash: Microsoft _WAS_ great. Collin's previous book was called "Built to last", and MS could have been a case study. So now they are experiencing record profits, sitting on $60 billion in cash, and they cut insurance so employees have a $40 copay. <br> <br> What the heck am I missing? Seriously - what am I missing? Has the leadership at MS forgotten how to manage software development, or is the article just biased? heusserm 2005-09-20T05:35:48+00:00 journal Potholes PT 2 http://use.perl.org/~heusserm/journal/26721?from=rss A snip of the intro to my talk to the Indiana QA Conference on "Magic Pixie Dust: Improving the pace of software delivery through People" is below. I really like the methodology stuff, but it doesn't fit - I may cut everything after "share a few with you." Mostly I wrote it up here to tie it back in with the potholes analogy. <br> <br> Have you ever been faced with an impossible deadline, where senior management tells you that adding staff, moving the date, decreasing quality, or removing features was "simply unacceptable?" After all, your job is to solve problems, not to whine. <br> <br> It&#8217;s seems as if Senior Management wants you to spread some magic pixie dust and make everything better. <br> <br> Well, yes, and to some extent, I believe that&#8217;s possible. Or, that is to say, there are tradeoffs you can make to improve the pace of development &#8211; and I would like to share a few with you. <br> <br> 1st Generation Methodologies were about preventing common mistakes.<br> The problem was that code reviews took time to organize, and this increased time-to-market and waste.<br> So our 2nd Generation Methodologies reacted to that to remove waste.<br> XP puts the customer in the same room, so you never have to wait a week to get an answer when you&#8217;re blocked.<br> XP moves people to more generalist roles, rather than specialists, which decreases handholding, confusion, friction, and points of failure. Pair Programming focuses a group on the task, eliminating a great deal of web browsing and goofing off.<br> <br> So 2nd Generation Methodologies remove waste. Our theory is that 3rd generation methodologies will improve the pace of development.<br> <br> How do you do that? Some techniques, like exploratory testing, work to make the practitioner more effective. What I&#8217;m going to talk about today are techniques to accelerate innovation within teams, and it&#8217;s consequences. heusserm 2005-09-14T16:59:16+00:00 journal Pothole Methodologies http://use.perl.org/~heusserm/journal/26712?from=rss Precursor: I don't like artificially created generations or bogus models. In the post below, I use this first/second/third generation methodology paradigm - mostly because I want to get this post out quickly. It's a contrivance I'm using to describe generalities - please don't think i'm taking myself too seriously.<nobr> <wbr></nobr>:-) <br> <br> Also note that methodology is just a fancy way of saying "the way we think or conceptualize our approach to solving problems around here." I use the word a lot in the post, I'm open to other options for word choice. <br> <br> And now, on with the show<nobr> <wbr></nobr>... <br> <br> Sean McMillan and I were talking about the evolution of methodologies today at lunch. He had some really interesting observations.<br> <br> Think about the first methodologies that came out. (Waterfall, various customized versions of the waterfall, and, eventually, the uber-model, the CMM) Try to read between the lines. These models were all about FEAR: Fear that management does not have control, fear that the customer will not accept the finished work, fear that the project will be late, over budget, etc, etc. <br> <br> So these first methologies addressed that fear in a number of ways: They froze requirements, they forced requirements "sign off", they insist on artifacts that have review, are version controlled, audited, etc - they tried to make software development "defined, repeatable, stable, and measured", they try to <i>institutionalize</i> process so that management is not dependent on the <i>heroics</i> of any individual, they eliminate "single points of failure", etc. <br> <br> A lot of those early methodologies are monday-morning quarterbacking: "We noticed one time we had this one problem, so we are going to insert this new step in EVERY project to eliminate the risk of that problem." <br> <br> Sean made a methaphor of a pothole methodology - We notice that we ran over some potholes and it gave us some car trouble, so we place gates around every pothole we see. Requirements Review, Code Review, Test Case Review, Requirements Signoff, Configuration Management, have a separate team move code into production<nobr> <wbr></nobr>... this list goes on. <br> <br> As the gates constantly propigate, we find that <i>slowing down to drive around the gates becomes more of a hassle than we had before!</i> <br> <br> This makes complete sense to me. In "Quality Software Management" Jerry Weinberg makes the assertion that the "level 2 repeating" organization was a fantasy created by non-technical management, wheren they manage to wrestle control back from the developers. After all, at level 2, any individual developer is expendible; the <i>process</i> is king. <br> <br> Sidebar: I've read a <i>LOT</i> of the stuff that came out of the academic/government sector about methodologies. One of the things I consistently notice is the use of big words to sound important and the lack of philisophical depth. This is a real problem if you're trying to develop software. On the other hand, if the <i>REAL</i> goal is to remove fear from executives and give them a feeling of control<nobr> <wbr></nobr>... <br> <br> Eventually, people begin to realize that dealing with fear is not good; instead we need to be adults, taking calculated risks and living with the consequences. We need to drive out fear in the organization (think Deming) and instead live with uncertainty. This brings us to what we called (again, lack of a better term) "second generation" methodologies that are a backlash to the first. XP is a great example - the whole point is simplest process that could possible work, combined with just enough safety nets that you can live with a little risk. Stop living in fear that the developers won't hit some meaningless deadline for a huge piece of work, and instead have a simple working system up in weeks and add features as you go. Duh. <br> <br> As I said before, these second-generation methodologies are, for the most part, just a backlash to the first. They are saying "well, heck, too much process didn't work. Let's take away and take away and take away process untill we have something workable." <br> <br> So, second generation languages are still caught up in fear - that is, driving it out. That's half the sales pitch. If we just take those gates down, maybe pave the road, we will get home faster. <br> <br> The next logical step is how to stick a turbo-booster on the car: To find ways to keep developers focused on work and improving the pace of delivery of software. (Hey, I'm giving a <a href="http://www.iqaa.org/events/training/07-20-05-reg/index.php">talk</a> on that on Oct 7th in Indiana, but it's not a methodology yet.)<br> <br> Test-Driven Development is pretty good example of this - it transforms testing from a boring, manual task into a coding task. It transforms API design (function signatures) from a "design" task into a coding task; exercising the API to run the tests. Developers like to code; it makes testing a coding a task they can then automate, so they can do more coding. <br> <br> What other 'tasks' of a methodology actually force developers to do a better job, or keep them focused on the job at hand? Pair Programming could keep them from surfing the web, and I'm sure there are more. Every XP book says that local adaptors will 'customize' XP to fit. Sean's theory is that those customizations contain the secret sauce to improvement. If the theory above holds true, we just have to find the cutting edge shops that are allready doing some of these practices, interview them, and we'll be defining the leading edge of this 3rd generation methodology movement. <br> <br> I'm willing to give it a shot; in fact, I'll be talking to folks about it tomorrow in the office, next week at the Better Software Conference in San Francisco, then next month at the Indiana QA Conference. <br> <br> The whole idea needs more work, but I wanted to jot something down before I forget. I'm curious as to comments<nobr> <wbr></nobr>... heusserm 2005-09-14T02:05:19+00:00 journal Andy Lester in West Michigan http://use.perl.org/~heusserm/journal/26711?from=rss Andys Lester will be speak to the Grand Rapids Perl Mongers and the local Extreme Programming User's Group on Oct 25th. <br> <br> At Lunch, he'll be presenting a guide to authoring CPAN modules to GR.PM - grand-rapids.pm.org at the Priority Health Conference Center. <br> <br> That evening he'll be at <a href="http://xpwestmichigan.org/">XP West Michigan</a>, speaking on agile project estimation techniques; it's same talk he gave at the Open Source Conference this year. <br> <br> Andy is the co-author of <a href="http://www.amazon.com/exec/obidos/tg/detail/-/1590594541/qid=1126661198/sr=1-1/ref=sr_1_1/002-0598052-6520805?v=glance&amp;s=books"> Pro Perl Debugging</a> and sole author of <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0596009437/qid=1126661198/sr=1-2/ref=sr_1_2/002-0598052-6520805?v=glance&amp;s=books">MAc OS Tiger in a nutshell</a>. <br> <br> I'm geeked. heusserm 2005-09-14T01:31:58+00:00 journal test http://use.perl.org/~heusserm/journal/26577?from=rss It's been - well over a year since I've posted. Checking to see if it still works, and trying to keep my account active.<nobr> <wbr></nobr>:-) heusserm 2005-09-02T19:59:26+00:00 journal Software Development _is_ writing http://use.perl.org/~heusserm/journal/17083?from=rss &nbsp; &nbsp; Every now and again, I'll read an article about how in the 1980's and 1990's, Japan tried to create "software factories" that were supposed to kill american business the way Japan's industrial sector had killed american manufacturing. <br> <br> &nbsp; &nbsp; Except that it never happened.<br> <br> &nbsp; &nbsp; Why? In "Agile Software Development With Scrum", Ken Schwaber argues that the manufacturing analogy is inappropriate, even harmful to software development. In his words: <br> <br> &nbsp; &nbsp; <i>"For a defined control process to work, these methodologies must define each process with enough accuracy that the resultant noise does not interfere with its repeatability, or the predictability of the outcome. I can watch engineers define a class numerious times and write down a definition of what I saw happening. This process definition is only useful if it can be repeated over and over to generate solid class descriptions. If my obersations are general or loose because many variations are employed to derive a class, the process definition is useless. The process definition will be so weakly defined that, when it is employed, it does not generate repeatable results. When an activity is so complex or complicated that a different defition is required each time it is executed, the activity cannot be abstrated into a process definition."</i> <br> <br> &nbsp; &nbsp; That is my problem with heavy-weight methodologies: They take what is essentially creative work and try to boil it down into a manufacturing process. It doesn't work. Software is different each time, just like writing.<br> <br> &nbsp; &nbsp; Imagine telling a writer how to write! Oh, you can give them guidlines and heuristics. You can talk about transitions and prose and style. You can even set up a working environment for them or give them requirements for the output of the piece.<br> <br> &nbsp; &nbsp; The thing is, the implementation of the piece can be completely different between two people, and yet both articles can satisfy the requirements completely. Unless you are doing cut-and-paste script-kiddie work, software development is not Manufacturing -- it is writing.<br> <br> &nbsp; &nbsp; I once read somewhere (And I was certain it was the intro of Effective Perl Programming about Randal Schwartz, but now I can't find it) that through the process of writing, the author realized that he was not a programmer who knew how to write, but he was actually a writer who knew how to program.<br> <br> &nbsp; &nbsp; I do believe that is one of the mose congruent statements about programming that I have ever read. heusserm 2004-01-29T13:43:32+00:00 journal Outsourcing http://use.perl.org/~heusserm/journal/17045?from=rss A few weeks back, I wrote some potential articles to the editors of Software Quality Engineering. After some back and forth discussions, they decided to <a href="http://www.stickyminds.com/sitewide.asp?Function=WEEKLYCOLUMN&amp;ObjectId=6975&amp;ObjectType=ARTCOL&amp;btntopic=artcol&amp;tt=WEEKLYCOL_6975_title&amp;tth=H">print one of them</a>. heusserm 2004-01-27T17:57:32+00:00 journal Professional Recognition of Testers http://use.perl.org/~heusserm/journal/16971?from=rss <p>I just posted this to Danny Faught's SWTest-Discuss Email List:</p><p>I think I've hinted at this before:</p><p>IMHO, pure software functionality testers are likely to lack professional status, lack authority, lack respect, be likely to be laid off, etc, etc.</p><p>By "pure" I mean "People who don't do anything else." In nursing terms, all a pure tester can do is operate equipment to take readings.</p><p>To gain professional credibility, we need to grow the field to be more of a nurse-practioner who is involved from the beginning. The "Uber-Tester" would then test the requirements, be able to understand design issues, perform usability and GUI (Interaction Design) assistance on the prototype before the real code is developed, help the customer write acceptance tests, set up and assist with code review, as well as set up and run system tests. The Uber-Tester could also own the bug tracking system.</p><p>Johanna Rothman wrote an article on "First Class Testers" in this month's Better Software that covers the general idea.</p><p>IMHO, Software Quality Engineering is a discipline of Software Engineering. (Notice what Cem Kaner is a professor _OF_.) Testing is a subset of that discipline. We will never have have professional recognition among testers until we admit that justification by testing alone is insufficient.</p> heusserm 2004-01-23T12:37:15+00:00 journal Test::More::Evangelical http://use.perl.org/~heusserm/journal/16528?from=rss <blockquote><div><p>Re: STAREAST, May 17-21 2004, The Rosen Centre Hotel, Orlando, FL<br> <br> We are pleased to welcome you as a Track Speaker at STAREAST 2004<nobr> <wbr></nobr>...</p></div> </blockquote><p> This begins my letter of acceptance as a speaker at <a href="http://www.sqe.com/stareast/">Star East 2004</a>. I'll be speaking on Test Driven Development in Perl. Obviously, this would never have happened without Scwhern, Chromatic, Lester, Scwartz, Wall, and Kent Beck. <br> <br> Anyone want to peer review a 1-hour presentation?</p> heusserm 2003-12-29T02:15:14+00:00 journal Net::Ftp.pm http://use.perl.org/~heusserm/journal/16463?from=rss <p>So, I've got some code that uses Net::Ftp.pm.</p><p>Now and again, I have to transfer really really big files. The whole system is automated, but it hangs and dies on a call to $ftp-&gt;put($filename).</p><p>So, the app dies, the sysadmin re-starts it, and it starts over again, transmitting the same file, hangs and dies. Never gets to the rest of the files, some of whom go to FTP sites that actually, you know, work.</p><p>I'm thinking of refactoring the code so that it just reports error instead of die-ing. Then it can process the ones that might work, and then come back and try again with the big file that only works rarely.</p><p>To do so, I'm planning on wrapping an eval block around the offensive code, and checking $@ to see if the call 'dies.'</p><p>Does this sound like a good approach?</p><p>regards,</p> heusserm 2003-12-22T18:45:09+00:00 journal Generic Unit Tests http://use.perl.org/~heusserm/journal/16165?from=rss <p>Someone on JoelonSoftware wanted to figure out how to do automated unit tests in TCL, so I wrote up this post:</p><p>Mike Scwern wrote test::More for Perl as well as test::Tutorial.</p><p>http://magnonel.guild.net/~schwern/talks/Test_Tutorial/Test-Tutorial.pdf</p><p>Basically, I'd suggest making a simple library with functions like this:</p><p>sub tests(int);<br>sub eq(string, int, int);<br>sub eq(string, bool, bool);<br>sub eq(string, double, double);<br>sub eq(string, string, string);<br>sub ok(string, bool);</p><p>The psuedo code looks something like this:</p><p>GLOBAL iTestNum int;<br>sub tests(i int)<br>{<br> &nbsp; &nbsp; printf("1..%d\n", i);<br> &nbsp; &nbsp; iTestNum = 1;<br>}</p><p>sub ok(s string, b bool)<br>{<br> &nbsp; &nbsp; if (b)<br> &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; print("ok %d - %s\n", iTestNum, s);<br> &nbsp; &nbsp; }<br> &nbsp; &nbsp; else<br> &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; print("not ok %d - %s\n", iTestNum, s);<br> &nbsp; &nbsp; }<br> &nbsp; &nbsp; iTestNum++;<br>}</p><p>sub eq(s string, i int, i2 int)<br>{<br> &nbsp; &nbsp; if (i==i2)<br> &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; print("ok %d - %s\n", iTestNum, s);<br> &nbsp; &nbsp; }<br> &nbsp; &nbsp; else<br> &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; print("not ok %d - %s\nGot %d\nExpected %d\n",<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; iTestNum, s, i, i2);<br> &nbsp; &nbsp; }<br> &nbsp; &nbsp; iTestNum++;<br>}<nobr> <wbr></nobr>//---End Psuedo Code</p><p>So your output to STDIO looks like this:</p><p>1..5<br>ok 1 - Foo with valid input<br>ok 2 - Foo with invalid group number<br>ok 3 - Error Message for invalid group number<br>not ok 4 - Foo with invalid date<br>not ok 5 - Error Message for invalid date<br> &nbsp; &nbsp; Expected - "Date 10/35/2003 is not a valid date"<br> &nbsp; &nbsp; Got - ""</p><p>Obviously, your function is something like:</p><p>func foo(iGroupNum int, sDate string) returns BOOL;</p><p>--All this is pseduo code you can write up in any langauge.</p><p>If you write it correctly, you can pump it through Test::Harness or Prove automatically.</p><p>That's the 5 minute version, anyway. You can write test harnesses in any language. (If you die after test 3 because of an unhandled exception, you know you SHOULD have had 5 tests because of the 1..5, so that too is a test.)</p><p>Thoughts? I think there's some interesting potential stuff about a "Generic Unit Test Framework", but it needs more work<nobr> <wbr></nobr>...</p> heusserm 2003-12-04T16:35:47+00:00 journal The obligatory 'story card picture' http://use.perl.org/~heusserm/journal/16121?from=rss Some day, I'm going to write some articles on my XP experiences. For the time being, all I've got is <a href="http://www.csis.gvsu.edu/~heusserm/CS/XP/StoryCards.jpg">this picture</a>. heusserm 2003-12-02T13:26:06+00:00 journal Structured Exception Handling? http://use.perl.org/~heusserm/journal/16003?from=rss So, I just walked a co-worker through how to use eval/die to catch errors before they propigate. <br> <br> (He wanted to use a signal handler to see if a system() call was running rogue. Pretty cool stuff.)<br> <br> Does that mean I can put "structured exception handling" on my resume?<nobr> <wbr></nobr>:-) heusserm 2003-11-25T15:33:31+00:00 journal On Perl 6 http://use.perl.org/~heusserm/journal/15900?from=rss I must admit, I thought Perl 5 was "good enough" and didn't really want to spend the time to figure out perl 6.<br> <br> Then I saw <a href="http://matt.diephouse.com/presentations/Perl6Essentials.pdf">Matt Diephouse's Presentation on Perl 6</a> <br> <br> All the pure OO guys who want intutive OO syntax, run time type information, templating, strict type checking and structured exception handling? It's in there.<br> <br> All the perl purists who want nothing to do with types, exception handling or required OO syntax?<nobr> <wbr></nobr>... well, it's in there.<br> <br> Want a "Switch" Statement? You can have something better: given/when.<br> <br> Want typed paramteres? It's in there. Don't want typed paramteres? It's in there.<br> <br> Simply put, Perl 6 provides the features of C++ or Java that OO people "need", but doesn't <i>require</i> them.<br> <br> Of course, some lady with a resturant has been saying that since the perl 6 project started, but it took more than 5 minutes for me to "get it".<br> <br> IMHO, the biggest problem with perl 6 is marketing. Instead of calling it "P6/P" I think it should be called "P6EE." And the parrot runtime should have a fancy name like "The e-CLR" (The Extensible Common Language Runtime). With a few more bells and whistles, we might even be able to the get the pointy-haired-boss crowd<nobr> <wbr></nobr>... <br> <br> Sadly, Unlike Dr. Maher, that forces me to ask the question "Hey, are we really sure we <i>want</i> the pointed haired boss crowd?"<br> <br> That one is going to take some thinking. heusserm 2003-11-20T13:20:40+00:00 journal Time to refactor my website http://use.perl.org/~heusserm/journal/15864?from=rss I'm afraid my website is slowly becoming a big ball of mud. (It "Smells Bad")<br> <br> Basically, it was organized as three blogs in three vaguely-overlapping subject areas, but then I got a blog on use.perl.org<nobr> <wbr></nobr>... so it's four. Sorta.<br> <br> <a href="http://www.csis.gvsu.edu/~heusserm">Here's the site</a> <br> <br> Here's my thoughts:<br> <br> Reorganize the site:<br> <br> (A) Leadership-Ish Stuff<br> (B) So you're thinking about an Advanced Degree in CS? PPTs, papers, and programs. (Think of it as "OpenCourseWare Lite")<br> (C) Faith<br> (D) Software Development<br> (E) Quality Through Agile Methods<br> (F) Perl<br> (G) Professionalism in software development<br> <br> I'm thinking of marrying D&amp;E or even D, E, and F. Maybe G as well. The span of control, as it stands now, is too big.<br> Also, the terms need to be shorter.<br> <br> Thoughts? heusserm 2003-11-19T12:59:49+00:00 journal lil' vi help ... http://use.perl.org/~heusserm/journal/15554?from=rss <p>I've got a program that looks something like this:</p><p>#Begin code<br>$sth-&gt;bind_param(1, 'blahblah');<br>$sth-&gt;bind_param(2, $somevar);<br>#End Code</p><p>I want to change it to this:</p><p>#Begin code<br>$sth-&gt;bind_param(1, $somevar);<br>$sth-&gt;bind_param(2, 'blahblah');<br>#End Code</p><p>Here's how I would do it in VI:</p><p>Go to the 1. Type 'I' (Insert Mode), change it to 2. Go to the 2, change it to 1. Type 'ESC'</p><p>Do to the first line. Press DD (Delete). Arrow down. Press P (Paste). Arrow up, and DD the blank line inserted. Arrow down, press I (Insert), backspace, hit return, then fix the indenting on the next line.</p><p>I'm 100% convinced this is a silly, inefficient way to type. Yes, it beats the heck out of some GUI Windows-like text editor, but still, it should be faster. I just don't know enought about VI (or vim) yet.</p><p>Ideas are welcome.</p> heusserm 2003-11-04T14:27:48+00:00 journal Ken Williams http://use.perl.org/~heusserm/journal/15413?from=rss "Some people sing, some dance, some write. I don&#8217;t do any of those things. Mostly I just write code, and build great product. It&#8217;s what I&#8217;m good at. If I had to push it just a bit harder, I also have a talent (which is unused at the present time) for motivating creative people to do great product. But that&#8217;s about it<nobr> <wbr></nobr>..."<br> <br> <a href="http://www.sierragamers.com/newMsgDisplay.asp?msgId=12627">Ken Williams</a>, former CEO and Co-Founder of Sierra Games, the people that brought you King's Quest. I would disagree; search the web for non-for-any-revenue-at-all organizations making fan "quest" games to continue the sierra tradition and you'll be amazed. He still is motivating creative people to do great product.<br> <br> Insert cheesy line about how Sierra made we want to write code here.<nobr> <wbr></nobr>:-) heusserm 2003-10-27T12:36:57+00:00 journal Those LISP Guys ... http://use.perl.org/~heusserm/journal/15379?from=rss After reading some comments, I did some more research. It seems the author of the paper "Worse is Better" also wrote an article called <a href="http://www.dreamsongs.com/LessonsFromNothing.html">Lessons of the science of nothing at all</a> <br> <br> XP, Agile, Open Source. heh. Who'd have thought? heusserm 2003-10-24T18:43:14+00:00 journal Perfect Vs. Good http://use.perl.org/~heusserm/journal/15342?from=rss In Unix Vs. MIT cultures, one of the recurring themes is "The Right Way" Vs. "The Good Enough Way." Another way to put this is "The Perfect is the Enemy of the Good."<br> <br> Pyscologists have a term for someone who expects too much: A Perfectionist. The Perfectionist's dilemma is that they can't every get started on anything until they have it planned, and planned <i>perfectly</i>. As a result, it's nearly impossible for them to move from planning to actually implementing (doing).<br> <br> What does this have to do with Perl? In class last week, we were talking about 5th generation langauges - declarative languages that understand the context of your words and can figure out meaning, instead of relying on syntax. Dr. Leidig said that the ideal programming language would be able to parse english sentances. Not quite to the level of a turing test, in that it doesn't have to <i>reply</i> in english, but pretty close.<br> <br> So, of course, ProLog and LISP come up, and Bill Day says something like "Any Language with a DWIM (Do What I Mean) command has got to be another generation." We discuss how ProLog and LISP truely are AI languages that can truely understand context - but not english context. <br> <br> Of course, I mention Perl. The professor's response is something like "Yes, Perl was an ugly, early attempt at grokking context." (Ok, he didn't say Grok, but that's what he meant.)<br> <br> So here you have this computer language that no one in class has been formally trained on, yet several of us have used to create large, complex, mission-critical applications. And you have LISP, that several people have been formally trained on, and yet pretty much none of them have written more than two or three lines of code in. The first language is Good, the Second is Perfect.<br> <br> <b>To borrow a line from Joel Spolsky, "What's going on here?"</b> <br> <br> Well, the Perfect is the enemy of the Good here, and Good is certainly Good Enough. "Learning LISP" has been on my to-do list for several years, but i've never had the time. "Learning Perl" wasn't even on my to-do list back in 1997, but I needed a quick program to grep some data, and the code was so trivial that I didn't have to "learn it."<br> <br> Doing a google search, I found <a href="http://www.denniskennedy.com/bestandgood.htm">this</a> explanation of how Good can be better than best - simply put "getting to best usually gets complicated."<br> <br> More searching nets the original quote to <a href="http://cs.gmu.edu/~sean/papers/ideal.pdf">Voltaire</a>. Anyone have any additional insight into this? heusserm 2003-10-23T11:44:26+00:00 journal The easiest way to make money quick ... http://use.perl.org/~heusserm/journal/15152?from=rss <p>... It to sell someone else a way to make money quick.</p><p>When what you are selling is in fact your own system, that's called a ponzi scheme or a pyramid scam and it's illegal.</p><p>However, "one level deep" pyramid scams are legal and very common. Probably the most common is the Real Estate Plan - "Make millions in real estate with no money down."</p><p>Of course, the people who are making the millions are the ones selling the plan. Otherwise, instead of TV info-mercials, they would be out buying real estate, wouldn't you think?</p><p>Another common one-level deep pyramid scam is the 2nd-or-3rd-Rate College-MBA scam. I'm sure you've heard the Ads on the Radio: "Earn your MBA Part-Time in about 6 months without leaving the comfort of your living room<nobr> <wbr></nobr>..." these ads all but guarentee employment and a big salary once you get the MBA.</p><p>Of course, they also exist for BS/BA and AA programs - very often in Computer Stuff like networking or, my goodness, computer science.</p><p>Of course, there is a large group of people who are<nobr> <wbr></nobr>... less than swift. For some reason or other, these people lack the skills to get and keep a high-paying job. What they desparately want is a "sure thing" - a degree or certificate to earn to "guarentee" them a high salary.</p><p>So, they go to Joe Schmoe College and earn an MBA. And, of course, they still lack interviewing skills - and - more importantly - analysis skills. So they can't really make use of the MBA. (It's from Joe Schmoe anyway, which isn't exactly Ivy League, so it's easy for employers to blow off.)</p><p>One big problem is that this increases the pool of available, incompetant MBA's - which decreases the percieved value of the MBA itself.</p><p>Simply put, this is essentially why I oppose Perl Certification. Eventually, training companies would spring up that will allow incompetants to pass the test - and hiring managers will begin to say "Perl? Nah, I think we should use Java. We hired some Perl certified programmers for the flim-boozle project and look what a mess they made<nobr> <wbr></nobr>..."</p> heusserm 2003-10-10T12:10:48+00:00 journal On Gr.pm http://use.perl.org/~heusserm/journal/14923?from=rss Yesterday, Andy Lester came to Gr.PM and gave a revised version of his talk <a href="http://petdance.com/perl/large-project-testing.pdf">Automated Testing of Large Projects in Perl</a>. It was a blast.<br> <br> That morning, the GR.PM steering comittee met with Andy for Breakfast. Speaking of CMM, Andy replied "Well, let me ask you this: How much are you Into Extreme Programming?"<br> <br> Al Tobey replied "Well<nobr> <wbr></nobr>... we've got Matt."<br> <br> Considering the person it came from, I consider this one of the greater compliments I have ever received as a programmer. Thanks, Al. heusserm 2003-09-26T13:16:11+00:00 journal Construction project management http://use.perl.org/~heusserm/journal/14787?from=rss <i>Our contractor's notion of what a ``schedule'' is drives me insane. It seems like when he says, ``it will be done by wednesday afternoon,'' what he means is, ``the guy who will be doing the actual work told me it will be done by wednesday afternoon.'' But the thing is, he knows that the guys who work for him are total flakes, and sometimes just don't show up at all. Yet his answers suggest that this takes him by surprise every single time. So it has proven utterly impossible to schedule anything based on his dates. He seems to think that answers like ``well the guy didn't show up'' should satisfy me, when I have to call up the person I've scheduled and tell them, ``oh, nevermind.'' </i> <br> <br> From <a href="http://www.dnalounge.com/backstage/log/2001/02.html">Some other Guys Blog</a> (February 27th, actually)<br> <br> This is pretty much the exact story of my bathroom modelling, only on a larger scale<nobr> <wbr></nobr>...<br> <br> (No, it wasn't "re" modelled, it was modelled. I put in a bathroom where there was no electrical or pipes in the first place<nobr> <wbr></nobr>...) heusserm 2003-09-19T16:32:26+00:00 journal Critical Success Factors http://use.perl.org/~heusserm/journal/14770?from=rss <p>If you check out the various forums and magazines for software developers today, you'll find a lot of whining: Software Developers are mistreated, underpaid, over-worked, easily laid off, h1b this, overpaid CEO that, blah, blah blah.</p><p>I have to admit, I've spent a great deal of time as a whiner. The truth is, lots of coders are under-paid and over-worked. They have been loyal, or dedicated, and not been rewarded. They worked thousands of hours of overtime for that $250.00 bonus and did the math. They are peeved.</p><p>Now, I ask: Why do you think that is?</p><p>In my opinion, it's pretty simple. Not only do software developers lack negotiation skills, they often don't even RESPECT those skills!</p><p>How many times have you heard a coder say out loud "Sales is something I never want to do."</p><p>Is it any wonder that, when that coder gets laid off, he has problems getting a job? After all, the most common way to find a job is to sell youself<nobr> <wbr></nobr>...</p><p>(Yes, the further you get in your career, the more reputation and free gifts sell yourself for you. I'm mostly talking about entry-level and all-proprietary shops here.)</p><p>Last week in class, we covered "Critical Success Factors". It's an info systems policy class, and the idea is simple: Identify the things you MUST do right, and everything else will fall into place. On the other hand, if you do them wrong, you've set yourself up to fail.</p><p>Then you make sure you nail your critical success factors.</p><p>It occurred to me that, for most smart coder-types who want to become independent consultants, the Critical Success Factors (CSF) are sales, marketing, and relationship-building. Working independently, the coders are going to be able to do just about any work for hire. The challenge is getting the work in the first place.</p><p>That's the critical success factor. What surprises me is that there are so few folks talking about that - we'd rather spend our time talking about kwikis and FIT and whateverelse new toy is our now. hmm.</p><p>Vaguely Related: http://software.ericsink.com/Marketing_for_Geeks.html</p> heusserm 2003-09-18T18:26:15+00:00 journal Attitude in Programmers http://use.perl.org/~heusserm/journal/14752?from=rss <p>This issue came up recently<nobr> <wbr></nobr>...</p><p>The problem is that productivity of software developers is hard to measure.</p><p>Thus, the guy who says "I am the most productive" the loudest and most effectively is credited with being the most productive.</p><p>We've all seen the guys who make a big deal about how complex, or important, or hard the projects they are working on are - or how much overtime they work, or whatever.</p><p>These guys are often inflexible, judgemental, and not teachable.</p><p>Yet, in the arena of office politics, they tend to win, because people tend to repeat things they've heard. Thus, the boss hears from -other- people that joe is smart, hard-working, working on a complex process, etc, etc.</p><p>Objective, Impartial measurement of the productivity of software developers would fix this. Of course, if you figure it out, let me know - we can bottle it and sell it and make billions.<nobr> <wbr></nobr>:-)</p> heusserm 2003-09-17T18:11:41+00:00 journal Exception Handling ... hmm http://use.perl.org/~heusserm/journal/14748?from=rss <tt>Right now, I'm running into a lot of legacy code like this:<br><br>#------------------------#<br>sub GetValues<br>#------------------------#<br>{<br>&nbsp; &nbsp; my $dbh = get_connection('databasename');<br>&nbsp; &nbsp; my $sth = $dbh-&gt;prepare('Select * from table_name');<br>&nbsp; &nbsp; $sth-&gt;execute();<br>&nbsp; &nbsp; my $r;<br>&nbsp; &nbsp; my @a;<br>&nbsp; &nbsp; while ($r = $sth-&gt;fetchrow_hashref) {<br>&nbsp; &nbsp; &nbsp; &nbsp; push @a, $r;<br>&nbsp; &nbsp; }<br>&nbsp; &nbsp; return (\@a);<br>}<br><br>my "Improved" version would look more like this:<br><br>#------------------------#<br>sub GetValues<br>#------------------------#<br>{<br>&nbsp; &nbsp; my $dbh = get_connection('databasename');<br>&nbsp; &nbsp; my $ok = 1;<br>&nbsp; &nbsp; my $msg = "Success";<br>&nbsp; &nbsp; my $sth;<br>&nbsp; &nbsp; if (!$dbh) {<br>&nbsp; &nbsp; &nbsp; &nbsp; $ok = 0;<br>&nbsp; &nbsp; &nbsp; &nbsp; $msg = "Failed to get connection to databasename in GetValues";<br>&nbsp; &nbsp; } else {<br>&nbsp; &nbsp; &nbsp; &nbsp; $sth = $dbh-&gt;prepare('Select * from table_name');<br>&nbsp; &nbsp; }<br><br>&nbsp; &nbsp; if ($ok &amp;&amp; (!$sth)) {<br>&nbsp; &nbsp; &nbsp; &nbsp; $ok = 0;<br>&nbsp; &nbsp; &nbsp; &nbsp; $msg = "Call to prepare failed in GetValues";<br>&nbsp; &nbsp; }<br><br>&nbsp; &nbsp; my $r;<br>&nbsp; &nbsp; my @a;<br>&nbsp; &nbsp; if ($ok) {<br>&nbsp; &nbsp; &nbsp; &nbsp;$ok = $sth-&gt;execute();<br>&nbsp; &nbsp; &nbsp; &nbsp;if (!$ok) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;$msg = "Call to excecute failed in GetValues";<br>&nbsp; &nbsp; &nbsp; &nbsp;} else {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;my $r;<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;my @a;<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;while ($r = $sth-&gt;fetchrow_hashref) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;push @a, $r;<br>&nbsp; &nbsp; &nbsp; &nbsp;}<br>&nbsp; &nbsp; }<br>&nbsp; &nbsp; return ($ok, $msg, \@a);<br>}<br>#------------------------#<br><br>&nbsp; Note that my new code is literally TWICE as long as the old code.&nbsp; Often, it's longer.<br><br>&nbsp; Is this really advantageous?&nbsp; In the long run, it feels like I'm trying the same things over and over again.&nbsp; I actually made a module to abstract out the if-ish ness of the this routine, but the functions got to the point where they were taking 6+ paramters, some of which were optional.&nbsp; It was just ugly.&nbsp; So I've stopped using it until I can do it over again with anonymous hashrefs and "named params."<br><br>&nbsp; The net result is that plenty of folks are saying "error checking is over-rated", and I can see where they are coming from.&nbsp; What's the "right" answer?<br><br></tt> heusserm 2003-09-17T11:33:50+00:00 journal Old habits die hard http://use.perl.org/~heusserm/journal/14668?from=rss <p>"Hi. My name is Matt, and I spent a great deal of time coding in C++"</p><p>I've found that my C++ idioms end up in my perl code. Here's a code sample:</p><p>#begin sample</p><p>sub DoStuff<br>{<br> &nbsp; &nbsp; &nbsp; &nbsp; my $blnOk = 1;<br> &nbsp; &nbsp; &nbsp; &nbsp; my $strMessage = "Success";<br> &nbsp; &nbsp; &nbsp; &nbsp; my $dbh = Get_DBH_Function();<br> &nbsp; &nbsp; &nbsp; &nbsp; if (!$dbh)<br> &nbsp; &nbsp; &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $blnOk = 0;<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; $strMessage = "Couldn't get DBH";<br> &nbsp; &nbsp; &nbsp; &nbsp; }<br> &nbsp; &nbsp; &nbsp; &nbsp; else<br> &nbsp; &nbsp; &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; #Whatever<br> &nbsp; &nbsp; &nbsp; &nbsp; }<br> &nbsp; &nbsp; &nbsp; &nbsp; #...Snip<br> &nbsp; &nbsp; &nbsp; &nbsp; return($blnOk, $strMessage);<br>}<br>#End Snippit</p><p>I've got if ($blnOk) fields to get the DBH, to get the STH, to prepare, to execute<nobr> <wbr></nobr>... blah.</p><p>How about something more like this?</p><p>#Begin Snippit #2<br>use Carp;<br>sub DoStuff2<br>{<br> &nbsp; &nbsp; &nbsp; &nbsp; eval {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; my $dbh = Get_DBH_Function();<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (!$dbh) {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; croak "Failed to get dbh in DoStuff";<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; #More code<nobr> <wbr></nobr>...<br> &nbsp; &nbsp; &nbsp; &nbsp; };</p><p> &nbsp; &nbsp; &nbsp; &nbsp; if ($@ ne "") {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return(0, $@);<br> &nbsp; &nbsp; &nbsp; &nbsp; } else {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return(1, "Success");<br> &nbsp; &nbsp; &nbsp; &nbsp; }<br>}<br>#End Snippit #2</p><p>Of course, the 3rd way to do it is to Croak without the eval, and trust the calling routine to eval it - The BSD way. But I'm not convinced.</p><p>The morals of the story:</p><p>1) I'm thinking of dumping my hungarian notation<br>2) I'm thinking of changing my curly-brace style so my code is more compact<br>3) I'm thinking of adding some structured exception handling instead of writing structured code. (IE, Most of my current code has one entry point and one exit for each function, and returns status state and messages.) Since I won't have try/catch until perl 6, I'll make do with eval.</p><p>Thoughts?</p> heusserm 2003-09-12T12:04:10+00:00 journal Who needs software architects? http://use.perl.org/~heusserm/journal/14657?from=rss Martin Fowler <a href="http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf">Quantifies</a> something that's always been an itch of mine. heusserm 2003-09-11T19:23:46+00:00 journal My last post http://use.perl.org/~heusserm/journal/14656?from=rss &nbsp; &nbsp; ugh.<br> <br> &nbsp; &nbsp; Folks who read my last post seem to think that I was saying: "Make your programs so they can't break, and you don't have to test them."<br> <br> Well, that's <i>half</i> right<nobr> <wbr></nobr>...<br> <br> &nbsp; &nbsp; If you break your functions down far enough, but not quite to the absurd, you can <i>understand</i> the entire function at a glance. Then, you can know they work correctly because you can completely follow the logic of the entire function.<br> <br> &nbsp; &nbsp; Military strategists got it right with the idea of span of control - it's hard for most people to keep track of more than about seven things at once. When functions get too complex, something falls out<nobr> <wbr></nobr>... and that something can all to easily be the limit of a loop index, or an "else" at the end of a long conditional.<br> <br> &nbsp; &nbsp; By keeping functions small enough that they can't break, we can avoid all that.<br> <br> &nbsp; &nbsp; <b>Does that mean we shouldn't test?</b> &nbsp; &nbsp; CERTAINLY NOT! Check the comments on my last post for plenty of reasons why you should test even things you think can't break. <br> <br> &nbsp; &nbsp; In fact, in his presentation <a href="http://www.petdance.com/perl/large-project-testing.pdf">Testing Large Systems in Perl</a>, Andy Lester suggests that you should test things that can't possibly break anyway.<br> <br> 1) Writing the test takes all of 2 minutes<br> 2) It's automated - running the test is nothing.<br> 3) Things may change.<br> 4) You might have been wrong.<br> <br> Again - my point - sure - test early, test often, test always. But minimizing the number of things that could possible break is still a good thing. heusserm 2003-09-11T17:22:04+00:00 journal