tag:blogger.com,1999:blog-163411812024-03-13T14:56:17.890-05:00The CodeWrights TaleThe Codewright's Tale is a place to discuss the craft of software development. The focus is more about the human aspect of programming, there are plenty of sites which post the latest and greatest tools or blocks of 'how to' code. All the tools, methodologies, or languages in the world won't help if the primary obstacle of quality software is human nature and not a human invention.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.comBlogger71125tag:blogger.com,1999:blog-16341181.post-23387861391759639692012-05-14T14:25:00.001-05:002012-05-14T14:25:35.915-05:00Thinking Backwards or ForwardsI've heard references to a new style for documenting requirements. Greg Young talks a little about it in his <a href="http://codebetter.com/gregyoung/2012/04/24/state-machines-and-business-users-2/">post on business requirements at CodeBetter.com</a><br />
<br />
<br />
<br />
I think he is onto something, as it is usually fairly obvious that business customers can handle some pretty complicated procedures and process flows, so why do they struggle with a machine, or state, based approach? The difference I suspect is that they focus on the action and not the state. The specs he describes are centered around a state, lists an action and only then describe the behavior that results from said action; let's write it thusly: <br />
<br />
<br />
<br />
<br />
State ->Action->Behavior. <br />
<br />
<br />
<br />
I'd be willing to bet that the users are really thinking like this, "I want it to do X (Behavior) so I have to push the yellow button (Action) but it only works if the red light is on (State), or <br />
<br />
<br />
<br />
Behavior<-Action<-State<br />
<br />
<br />
<br />
<br />
<br />
The style of documenting has enough in common that they understand what is being asked for even if, to them, it is listed backwards. As an aside, another major difference is I've never had a business user ever want to have a meta-discussion on how they think, so we tend to have to take it into account when designing the requirement gathering process but that will have to wait for its own post.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-6400528122120617542012-04-18T13:28:00.000-05:002012-04-18T13:28:02.005-05:00Programming as an Individual ActivityI've decided to come back to Weinberg's classic 'The Psychology of Computer Programming' since it is at the heart of why I took up writing about programming in the first place. At my first job oh so long ago, it was obvious that we were nowhere close to a solution to programming-in-the-large. With applications small enough to be written by a single developer we could manage to deliver software that works, maybe it was inefficient or clunky but it worked well enough. Sure large systems were built using the waterfall approach but they would invariably overrun both their budget and their schedule. The industry was by no means young, even though the PC revolution was in full swing, the underpinnings had already been discussed ad nauseum. You could dismiss the waterfall method but would still be left with the same questions, 'what do they want?', 'how do we build it?', 'how long will it take?', and so forth. The Agile or Lean movements have been able to change the discussion to ask 'what is the smallest amount of work that we need to address at one time' and go from there.<br />
<br />
I believe that we have been avoiding the most important questions - which are uncomfortable to contemplate - like, "what is the largest single aspect that controls a software schedule?" or "How do we plan a project when the members of the team are not pluggable resources?"<br />
<br />
This brings me back to one of the biggest unresolved question of our field, "Why can't we engineer software like we engineer buildings or spacecraft?" I ask this not for serious comparison since the differences are legion, but rather to point at the single most important advancement in the field of engineering since the advent of the first simple tools (the lever, the wheel, etc), calculus. <br />
<br />
Why calculus you ask? because it gives us a way to plan for infinite variability and still have confidence in the result. Planning a trip to the moon would be impossible without being able to calculate how much fuel is needed since how much fuel is needed depends upon the weight of the rocket which creates a recursive dependency.<br />
<br />
Software will have no equivalent for calculus because the variability comes from the people participating in the project. Until we accept that <a href="http://alistair.cockburn.us/Characterizing%20people%20as%20non-linear,%20first-order%20components%20in%20software%20development">people are a first-order component of any software project</a> we will continue to look to <a href="http://codewright.blogspot.com/2007/04/technology-is-harsh-mistress.html">silver-bullets</a>, the next development process fad, or the <a href="http://codewright.blogspot.com/2012/02/xslt-modern-day-snake-oil.html">latest new-fangled technology</a> for relief.<br />
<br />
<br />
<br />
<br />
<br />Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-41999822259729933782012-02-22T15:53:00.001-06:002012-02-23T11:36:43.251-06:00XSLT - The Modern Day Snake Oil<br />
<div class="separator" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-zB2W4uRL_Ow/T0VZqh1EU0I/AAAAAAAAAV8/z2kmRvxid44/s1600/2snakeoil_1.jpg" imageanchor="1" style="clear: right; cssfloat: right; float: right; height: 282px; margin-bottom: 1em; margin-left: 1em; width: 244px;"><img border="0" height="200" lda="true" src="http://4.bp.blogspot.com/-zB2W4uRL_Ow/T0VZqh1EU0I/AAAAAAAAAV8/z2kmRvxid44/s200/2snakeoil_1.jpg" width="171" /></a></div>
Technology seems to attract all kinds, no surprise these days when everybody and their dog are high-tech consumers. But those of us who earn their living in that fast-paced world every day can't help but get a bit jaded seeing the same mistakes repeated time and time again. From the <a href="http://codewright.blogspot.com/2009/12/lifes-too-short-to-work-for-clowns.html">desperate</a> or possibly <a href="http://codewright.blogspot.com/2009/06/why-extreme-programming-fails.html">Machiavellian</a> managers who want to ignore common sense and decades of history and continually chase the proverbial <a href="http://codewright.blogspot.com/2007/04/technology-is-harsh-mistress.html">silver bullet</a>, to the greedy vendors selling the latest 'enterprisey' tool with promises which sound more like a late-nite comedy skit, "Not only is it a floor wax, it's a tasty dessert topping!". In software it is, "Without writing a single line of code". Why do people fall for these pitches? You can blame ignorance, malice, or greed; in any event, it is up to each of us to keep our wits about us when evaluting claims for the latest-and-greatest doohickey the next salesdroid offers.<br />
<br />
There is one phrase that I've seen many times over the last twenty years and whenever I hear it, I immediately think of snake oil. Whenever you hear a consultant say anything to the effect of, "easy to use by non-programmers!", smile and quickly look for the exit. How trite is it? Well, early in my college days I remember hearing stories from the early mainframe days when assemblers were first coming out, "It works so well you won't need programmers anymore!" At my first job at a large company, the <a href="http://en.wikipedia.org/wiki/Fourth-generation_programming_language">4GL</a> vendors would use the same line on the managers, distracting their mark from the large price tag with promises of savings from lower staffing. The reality was nobody but programmers could figure out how to actually use the immense packages, assuming they could get them installed correctly in time to use on a project. Even modern tools like<a href="http://www-01.ibm.com/software/awdtools/reqpro/"> Requisite Pro</a> fall, which I really liked, prey to this. They are supposed to improve productivity but the learning curve is so large that the only way to properly use it on a large project is to have someone who already knows it configure it for you.<br />
<br />
Recently I ran accross the claim in an old book, "<a href="http://www.amazon.com/Professional-Java-XML-Programming-servlets/dp/B0000B0T0X">Professional Java XML Programming with Servlets and JSP</a>" by <a href="http://cs.colgate.edu/~sasha/">Alexander Nakhimovsky</a> and Tom Myers published in 1999 (page 526 to be exact) which attempts to summarize the ream of paper constituting the previous chapters. In a section appropriately but belatedly (considering where it appears) titled "What's XSLT for?" the authors explain,<br />
<br />
<blockquote class="tr_bq">
We are rapidly approaching the summary and conclusions to this final chapter of the book In the meantime, the main conclusion about XSLT that we hope you will draw from this chapter is this: XSLT is best described as a general-purpose mini-language, intended to make many common operations on XML documents easy to express and accessible to non-programmers.</blockquote>
Is the book old and out-dated? Of course. The age of the book only matters though if the authors would express a different attitude given a chance to update their book. Granted, right after the offending paragraph they attach some conditions, <br />
<blockquote class="tr_bq">
Allows non-programmers to do some transformations: <br />
- without tools, only simple things<br />
- with tools, more complex things</blockquote>
When I read the above, I couldn't help thinking, "Have you guys _looked_ at what you've written lately? If it takes a book 500 pages long to explain it, you're never going to get non-programmers to use it" Why is programming hard, I don't know and do not want to venture a guess. What I do know is when competent programmers who are at least trained - if not adept - at imperative object-oriented languages face a significant learning curve when working with a declarative language like <a href="http://en.wikipedia.org/wiki/SQL">SQL</a> much less a functional one like <a href="http://en.wikipedia.org/wiki/Erlang_(programming_language)">Erlang</a>. XSLT is like a combination of web templates with an embeded declarative language which also include functional aspects, although the authers probably disagree saying, "As of today [1999], JSP is a tool for a prgrammer while XSLT is a tool for a Competent User who is NOT a programmer."<br />
<br />
Am I trying to call out XSLT or XML? No, they are useful tools (<a href="http://memeagora.blogspot.com/2005/08/actual-real-everyday-use-for-xslt.html">like automatically formatting your log4j config file</a>) and at this point we couldn't get rid of them if we tried. The issue is quite old and <a href="http://www.codinghorror.com/blog/2005/07/martin-fowler-hates-xslt-too.html">better men than myself have already weighed in</a>. What I do want is for people who should know better, like said authors, to refrain from propagating the myth that if only we had better tools or languages, non-programmers would rush in to join the computerized fun.<br />
...Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-21323548628761972852012-02-15T18:52:00.002-06:002012-04-18T12:35:45.687-05:00Pattern IgnoranceI've been in graduate school for a few years now and keep asking myself how we could engender good habits in students - <a href="http://codewright.blogspot.com/2005/09/education-of-codewright.html">like any good Codewright</a> - during their education, like<a href="http://codewright.blogspot.com/2010/07/battle-of-computer-science-training.html"> usage of version control</a> or refactoring.<br />
<br />
My database class provides a good example of the potential and the obstacles. The first project involves creating a schema where the tables have contraints that prevent the tables to be created all at once and those same constraints make it impossible to load the sample data all at once. You don't need the actual schema, I'm just describing a bit of complexity where it influences the assignment.<br />
<br />
So the data is provided in text files in a comma seperated form and the approach I decided upon is simply parsing the values and then generate SQL statements in the right order. First off, I thought about using an ORM framework, like <a href="http://www.hibernate.org/">Hibernate</a>, but have no experience with one. I did find a <a href="http://opencsv.sourceforge.net/">CSV library</a> to parse the data which cut down the code I had to write but will complicate the grading because the TA will need to download and extract the library in order to run what I submit so I'll have to include those details in a readme file.<br />
<br />
So, processing a single file is fairly straightforward; parse the file into a list of lines, loop over the lines, generate the appropriate SQL statement for the data from that file. I soon found myself repeating code for looping over the lines since the files for each table needed slightly different SQL statements. In rejecting the ORM approach, avoiding the definition of domain objects as simple containers for data -- I also didn't really need domain objects for each file because there was not going to be any behaviour, not to mention the lack of a data framework -- I continued the straight text approach. Looping over the lines in the first file (Employee), it was easy to directly call a routine to generate SQL rows. This caused a problem when I wanted to reuse the looping structure for the next file (Departments). I could leave the loop and add an argument but that would require defining an interface and implementing a distinct class for each file. Avoiding data objects puts me on the slippery slope of avoiding other patterns too; what I keep telling myself is it's only for this one project, it's due in two days, and the TA isn't going to give bonus points for using nifty patterns assuming he's ever been exposed to them.<br />
<br />
In short, there is no incentive to produce well-written code. The assignment is graded by evaluating the results without regard for the methods used to produce those results. <br />
<br />
<br />
<br />
<br />
<br />Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com1tag:blogger.com,1999:blog-16341181.post-75754200948675613092012-02-08T09:45:00.001-06:002012-02-08T09:45:01.644-06:00Testing and the Parable of the PainterOne of the many stories from the real world is having a coworker who doesn't understand the idea of how to test an application. When asked to write a test program, they think that means writing a second program with the same logic - which is redundant of course - and any other approach makes no sense.<br />
<br />
Here is a story to tell these folks.<br />
<br />
There were two painters who kept busy painting houses around town. The painters were brothers named Jerry and Dale. They'd come by the house to be painted and the owner would tell them what color to use, the people in town didn't have eclectic tastes which made it easy for the men, the choices were: white, blue, red, or yellow. They had both been painting for many years and made a comfortable living this way.<br />
<br />
A retired sea captain moved to town and bought an older house that was in dire need of a paint job. He hired Dale to paint his house with instructions to paint the house ocean blue. The captain had bent Dale's ear about how the sea was his first love and she showed many different faces and that you could encounter waters of midnight blue during a storm or nearly turquoise near a shallow lagoon on a sunny afternoon.<br />
<br />
Dale goes back to his shop, picks up his blue paint, telling himself that blue is blue, and heads off to do the job. When he's done the captain comes around, takes one look at his house and exclaims, "I've never seen the wild ocean look like that! I said ocean blue, not sky blue!". The captain dismissed Dale and refuses to pay.<br />
<br />
Dale returns home and grumbles to his brother Jerry about the whole affair, "If he wanted a specific shade of blue he should have said so before I painted the whole house!"<br />
<br />
The next day, Jerry is surprised to find the very same captain at his door asking to have his house painted a, "proper shade of ocean blue." Jerry, with the hindsight of his brothers experience, takes the captain to his paint shed and quickly mixes several different shades of blue until the captain smiles and says, "That one reminds me of calm seas off the coast on a sunny day, I'll take it.". Jerry splashes the chosen color onto a thin peice of wood and the two men agree on a price. The captain directs Jerry to get started the next day while he is away at the docks helping a friend repair a fishing boat.<br />
<br />
The work goes quickly and when the house is done Jerry goes to fetch the captain to ask him to come see the finished product. On the way to the docks the sky darkens and starts to fill with ominous clouds, a storm is headed this way. Jerry finally reaches the docs and finds the captain in a sour mood, the captain snaps, "It had better be the right color, I'm not going to live in a house that doesn't remind me of the fickle sea." Upon seeing his house the captain throws a fit, "That is not the color of the ocean! What kind of painter are you? You're not going to get one cent out of me for such a lousy job". He continues his verbal abuse until Jerry pulls out the peice of wood with paint splattered over it and holds it up saying, "You recognize this? This is the color you agreed to before we started. When I hold it next to your house, you can clearly see that they are the same color. You might have changed your mind but I've held up my end of the bargin and expect to be paid fair-and-square. If you want it painted some other color, I'll be happy to add as many coats as you have money to buy, but you'll have to pay for this one first." <br />
<br />
The moral of the story? Agreeing on the outcome beforehand is the only way to prevent any arguments over what 'done' means at the end.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-63952738749931687872011-12-29T14:43:00.000-06:002011-12-29T14:43:16.240-06:00SharePoint 2010 Custom IFilter development updateThe previous post on<a href="http://codewright.blogspot.com/2011/07/mysteries-of-ifilter-development.html"> IFilter development for Windows and SharePoint</a>, I included several links to resources we used to code a custom IFilter; the hope being they would be useful to anyone looking to write their own, seeing as how difficult it was to find accurate information on the subject.<br />
<br />
Alex Culp did an outstanding job with the IFilter, so much so that Microsoft asked him to write a MSDN article on the subject of <a href="http://msdn.microsoft.com/en-us/library/hh694268.aspx">writing a custom IFilter</a>. The custom file type wasn't the issue, it was all the complexities of C++ and IFilter development combined with registry entries, properties, 32bit/64bit details and so forth, like how the 64-bit version of Visual Studio creates a 32-bit installer by default which then didn't install the correct version of the .Net dlls. Another bit-ness nugget is to pay attention to which Regedit you run when setting registry entries; 64-bit entries are not visible to the 32-bit executable.<br />Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com1tag:blogger.com,1999:blog-16341181.post-62801007823774111432011-10-03T16:40:00.001-05:002012-01-10T12:25:32.969-06:00Mysteries of IFilter Development RevealedAlex Culp and I worked on a IFilter for a customer file type. His page on <a href="http://alexculpblog.wordpress.com/2011/07/01/ifilter/">writing an ifilter</a> is down while he works on publishing an article on writing ifilters for Microsoft. [Update: His MSDN article on IFilter development has been published, see my post, <a href="http://codewright.blogspot.com/2011/12/sharepoint-2010-custom-ifilter.html">http://codewright.blogspot.com/2011/12/sharepoint-2010-custom-ifilter.html</a>] In the meantime, I figured I'd share my list of IFilter development links. Considering all the other technology out there and the age of the ifilter interface, I was surprised how difficult it was to find useful information.<br />
<br />
A good start is this MSDN page: <a href="http://msdn.microsoft.com/en-us/library/ms916793.aspx">http://msdn.microsoft.com/en-us/library/ms916793.aspx</a>. It's somewhat old but does cover lots of the details involved. We had the hardest time finding out how to create a custom property or property set for the ifilter to use when it found metadata. We ended up using an existing category, Basic, and creating property ID's above the range of existing properties, i.e. we started at 200 since the existing Basic properties didn't get above 100.<br />
<br />
Here's info on <a href="http://blogs.msdn.com/b/ifilter/archive/2007/02/06/debugging-ifilters-in-moss-wss.aspx">debugging IFilters in MOSS</a>. We did have trouble getting all the registry entries needed to properly register the IFilter with the server. Keep a log of the entries, there are quite a few and in confusingly similiar places, especially since GUIDs are involved.<br />
<br />
Here is another page on <a href="http://blogs.msdn.com/b/ifilter/archive/2006/12/25/chronicles-of-an-ifilter-development-inception-to-deployment.aspx">ifilter development</a>. Keep reading through the comments, lots more details are discussed there.<br />
<br />
<a href="http://www.citeknet.com/Products/IFilters/IFilterExplorer/tabid/62/Default.aspx">IFilter explorer</a>. Shows information about the installed ifilters.<br />
<br />
Good article series from Anne Stenberg on <a href="http://blogs.technet.com/b/anneste/archive/tags/crawled+properties/">crawled properties</a> and how to find the one you want to map. This is useful in understanding more about a crawled property, like when you want to make your own.<br />
<br />
This post mentions a dev guide to writing your own <a href="http://sharepointsearch.com/cs/blogs/notorioustech/archive/2007/06/19/writing-a-custom-protocol-handler-for-sharepoint.aspx">SP2007 protocol handler</a>. Might be a good resource.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com1tag:blogger.com,1999:blog-16341181.post-18300900634677228902011-01-11T09:00:00.002-06:002012-01-10T12:29:15.369-06:00Computer Science is an Art<br />
Of the many eternal debates that spiral around software development blogs the one that seems the most intransigent is whether the practice of programming is an art or a science. <br />
<br />
Chefs have a similar discussion over cooking and baking. Cooking is an art while baking is a science. Why? Because when you put something in the oven, you had better get it right the first time. Mistakes mean starting over. Cooking, on the other hand, allows the chef the leeway to make changes as the dish progresses. The chef can take action to keep the dish from heading off course. For example, when making gravy you keep adding flour until it is the right consistency and if you add too much flour you can add some milk to thin it down. It is incremental by nature.<br />
<br />
<br />Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-4289443270004563062010-12-01T09:20:00.002-06:002010-12-02T14:12:49.098-06:00Computer Science or Software Engineering - An Elemental ProblemWhat is the difference between Computer Science and Software Engineering? That depends on the nature of the problem you are trying to solve - is your problem one of <a href="http://en.wikipedia.org/wiki/Silicon">Silicon</a> or one of <a href="http://en.wikipedia.org/wiki/Carbon">Carbon</a>? <br />
<br />
In my 20-year career in working with software, the single biggest issue has also been an elephant
in the room: the abysmal success rate of large software systems. Plenty
of books have been written on the subject with lots of great, if
unheeded, advice. Scope creep, ambiguous or missing requirements, poor communications, bad risk management; lots of reasons have been documented and just as many if not more solutions have been suggested. <b>Brooks </b>gave us "<i>The Mythical Man-Month</i>", <b>Yourdon </b>writes of "<i>The Death March</i>", <b>Tom DeMarco</b> has "<i>Peopleware</i>". All of them attempting to answer the question, "Why is it
so hard to write software?"<br />
<br />
If you take the all the books on writing software and put their suggestions in one big list, the first question would be, "If we have all the answers, why don't we use them?" That might be nice for getting it off your chest but isn't has helpful in pointing us in the right direction. At its core, this question does have a useful kernel, it assumes that 'we' are the problem. If only we used this process, if only we implemented that practice, if only we hired the right people, if only we kept our teams motivated. As an aside, most of the reasons for failure are management reasons, not technical ones. It should be no surprise that many find the <a href="http://virtualschool.edu/mon/CaseStudies/Vasa/vasa.html">case study on the sinking of the Vasa in 1628</a> to be very instructive. The blame is as much, if not more so, on the King's unrealistic demands as on the builder's efforts to failure to meet the royal requirements. In our endless efforts to build bigger, more complex and complicated software solutions in the face of almost certain failure, should question our sanity; one definition of insanity being, "doing the same thing and expecting different results." Biting off more than we can chew, choking, and then doing it all again time after time only shows how our hubris can get the better of us, allowing us to continue on our <i><a href="http://en.wikipedia.org/wiki/Sisyphus">Sisyphean task</a>.</i><br />
<br />
This brings me to an interesting observation. There is a long running debate over whether computer programming is/should be considered a form of artistic expression or of engineering prowess. Computers have such a wide scope that many sub-fields have crept up, hardware and software being the most obvious. Hardware is typically the realm of the engineer, designing circuit boards or embedded sensors. This changes as the hardware gets larger in size or scope. CPUs have microcode, missiles have on-board navigation systems with programmable targets. <br />
<br />
Most universities that offer degrees related to programming computers name the department Computer Science. Now, being considered a 'science' may be just a way of expressing the notion that computers are deterministic and worthy of comparison with mathematics or engineering, having likely grown as an offshoot of the field of electrical engineering. Whether it be data mining, security, networking, or pure algorithms, most of the areas seem to ignore the question of why software is so hard. They assume the problem is in the silicon computer chips. Curiously, these fields don't even attempt to address this most difficult of questions, assuming improvements of our silicon constructs or their usage will somehow mitigate our human foibles. If only we had better tools, or faster computers, etc. then our carbon-based brains could somehow ascend above the project management miasma and become a beacon to those who struggle and toil without end. Considering the gargantuan number of man-hours and humongous amounts of money wasted, such an accomplishment would be of heroic proportions, mythic even; a modern-day retelling of Prometheus or Sisyphus.<br />
<br />
The truth is that Computer Science may bring improvements in areas where
the problem is in the silicon, it is mute when asked to provide answers
to problems of a carbon nature. Software Engineering attempts to develop solutions that include how humans work together. Software Engineering does not assume that software development is as cut-and-dried as putting the right circuits on a board to achieve the desire product, or breaking down a complex problem into constituent algorithms to make the problem more manageable. There is no magic bullet, no single development process, no single answer. To understand why humans have a hard time developing software, we must admit that humans are part of the equation. Doing is brings with it a cold truth about humans - they are non-deterministic by nature. Alistair Cockburn describes it as people being <a href="http://alistair.cockburn.us/Characterizing%20people%20as%20non-linear,%20first-order%20components%20in%20software%20development">non-linear, first order components in software development</a>. To answer the question of what is software development, we might have to take detours through Psychology, and may be surprised to end up working with Philosophy even.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com2tag:blogger.com,1999:blog-16341181.post-36111887449452422212010-09-02T09:21:00.002-05:002010-09-02T09:24:41.714-05:00When the Student is Ready, the Teacher Appears<br />
I remember hearing from a 'higher-up' once at a previous company that we shouldn't do Use Cases.
"The customer doesn't like them", something I never heard directly from
a customer. Doing a design review with use cases, a domain model, and a set of fleshed-out sequence diagrams was once described as 'over designed'. It was a mystery to me at the time why they would be so ambivalent about better ways to develop software. <br />
<br />
Now, in my graduate class at UTA on Software Design Patterns, the assignments are ironically familiar:
<br />
<br />
<ul>
<li>
project requirements</li>
<li>
use cases (3 levels)</li>
<li>
domain model</li>
<li>
sequence diagrams, design class diagram</li>
<li>pair programming</li>
<li>test driven development</li>
</ul>
<br />
Not even ten years ago, these practices were still gaining acceptance in the industry. A common complaint up until now has been that colleges and universities don't teach these techniques, which only gave the critics more ammunition. Now that has started to change, hopefully the debate about these practices will be about how to best implement them instead of how to dismiss them.<br />
<br />
It turns out that the solution to the mystery had nothing to do with the merits of any software development methodology but rather had everything to do with the rejection of in-house software development. This company had a long history of developing their own software and over the years had ended up with one of the largest technology departments I've ever worked in, close to 1,000 people. When the leadership changed, the attitude shifted from "Not built here" to "Don't build it if you can buy it". They didn't value the capability to develop software, so trying to improve the process had become moot. Preferring to buy vs. build is a perfectly reasonable approach. Some company's realize they don't want to be a development shop and make no bones about it. The harm comes when there is a disconnect between management and the teams doing the work. Psychologically, this would fall under cognitive dissonance; having a development shop mindset at the same time the departments actions are turning away from development. <br />
<br />
It wasn't a surprise then, when it was announced that they were 'partnering' with a large three-letter company to rewrite their web-site, which happens to be the company's main source of revenue. The team that developed the site was held in high esteem by the department, full of some of the smartest guys and pushing the envelope, all while supporting a truly business-critical app 24/7 with close to zero unscheduled downtime. The site happened to be written in C++, putting the bar high for development skills for recruiting. One of the clues to the mystery was at a monthly meeting of technical leads prior to the partnering decision. Using C++ was being de-emphasized, the reason given was the difficulty in finding qualify developers.<br />
<br />
The interesting question becomes, if you devalue software development skills will you lose the ability to monitor your partner and be a fully engaged partner? Inevitably, you'll have to take some consultants word on a technical matter and you'll no longer be a partner but rather a simple client. Keeping your organizations software development skills sharp benefits you even if you don't write the code.<br />
<br />Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-41419274602135637562010-08-09T11:58:00.001-05:002010-08-09T12:07:05.636-05:00Student, Teach Thyself - A Theoretical Computer Science QnA siteI've been a fan of Stackoverflow for a while. <a href="http://www.codinghorror.com/blog/">Jeff Atwood</a> and <a href="http://www.joelonsoftware.com/">Joel Spolsky</a> have helped the Internet turn a corner when it comes to helping people find answers to their questions. Google may do an incredible job indexing pages but it would be to no avail if the pages themselves were all junk.<br />
<br />
I don't have a ton of time to be on the new site-proposal system called <a href="http://area51.stackexchange.com/">area51.stachexchange.com</a>. During one of my CS grad school classes, I asked a <a href="http://stackoverflow.com/questions/2625261/how-is-a-lattice-used-by-a-compiler">question regarding my schoolwork</a> on the main Stackoverflow site and was underwhelmed by the responses. Since the main site is more for working programmers who typically expect a code snippet as an answer, I figured the proposal for a <a href="http://area51.stackexchange.com/proposals/8766/theoretical-computer-science?referrer=Q9zc-ltJyTBRULukYsvH_w2">site on theoretical computer science</a> deserved a shout out.<br />
<br />
Now if they would only restart their podcast.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-91629076516911378092010-07-27T10:11:00.113-05:002010-07-27T10:11:00.628-05:00The Battle of Computer Science TrainingThere is a constant battle between the corporate and academic worlds. Universities want to teach more theory so students are prepared for a wide range of situations. Companies want graduates with technology-specific training so they can contribute immediately. Who is right? Both and neither.<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/_ikmwGzALbOc/TEh7726F5sI/AAAAAAAAAQk/cRVzai45LM4/s1600/the-blacksmith.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="http://3.bp.blogspot.com/_ikmwGzALbOc/TEh7726F5sI/AAAAAAAAAQk/cRVzai45LM4/s200/the-blacksmith.jpg" width="160" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Equipped with skills</td></tr>
</tbody></table><br />
When taking a course in algorithms, you might need to demonstrate some type degree of learning through programming a lab assignment. Its a decent bet that languages the student may not be the best choice to highlight the various algorithms being taught. The student then finds himself learning a new language for the sake of submitting a lab assignment. This is usually done with zero training or exposure and very little support outside of asking classmates or asking for help from the instructor who is eternally busy with other things.<br />
<br />
Version control is another topic that shows the rift between the two worlds. Most IT shops require the use of some version control system. Most developers learn enough to get the job done but never really understand it enough to make it an equal partner in the development process. The administrative function is usually lacking. big IT shops can afford to hire VCS admins also have so many repositories that the admin's time is spread too thin unless you happen to be working on the 800-lb gorilla project. Smaller shops muddle through and usually someone takes the admin role upon themselves because they are tired of the situation and are the first to hit their frustration threshold. Not unlike the newlywed dilemma, "If the full sink of dishes bothers you, you wash them."<br />
<br />
Since starting grad school, I figured I'd apply my own coding lessons and use version control for my assignments. What an eye-opening experience! Some tools with which I'm familiar already have enough version history. Eclipse has a nice feature where it automatically saves the change history of a file every time you save it. This works for solo Java projects but doesn't for other languages or group projects.<br />
<br />
There are two main obstacles to using version control in academia; having to be your own VCS admin/trainer, and the lack of consistency from the university. You have to have the discipline to keep your VCS configured and working but also extend it to whatever environment that might be required. It does you little good if you have your personal repository setup on your own PC when the professor requires assignments to be done on the campus Unix box. The same holds true when a lab is required to be done in a language that your IDE doesn't support. Eclipse has 'C' support through the CDT but if you aren't going to be using it next semester, the time it takes to get it configured and working becomes that much time away from getting the assignment done or studying for the next test. When working on a group project, it also means having to teach your teammates how to use the tool and then hope that they actually use it.<br />
<br />
This leads to the second obstacle. Without a departmental policy or professorial dictate, version control usage by students will be as rare has hen's teeth. The university or at least CS department would need to support VCS tools for campus computing environments, at least for administrivia. The professors and instructors would need to make VCS part of the lab requirements.<br />
<br />
Don't hold your breath.<br />
<br />
There is no impetus by the faculty to standardize on a VCS tool. The sheer number of languages and environments make it unlikely for any consensus to appear. This is odd because CS classes constantly have issues with turning in code and checking for plagiarism/cheating. Looking through the check-in history would be a simple way to verify a student's progress. Code diff tools would make it almost effortless to check for "borrowed" code. There are enough cross-platform tools that it is not a technology problem, it's a human problem.<br />
<br />
The fundamental problem is the two worlds are trying to 'train' for different things. In school, technology is a means to an end. Students are being trained to understand how to approach and solve problems. They are being prepared for unknown situations so they can recognize when an approach is guaranteed to fail or maybe has been solved before and a stock algorithm exists. Employers, on the other hand, want people who are trained in the tools they are using to solve their problems. New hires aren't the ones who get to analyze a business problem not to mention prioritizing which problem to address. Managers still like to think of coding like a factory floor, the workers don't get to design the manufacturing process or choose the tools.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/_ikmwGzALbOc/TEh8siIR4FI/AAAAAAAAAQs/2UbB-zlJPuw/s1600/factory.jpeg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="111" src="http://2.bp.blogspot.com/_ikmwGzALbOc/TEh8siIR4FI/AAAAAAAAAQs/2UbB-zlJPuw/s200/factory.jpeg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Trained to repeat a process</td></tr>
</tbody></table><br />
For those of you that like analogies, here is how I'd put this conundrum. College is training blacksmiths that don't make the same thing repeatedly. They can be given a strange piece of hardware and figure out how to fix it. They can be asked to create something new based on ambiguous requests. Business wants someone who is trained to make swords. The enemy is already defined by the leaders, the strategies already determined by the generals.<br />
<br />
The problem isn't training sword-smiths, it's wanting nothing but sword-smiths and then discovering you need a telescope, or horseshoes. Technology is still changing at an unheard of pace. Training in the current technology is a recipe for obsolesce. The window of current technology is getting smaller and smaller. COBOL was king-of-the-mountain for 20 years, C/C++ for maybe 15, Java is already on the downhill slope with C# and JavaScipt taking the spotlight and other languages in the wings (Ruby, Python, Scala) or working backstage (Perl, PHP, SQL).<br />
<br />
Pick your tools well and train for anything. You'll have your fate in your own hands and not be surprised by the winds of change. <br />
<br />
<br />
<br />
<a name='more'></a>Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-87487970958040727962010-05-14T08:33:00.003-05:002010-05-14T08:33:00.768-05:00To Buy or Not to Buy Technical Books, That is the Question<div class="post-text">So the rookie coder is working at his new job, fresh out of college, when the team malcontent is overheard a couple of cubes over, "This place is so cheap! They should reimburse me for this technical book. It's a heckuva lot cheaper then a training class." However true that is, it hides a simple choice: keep the book and be out the money, or give up the book and pocket the cash - <a href="http://stackoverflow.com/questions/233903/how-can-i-convince-my-boss-to-buy-books-for-programmers">assuming the boss will foot the bill</a>. </div><div class="post-text"><br />
Recently a <a href="http://stackoverflow.com/questions/944878/should-programmers-buy-their-hardware-if-their-company-doesnt-buy">question on Stackoverflow</a> reminded me of that rookie coder. Being fresh out of college gives you an amazing combination of overconfidence and cluelessness. Without any basis, it's easy to take the office attitude and run with it. You shouldn't have to buy your tools, your company should.<br />
<br />
I disagree.<br />
<br />
Why? Because they are tools. It's not even a cost thing. A professional should be responsible for knowing which tools they need to be most productive. Tour an airline maintenance facility and check out the workshop. A large area, maybe 1000 sq. ft., with nothing but large toolboxes; each with a name and a lock. The mechanics have to buy all their own tools, think wrench sets and so forth - not large things like engine dollies.<br />
<br />
At first it seems a bit silly and redundant but when you start to think about it, it's easy to see that not everyone is going to want to spend the extra money on the high-end tools, or they might want extras of the same set for whatever reason. Also, consider the hassles with sharing, e.g. "Where are the 1/2 inch box-end wrenches?" By not making the tools shared, the '<a href="http://en.wikipedia.org/wiki/Tragedy_of_the_commons" rel="nofollow">Tragedy of the commons</a>' is avoided. <br />
<br />
Another example is chefs and their knives. You don't touch another chef's knives. The restaurant provides the big things like ovens and stoves, the chefs bring their own knives.<br />
<br />
Back in the world of computers, I've brought in extra memory before. I told my manager so he'd know that some of my personal property was in the PC in case it needed to be worked on by the internal techs. I also put a note on the box itself. I would have had a bigger issue if they discouraged bringing your own hardware. Most shops like to provide the box itself because it minimizes their support issues but they shouldn't have any problems with you bringing accessories like monitors, keyboards, mice, etc.<br />
<br />
To summarize, change how you think about tools and strive to use whatever makes you better at your job, even if you have to pay for them out of your own pocket. It's the 'Professional" thing to do.</div>Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com2tag:blogger.com,1999:blog-16341181.post-83903177361397099172010-04-21T13:13:00.001-05:002010-09-24T10:30:53.366-05:00Martin Fowler, Alistair Cockburn, and OptimismThe effort to make Software Engineering actually live up to the 'Engineering' part has been greatly helped by <a href="http://martinfowler.com/">Martin Fowler</a>'s book on <a href="http://www.amazon.com/exec/obidos/ASIN/0201485672">refactoring</a>. Martin recently posted about <a href="http://martinfowler.com/bliki/Semat.html">his decision</a> to not participate in an effort by others in the industry, not lacking in optimism, to define a common process for software development.<br />
<br />
Martin Fowler declined to get involved in a similar effort and for the same reason. The key quote is,<br />
<br />
<blockquote>
“Why this is so was primarily crystallized for me by Alistair Cockburn who explained that since people are the central element in software development, and people are <a href="http://alistair.cockburn.us/Characterizing%20people%20as%20non-linear,%20first-order%20components%20in%20software%20development">inherently non-linear and unpredictable</a> - such an effort is fundamentally doomed.”</blockquote>
<br />
While my <a href="http://codewright.blogspot.com/2009/11/extreme-programming-is-people.html">previous post</a> about Alistair's paper covers much of the same ground I felt it was worthy of an update. There will always be souls who crave consistency just as there will always be salesmen willing to offer the illusion of it. Facing our own nature is one of life's hardest lessons. Some of those who ignore the human factor are optimists seeking to improve their chances of consistency, which has <a href="http://codewright.blogspot.com/2007/04/technology-is-harsh-mistress.html">driven many towards the latest and greatest geegaw</a>, a new language, a new GUI, a new design tool. Others are simply deluding themselves in the hopes that if only people would sit up and fly right (read this to mean 'do it their way') all our problems would be solved. <br />
<br />
Studying the <a href="http://www.blogger.com/%20http://codewright.blogspot.com/2009/03/chapter-3-how-can-we-study-programming.html">process of computer programming</a> has been around for decades. Even so, we still have trouble internalizing human foibles - people aren't predictable and follow "standards" about as well as a <a href="http://en.wikipedia.org/wiki/Random_walk">random-walk</a>. So the most successful way to get people to be consistent is to lead by example, blaze a trail ahead and show them the way. In this manner Extreme Programming was its own worst enemy and its own best cheerleader. By showing how a set of practices work in situ, it created a much-needed focus. The "Waterfall" model was the favorite whipping-boy, essentially dead, and the iterative approach was in its infancy. So XP served as a lightning-rod for discussions on the craft of software development. It provided an example of practices that could be emulated and provided an easy target for the doubters, disbelievers, and denialists; no doubt the negativity coming from the critics was channeling their innate understanding of the <a href="http://codewright.blogspot.com/2009/06/why-extreme-programming-fails.html">darkside of human behavior</a>.<br />
<br />
While Extreme Programming hasn't become the standard development model, that doesn't mean it failed. When the history of Software Development is written, XP will be given credit for re-introducing the most important factor; not tools nor process, but people.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com4tag:blogger.com,1999:blog-16341181.post-45639635521913702862010-04-12T12:21:00.000-05:002010-04-12T12:21:00.793-05:00Context as a commodity<div class="Section1"><div class="MsoNormal">How much context do you need to do your job? Can we quantify context in any way?<o:p></o:p></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Jeff Atwood has mentioned that he doesn’t shut his machine down every night. He wants his environment to be as he left it at the end of the previous coding session. Getting all the apps, tools or other windows opened to the right place takes not only CPU time but mental energy, aka context. <o:p></o:p></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Some jobs require no context, for example a bank teller can walk in to work on Tuesday and not need to remember any of the transactions that took place on Monday. Contrast that with a novelist in the middle of writing a new book, let’s say writing the next chapter not editing anything. They need to remember all the characters, their personalities, the existing story, and in what ways the plot threads are to interact in the new material.<o:p></o:p></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Another good contrast is a professional athlete. A pro baseball player doesn’t need to remember what happened in yesterday’s game in order to pitch a strike, hit a home-run, or execute a double-play. The limited context that does appear has to do with the optimizing performance. A pitcher does need to know the preferences and history of the batter who is at the plate, just like the batter needs to know if the pitcher has a wicked slider. <o:p></o:p></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Companies want to be “green” these days and have instituted policies to shutdown computers overnight. This may be pennywise and pound foolish. Here’s why. A consultant gets paid $50/hr and it takes 30 minutes to get their workspace ready after an overnight shutdown lasting from 5pm to 8am the next day, 15 hours. A conservative energy estimate would be if electricity costs $0.25 a kilowatt hour multiplied by 15 hours for a cost of $3.75. So $25 is spent trying to save $3.75. That’s motivation to use the hibernate feature at a minimum. It also is a very simple way to quantify the cost of context.<o:p></o:p></div><div class="MsoNormal"><br />
</div><div class="MsoNormal">Can we describe jobs by how much context is required? If so, is there a relationship between the amount of context needed and the average salary? Those are interesting questions, maybe I’ll cover those in a later post. <o:p></o:p></div><div class="MsoNormal"><br />
</div></div>Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com2tag:blogger.com,1999:blog-16341181.post-91583919277267538152010-01-21T09:30:00.004-06:002010-04-09T13:44:31.446-05:00Programmings Best Kept SecretSoftware development is often compared to engineering or construction which has a hidden and debatable assumption that the source code is the product. One camp has declared that <a href="http://c2.com/xp/TheSourceCodeIsTheDesign.html">source code is the design </a>. Other camps declare that programming as a branch of applied mathematics; see Dijkstra's "<a href="http://www.cs.virginia.edu/%7Eevans/cs655/readings/ewd498.html">uncomfortable truth</a>" quotes. Extreme Programming as a <a href="http://codewright.blogspot.com/2009/06/why-extreme-programming-fails.html">movement may have failed</a>, it at least served as the flashpoint for a new examination of the nature of programming. Instead of arguing about engineering we can brag about how <a href="http://www.agilemanifesto.org/">Agile</a> we are or that we are <a href="http://manifesto.softwarecraftsmanship.org/">Software Craftsmen</a>.<br />
<br />
Programmers are not engineers, nor are they artists. Even when they are compared to craftsmen, the comparison is always with woodworkers or blacksmiths. Programmers are nothing of the sort, <a href="http://codewright.blogspot.com/2009/09/software-as-literature.html">programmers are writers</a>. Danny Thorpe discusses how you might tell <a href="http://dannythorpe.com/2009/06/29/software-as-literature/">what sort of literature your app may be</a>.<br />
<br />
Danny is on the right track but when it comes to software, there is an elephant in the room that needs to be discussed in the open. Developers do not produce software, they write code. This means that sometimes they need the logic skills of an engineer but just as often they need the communication skills of a poet. Reading and writing, thinking about how to achieve a desired affect through the written word, those are the qualities of a writer. It just so happens that the one of the chosen audiences is a<a href="http://codewright.blogspot.com/2009/06/what-did-you-say.html"> single-minded overly-literal pendantic polyglot idiot-savant</a>, otherwise known as a computer. The other audience is other humans that may or may not have to actually follow the instructions, they do have to understand them well enough to tell if the instructions are correct.<br />
<br />
<br />
It would be useful to compare programming to other fields and see how the comparison holds up. It is not a coincidence that the games industry has adopted the filmmaking model for the production of games. Good choices would be publishing a book, producing a movie, or creating a recipe.<br />
<br />
<br />
<span style="font-size: large;">Programming as publishing</span><br />
<br />
<br />
Programmers are the authors. The compiler is the printing press. Publishers are the companies that agree to fund the process in hopes of turning a profit. Self publishing would be like creating training manuals for internal use; no profit is involved but the medium is appropriate for other reasons. The book still needs to be edited, proofread, typeset, marketed, etc. <a href="http://codewright.blogspot.com/2009/05/myth-of-code-construction.html">I've covered this ground before</a> but there is still much to contemplate.<br />
<br />
<br />
<span style="font-size: large;">Programming as filmmaking</span><br />
<br />
<a href="http://en.wikipedia.org/wiki/Filmmaking">Filmmaking </a>is in interesting comparison because it deals with translating the written word into another medium. Programmers are the writers of the scripts and screenplays. The producer is the stakeholder who desires the software. The director is the project lead. Instead of actors and crew we have the compiler which takes our instructions and executes whatever script of commands we provide; call it a screenplay or call it an application, the actions and actors my be different but it's still a set of commands given to actors to be performed.<br />
<br />
<br />
<br />
<span style="font-size: large;">Programming as cooking</span><br />
<br />
Programmers create a recipe for a given dish. The recipe is not the final product, the result of following the recipe is. You don't buy a cookbook for the fabulous chocolate cake recipe, you buy it because you want to eat the cake. In this case the compiler would be the tools available to the chef; pots and pans, utensils, and the stove/oven. Having the right tools really helps but even the best oven won't correct a recipe that calls for 2 cups of vinegar for the sugar cookies. Eventually software may survive the <a href="http://yro.slashdot.org/article.pl?sid=09/02/25/232212">patent wars</a> and finally be considered on par with a recipe; instructions to a cook in order to produce the desired product.<br />
<br />
<span style="font-size: large;">Summary</span><br />
<br />
Software is actually a mix of disciplines, all trying to contribute towards a common goal. The game industry may have it right, evidenced by them being to busy producing games and not endlessing debating whether their process is broken or <a href="http://codewright.blogspot.com/2007/04/technology-is-harsh-mistress.html">seeking the latest silver bullet</a>. They use directors, producers, art and sound specialists, etc. The compiler is their camera, used to capture the intent of the contributors; the CPU the silver screen for which to project the final product for consumption by the audience.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-48214816576978035942009-12-29T08:37:00.003-06:002009-12-29T08:37:00.235-06:00Of Rockstars and BricklayersToday we're going to start with a thought experiment. You are one of the better coders in your company. All the proof I need is that you're reading this. Ok, that may be a little self-serving but it is true that the better coders I know are always reading something about coding. It might be a new language, or a new technique, a <a href="http://stackoverflow.com/">programming question and answer site</a>, or even a site that likes to <a href="http://thedailywtf.com/">rag on bad code</a>. <br />
<br />
Based on how many <a href="http://codewright.blogspot.com/2005/12/codewright-and-code-monkey.html">Code Monkeys</a> you know, it's easy to figure yourself in the top half of programmers, a 'good' coder if you will. An assumption that is easy to make is that the higher your productivity the higher your pay. Is this true? If you base it on simple experience, the answer is no. It's too easy to get a job right out of college and get mediocre raises and then find yourself interveriewing candidates for openings in your own group where you have to offer 'market rates' to attract anybody. If you've been there for 5+ years, given a company desperate to hire warm bodies, it doesn't take much for the new guy to be making 15-25% more than you even if he is a two-finger typist and can't spell SQL if you spotted him the 'S' and the 'Q'. <br />
<br />
<br />
Now, I'm happy where I am but it didn't take much to trigger my bad habit of thinking up 'what-ifs'. The Stackoverflow podcast has been a good one for this sort of pondering. Jeff and Joel have enough real-world experience to bring a ton of wisdom to the discussion on programming as it's own topic and in episode #42 <a href="http://itc.conversationsnetwork.org/shows/detail4017.html">discuss underperforming programmers</a>. I'd been reading about how star actors can command huge salaries based on their past work and the expected effect on the box-office if their name appeared on the marquee. That major-league sports can have individuals who make 10-times what the lowest paid athlete makes on a single team, it doesn't take much to ask why programming doesn't see the same effect. <br />
<br />
I submitted this as a question to the Stackoverflow podcast which they spent a good 10 minutes on in <a href="http://itc.conversationsnetwork.org/shows/detail4328.html%20%20-%20Transcript%20wiki:%20https://stackoverflow.fogbugz.com/default.asp?W29113">episode 77</a>. It didn't fit so well as a <a href="http://stackoverflow.com/questions/1767957/paying-great-programmers-more-than-average-programmers">question on Stackoverflow itself</a>, I suspect the culprit is the lack of code snippets. Interestingly enough I discovered the podcast when they were at episode 65 and decided to start listening back at #1 and was up to around #42 when I decided to contribute my question. So anyway, when I saw the summary for #77, I didn't have the audio handy so jumped over to the<a href="https://stackoverflow.fogbugz.com/default.asp?W29113"> transcript wiki for #77</a> and read the transcript. It was a pleasant surprise at how engaged they were and that the question wasn't dismissed out-of-hand. When I downloaded the audio, to hear their discussion it only reinforced my reaction. <br />
<br />
The range of talent can be mighty wide even if there is some disagreement on the empirical numbers. Joel Spolsky talks about the <a href="http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html">difficulty in finding great programmers</a>, and uses similiar metaphores in a<a href="http://www.joelonsoftware.com/articles/HighNotes.html"> comparison with opera singers</a>. Jeff has a similar take on <a href="http://www.codinghorror.com/blog/archives/001214.html">Coding Horror</a>. Finding great talent is hard because there are only so many people who can do what you need done. <br />
<br />
There have been some good discussions that has surfaced. <a href="http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity/">John Cook</a> has a good argument based on lack of meaningful metrics. It's a question that has been around for awhile. <a href="http://www.revsys.com/about/bio/frankwiles.html">Frank Wiles</a> makes the claim that hiring average (or below) programmers<a href="http://www.revsys.com/blog/2007/aug/05/a-guide-to-hiring-programmers-the-high-cost-of-low-quality/"> actually costs your company money</a> (<a href="http://www.revsys.com/blog/2007/aug/08/followup-to-a-guide-to-hiring-programmers/">followup post</a>). Obviously when a company says they only hire the to 10%, they are deluding themselves or at least paying lip-service to wanting good programmers. Joel does a great job of <a href="http://www.joelonsoftware.com/items/2005/01/27.html">shattering that particular illusion</a>. <br />
<br />
What about sales? In some fields top salesmen can bring home seven-figure incomes so we know that the wide range of incomes aren't limited to Hollywood and the big leagues. <a href="http://baselinescenario.com/2009/12/24/salespeople-and-programmers/">James Kwak</a> picks up on John's post and supports Joel and Jeff contention that paying the top performers much more than the average, outside of easily measured areas like sales and movies, has a corrosive effect on the group and the best coders end up leaving for greener pastures while the dregs hang on for dear life or are eventually pushed out. I can't disagree. It seems that if you are underpaid you have to ask yourself Ann Lander's question, "Am I better off leaving or staying put?" Just realize that it's no use complaining to the company, the status quo works for them.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-3308370155871510622009-12-21T14:53:00.007-06:002009-12-22T13:36:40.693-06:00Life's Too Short To Work For Clowns.One of the cliche's of our culture is the little boy who rebels against his parents and dreams of running away to join the circus. His mind is filled with the glamor of the Big Top, the exotic animals, the independence of wandering the country from one town to the next. He hasn't really thought about what it means to work in a circus. The Ringmaster did many menial jobs before arriving in the spotlight. The animals have to be cared for; double the time it takes to feed them when you consider both ends of the animal. Traveling from town to town may sound romantic until you realize it means you spend more time traveling than in one place, lots of lonely nights on the road regardless of the weather or climate because 'the show must go on" after all. The life of a circus is not just popcorn, parades, and pretty girls.<br />
<br />
I ran across a quote in Christopher Duncan's, "The Career Programmer: Guerilla Tactics for an Imperfect World" that made me both laugh and sigh.<br />
<br />
<blockquote>You need to consider one additional thing when trying to convince management the current approach to developing software needs improvement. What do you do if non of this sways them and they insist on continuing with chaotic development approaches that consistently create disasters and stress? Update your resume. Life's too short to work for clowns.<br />
</blockquote><br />
So the question becomes, do you work for clowns? Does the development process at your company make a circus look like a well-oiled machine? You might work for a clown.<br />
<br />
I plan on putting together a complement to <a href="http://www.joelonsoftware.com/articles/fog0000000043.html">The Joel Test</a> where instead of a list of things a company does before you consider working for them, The Clown Test would be a list of things that indicate you might work for clowns.<br />
<br />
This might describe your boss,<br />
<br />
<ul><li>if he thinks an <a href="http://codewright.blogspot.com/2009/04/estimate-by-any-other-name.html">estimate is a promise</a>,</li>
<li>if he thinks <a href="http://codewright.blogspot.com/2009/04/programming-as-social-activity.html">developers are interchangeable </a>with no effect on the schedule,</li>
<li>if he thinks its ok for the lead developer to <a href="http://codewright.blogspot.com/2009/06/why-extreme-programming-fails.html">publicly berate a junior developer</a>,</li>
<li>if he thinks <a href="http://codewright.blogspot.com/2006/08/compost-heap-theory-of-development.html">requirements documents are a waste of time</a>,</li>
<li>if he thinks the <a href="http://codewright.blogspot.com/2007/01/have-design-will-travel.html">only place for designers</a> is at a fashion show,</li>
<li>if he thinks he just needs <a href="http://codewright.blogspot.com/2005/12/codewright-and-code-monkey.html">one good programmer</a> who can code anything,</li>
<li>if he thinks that people <a href="http://codewright.blogspot.com/2009/04/chapter-5-programming-team.html">whine too much about teamwork</a>,</li>
<li>if he believes in <a href="http://codewright.blogspot.com/2007/04/technology-is-harsh-mistress.html">Silver Bullets</a>,</li>
</ul><br />
he might be a Tech Clown.<br />
<br />
My apologies to Jeff Foxworthy.<br />
<br />
When you run across a good example of a Tech Clown, send 'em my way and I'll add it to the list for every one's enjoyment.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-86472143220441351102009-12-11T09:13:00.000-06:002009-12-11T09:13:00.127-06:00The Myth of the Aging DeveloperI question that I've heard throughout my career is, "<a href="http://stackoverflow.com/questions/972611/old-developers-any-future">What happens to older software developers?</a>" The danger with this question is when the discussion turns to the implied version which is "The lack of older developers means that it is a young persons game." Nothing could be further from the truth..<br /><br />My wife and I are both developers. We have both been working as developers for 15+ years. One thing we noticed was that there were a lot of people working as developers who really shouldn't be, they didn't have the aptitude, interest or sometimes even the background. It would be easy to dismiss the problem as a <a href="http://codewright.blogspot.com/2005/09/education-of-codewright.html">lack of proper education</a> but that doesn't explain the developers who lack a CS degree but who can code circles around veteran devs. Those folks usually decide that programming is not for them and move on to different job. Some go into management, some become analysts, while others change careers completely.<br /><br />What's left? The ones who are passionate about development and are interested in doing it right. They love learning new stuff and don't gripe about how things used to be in "The good ole' days." They might be grumpy but they usually know their stuff.<br /><br />The main problem would be in finding management who doesn't have a pre-conceived notion about what makes a good developer. If they feel that only the younger ones have the stamina to keep up with the pace, I'd wonder whether those same employers were the same ones who believe that the 'Deathmarch' style of project management is standard operating procedure. They'd rather grind through fresh-meat developers (<a href="http://codewright.blogspot.com/2005/12/codewright-and-code-monkey.html">Code-Monkeys</a> anyone?) than listen to the experienced ones and change their development process much less change their <a href="http://codewright.blogspot.com/2008/11/tale-of-two-managers.html">management style</a>.<br /><br />Lastly, I've noticed that doing nothing but coding holds less business value than being able to communicate with customers, users, management, and vendors. One reason you start coding less is because finding answers to ambiguous requirements takes more experience and provides more payback to the business.<br /><br />My advice, to those who worry about their coding future, would be to find a place where they need experienced developers to help with the overall task of creating or maintaining software, that also gives you the opportunity to code regularly. That way you can have the time to keep up with industry changes while taking advantage of your understanding of software development.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-91632356678666598442009-12-08T07:18:00.000-06:002009-12-08T07:18:00.223-06:00What I learned about Cryptography<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_ikmwGzALbOc/SwzDmAgFl_I/AAAAAAAAAPk/3kF8ODCA8YA/s1600/Scytale1.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px; height: 240px;" src="http://4.bp.blogspot.com/_ikmwGzALbOc/SwzDmAgFl_I/AAAAAAAAAPk/3kF8ODCA8YA/s320/Scytale1.jpg" alt="" id="BLOGGER_PHOTO_ID_5407912310302152690" border="0" /></a><br />In preparing a presentation on cryptography for a graduate class, I was surprised by what I learned. <br /><br />Cryptography has been used from ancient times through the Industrial Age to the modern day. It's been used for military, diplomatic, criminal, and commercial purposes.<br /><span style="font-size:130%;"></span><br />In the simplest and oldest form, Greeks used strips of paper wrapped around sticks of a certain size called a scytale - rhymes with Italy.<br /><br />Julius Caesar is one of the first known users of the simple letter substitution method. The modern day cousin is ROT13.<br /><br /><blockquote>If he had anything confidential to say, he wrote it in cipher, that is, by so changing the order of the letters of the alphabet, that not a word could be made out. If anyone wishes to decipher these, and get at their meaning, he must substitute the fourth letter of the alphabet, namely D, for A, and so with the others.<br />—Suetonius, Life of Julius Caesar </blockquote><span style="font-size:130%;"></span><br />Hiding messages (steganography) is as old as the ancients. An example would be a tattoo on a shaved head. The hair would grow back hiding the tattoo. A modern example is hiding text in the pixels of a digital image.<br /><br />Charles Babbage is a name taught in every into to computer science class as a pioneer in computing machines. I never knew that he helped the English during the Crimean War by breaking cryptological codes.<br /><br />Mary "Queen of Scots" was caught when one of her secret codes were broken.<br /><br />The Voynich Manuscript may have been an elaborate hoax to defraud a king, who had a interest in mysteries like coded messages, out of a large amount of gold.<br /><br />A mob boss used encrypted messages to give out orders to his lieutenants and was arrested when the police cracked his amateur code.<br /><br />Cryptography is thousands of years old and is used all around us everyday.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-23954936703163952332009-12-03T08:52:00.007-06:002009-12-11T08:14:17.784-06:00Programmers - Poets or Mathematicians?Programming software is much like writing a story. Any given story can be told in a near-infinite number of ways and those who practice the craft will spend just as much time, if not more, arguing over the style of a work, as if their subjective opinion can suddenly become objective fact. Usually this leads to a contest of "If you don't agree with me, I'll just keep talking until you see reason" or otherwise known as talking the subject to death.<br /><br />I thought I'd shine some light on an example of this issue in programming. There is a never-ending debate in programming circles about the 'proper' way to write code that creates some true/false decision. Stackoverflow has a <a href="http://stackoverflow.com/questions/423823/whats-your-favorite-programmer-ignorance-pet-peeve/424005#424005">good example of this</a>.<br /><blockquote><br /><div class="post-text"><p>My personal pet peeve (petty but my teeth grind everytime I see it) is verbosely setting booleans, e.g.</p> <pre class="prettyprint"><code><span class="kwd">bool</span><span class="pln"> isValid</span><span class="pun">;</span><span class="pln"><br /></span><span class="kwd">if</span><span class="pln"> </span><span class="pun">(</span><span class="pln">percentage </span><span class="pun">>=</span><span class="pln"> </span><span class="lit">0</span><span class="pln"> </span><span class="pun">&&</span><span class="pln"> percentage </span><span class="pun"><=</span><span class="pln"> </span><span class="lit">100</span><span class="pun">)</span><span class="pln"><br /> isValid </span><span class="pun">=</span><span class="pln"> </span><span class="kwd">true</span><span class="pun">;</span><span class="pln"><br /></span><span class="kwd">else</span><span class="pln"><br /> isValid </span><span class="pun">=</span><span class="pln"> </span><span class="kwd">false</span><span class="pun">;</span><span class="pln"><br /></span></code></pre> <p>whats wrong with </p> <pre class="prettyprint"><code><span class="kwd">bool</span><span class="pln"> isValid </span><span class="pun">=</span><span class="pln"> percentage </span><span class="pun">>=</span><span class="pln"> </span><span class="lit">0</span><span class="pln"> </span><span class="pun">&&</span><span class="pln"> percentage </span><span class="pun"><=</span><span class="pln"> </span><span class="lit">100</span><span class="pun">;</span><span class="pln"><br /></span></code></pre> <p>It's soooooo much more succinct and easier on the eye</p></div></blockquote><div class="post-text"><p></p> </div>Even though the single line version isn't the most complex, different people read through code in different ways. A single expression can be easily parsed by people who have a math background or are experienced coders. That's not the point. The expanded version reads more like a sentence than a formula. It's easy to forget that there are plenty of coders without a background in math. It really comes back to the preferred style of the <i>reader</i>. Do they prefer reading expressions and formulae or something more like human speech.<br /><br />Homer's <span style="font-style: italic;">The Illiad</span> and <span style="font-style: italic;">The Oddessy</span> are ancient works dedicated to expressions of speech. They were originally poems that were passed down in an oral tradition and meant to be sung instead of read.<br /><br />Euclid's <span style="font-style: italic;">Elements</span> is a work dedicated to expressions of logic. It covers objective proofs and unambiguous facts and is the beginning of the mathematical tradition, if you will, of rigorous scientific thinking.<br /><br />The problem we face in software is code is a form of human expression, with all the imprecision that entails, attempting to communicate with the utterly logical CPU; programmers will be forever trying to translate "An Ode to the Machine" into the Pythagorean Theorem.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com2tag:blogger.com,1999:blog-16341181.post-81293988587829166782009-12-01T08:27:00.007-06:002009-12-03T13:58:12.885-06:00If Gulliver Were a DesignerThe term 'Design' gets thrown around a lot in software developer circles. There are constant flamewars over favorite techniques and battles over what good design really entails. When those arguments start getting too <a href="http://en.wikipedia.org/wiki/Ad_hominem">ad hominem</a> figure out whether the speaker is a <a href="http://codewright.blogspot.com/2005/12/codewright-and-code-monkey.html">Code Monkey </a>before giving them much credence. Since I've already braved the waters, see "<a href="http://codewright.blogspot.com/2007/01/have-design-will-travel.html">Have Design Will Travel</a>" or "<a href="http://codewright.blogspot.com/2006/08/age-of-design-review.html">The Age of the Design Review</a>", instead of safely avoiding the issue, I'm going to bravely (or foolishly) join the fray.<br /><br />Realize that there is more than one type of 'Design'. Design in the large turns into architecture and is something that really only comes with experience. Designing at the lower levels, say at the individual class/object level is easier to cover. Today I'm writing about design in the small vs the large; <a href="http://en.wikipedia.org/wiki/Gulliver%27s_Travels">Lilliput vs. Brobdingnag</a>.<br /><br />The issues with designing a class is the same regardless of platform or language. The key is whether an object should be autonomous or whether it is better for any given behavior to be spread out among objects with limited scope and distributed responsibility.<br /><br />For each class the answer might be different. We end up with a spectrum along which we can place classes based upon the <span style="font-weight: bold;">Density of Responsibility</span>.<br /><br /><pre> (Level of responsibility for behavior)<br /> Autonomy - - - - - - - - - - - - - Dependence<br /> High<br /> C - [god object] [spaghetti]<br /> l -<br /> a -<br /> s - <br /> s - <br /> - <br /> s -<br /> i -<br /> z -<br /> e - [template] [framework]<br /> low<br /></pre><br /><br />Let's say you favor letting the class perform all the behaviors itself, or as many as you can. Starting on the left side of this graph, when you make your class more autonomous, the size of the class will grow unless you continuously refactor it to make it more generic. This leads to a <span style="font-weight: bold;">template</span>. If no refactoring is done, the tendency is for the class to become more "<span style="font-weight: bold;">god-like</span>" because if there is some behavior it needs, it has a method for that - it can do anything and everything. The number of fields and methods grow and soon become both unmanageable and unavoidable. Since the class already does so much, coders would rather add to the monstrosity than try to piece it apart and cut the Gordian knot.<br /><br />The right side of the graph has classes that depend on other classes to a large degree. If the dependency level is high but the individual class is small, that is a sign of a <span style="font-weight: bold;">framework</span>; each class doesn't do much and requires lots of dependent classes to accomplish some function. On the other hand, a highly-dependent class that also has a large amount of code is a sign that the class is full of <span style="font-weight: bold;">spaghetti</span>.<br /><br />The key to this question is to determine where you feel more comfortable on the graph. In any event, individual classes will end up spread out on the graph unless some organizational principle is applied, which is how you can achieve the results of <span style="font-weight: bold;">Template</span> or <span style="font-weight: bold;">Framework</span>.<br /><br />Having just written that, I would say that there is a correlation between class size and degree of organization. Robert C. Martin (or "Uncle Bob") covers similar ground with package dependencies in his very thorough paper on <a href="http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf">Design Principles and Design Patterns</a>[pdf]. <a href="http://www.ibm.com/developerworks/java/library/j-ap01117/">JDepend</a> is an implementation of the ideas behind the graph on page 26 and complements <a href="http://www.ibm.com/developerworks/java/library/j-ap01117/">static analysis tools</a> such as <a href="http://checkstyle.sourceforge.net/">Checkstyle</a> and <a href="http://pmd.sourceforge.net/">PMD</a>.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com2tag:blogger.com,1999:blog-16341181.post-33881517212180650372009-11-02T05:19:00.001-06:002009-11-02T05:19:01.369-06:00Extreme Programming is PeopleThere has been an enormous about written in the blogosphere on ways to improve how we write software. Much of the virtual ink spilled on the Internet about <a href="http://codewright.blogspot.com/2009/06/why-extreme-programming-fails.html">Extreme Programming</a>, or Agile, or SCRUM, gathers at opposite ends of the spectrum. Some focuses on how those practices make things better, usually in a overly enthusiastic way which invites the curt dismissal as nothing more than hype and hyperbole. Others constantly remind everyone that they've tried it and it didn't work which invites observations about anti-social programmers.<br /><br />Both camps need to call a truce. They'll get much farther - and be happier - if they stop throwing grenades at each other and start talking to each other.<br /><br />We can get both sides to agree that the previous ways of software development is problematic and certainly non-optimal, at least if the goal is to develop acceptable software in a reasonably quick, consistent, and effective manner.<br /><br />Once we've agreed on common goals, we can discuss typical obstacles and plan ways to avoid or mitigate them. One of the biggest problems, and least discussed, is how people affect the processes in which they participate. There is a good article by Alistair Cockburn about this phenomenon. His paper is titled "<a href="http://alistair.cockburn.us/Characterizing%20people%20as%20non-linear,%20first-order%20components%20in%20software%20development">Characterizing people as non-linear, first-order components in software development</a>".<br /><br /><span style="font-weight: bold;font-size:100%;" >The Story of Joe and Al</span><br /><br />So let's examine more of the laws and how they affect an effort to introduce Extreme Programming. People who use the <a href="http://www2.tech.purdue.edu/cgt/courses/cgt411/covey/48_laws_of_power.htm">48 Laws</a> as a handbook for how to live their lives are usually label as evil, justifiably so. I don't want this discussion to degenerate into name calling or dismissed because of guilt by association so let's create two personas as our antagonist and protagonist. We'll call the willing and manipulative one Joseph (think Stalin) and the unwitting and hapless one Al (think Flowers for Algernon).<br /><br />Law #1 "Never Outshine The Master". Humans are sensitive about losing face in front of others. Joseph uses this to his advantage to keep from attracting the wrong kind of attention. Al is proud of his achievements and doesn't understand why others don't share in his celebration. <br /><br />Law #2 "Never put too Much Trust in Friends, Learn how to use Enemies" - Joseph keeps reminding himself to watch out for number one. He doesn't want to put his fate into the hands of others which means fewer allies but also fewer fair-weather friends. Al, on the other hand, cannot comprehend the idea that people have hidden motives even while having repeated instances of being taken advantage of. <br /><br />Law #3 "<span style="font-style: normal;font-size:100%;" >Conceal your Intentions"</span><span style="font-size:100%;"> </span>is "Do unto others before they have a chance to do it to you". Keep the knife hidden from your intended victim. Joseph believes that life is a <a href="http://en.wikipedia.org/wiki/Zero-sum">zero-sum game</a>. Since he values himself over all others, he won't lose any sleep taking what he wants so he'll have more. He's interested in power and control, if he takes it from you it means you'll be powerless to respond after his power grab is fate de'compli. Al doesn't have the mental capacity to think one thing while saying or acting another. <a href="http://en.wikipedia.org/wiki/Nineteen_Eighty-Four">George Orwell's "Doublespeak"</a> would be a foreign concept.<br /><br />Law #7 "Get others to do the Work for you, but Always Take the Credit". Some <a href="http://stackoverflow.com/questions/1205191/what-are-things-that-make-a-programmers-life-miserable/1237117#1237117">poor soul</a> on <a href="http://stackoverflow.com/">StackOverflow</a> called this a "Seagull Manager - a scavenger who takes all the credit for your hard earned work and hangs around you like a bad smell." This will be a common behavior for Joseph who lacks scruples and thinks those who let him get away with it deserve to have their credit stolen. Al believes what society preaches in public, the value of hard work, work hard and keep your nose clean and you'll get what's coming to you, etc. He has the pride of the workman where good work will be recognized and rewarded. Combine that with no ability to detect deceit in others and you end up with someone who becomes the pawn of others. Naively believing the promises of their antagonists.<br /><br />You can't approach a social situation as if everyone has the same motivations. Workplaces have plenty of Josephs blending in waiting for any situation to turn to their own personal advantage, and Algernons trying in vain to be accepted. If we don't recognize that, we'll be like farmers watering their crops with beer, "It tastes good to me so it must also be good for growing corn."Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-58002075855960347092009-10-28T06:34:00.002-05:002009-10-28T09:49:59.550-05:00Chapter 5 - The Programming TeamThis continues <a href="http://codewright.blogspot.com/2009/02/review-psychology-of-computer.html">my review</a> of "The Psychology of Computer Programming" by Gerald M. Weinberg.<br /><br />So far we've had individual programmers either working solo or in an environment where other programmers work but on separate tasks. As long as a single person can maintain the conception of the program, conflict resolution involves the thinking of a single individual, regardless how much advice is available or heeded. When a problem is too large for one person to hold in their mind at once, the scale of the problem goes up due to the increasing communication needs but is now one of a different kind. In this second case,<br /><br /><blockquote>"conflicting technical demands are translated into potential interpersonal conflicts, and a social mechanism must be formed to resolve them"</blockquote>This is part of the territory. Two people with solutions that are mutually exclusive. Programmers are proud of their intelligence and are more than willing to argue their side.<br /><br /><br /><div style="text-align: center;">How A Team Forms<br /></div><br /><blockquote>"As a rough rule, three programmers organized into a team can do only twice the work of a single programmer of the same ability"</blockquote>I'm no longer as convinced of this as I once was. It really depends on how well defined the separation is between the modules.<br /><br /><br /><div style="text-align: center;">Establishing And Accepting Goals<br /><br /><div style="text-align: center;"><div style="text-align: left;"><blockquote>"Social psychologists have verified in other contexts that failure of one or more members to share the group goals affects the group performance -- not only through that member's share but through a reduced performance on the part of the others, for they invariably perceive the division within the group or the indifference of one of the members."</blockquote>A non-programming example of this is when football teams get a new coach; the TV pundits like to use the phrase "They've bought into the new system" meaning that the players have taken the coaches goals for their own. A common programming example you might see in a development shop is where the current toolset and technology stack used is from Microsoft and there is that one guy who keeps muttering under his breath that "Microsoft sucks". His lack of cooperation will be felt by the rest of the team. The result may be that they avoid him instead of sharing the new trick they learned to solve some daily annoyance. <a href="http://codewright.blogspot.com/2009/06/why-extreme-programming-fails.html">No one wants to pair-program with him</a>. The price being paid, at a minimum, is the reduced productivity of the frustrated Microsoft-hater.<br /><br /><br /><br /></div></div></div><div style="text-align: center;">The Team In Crisis<br /></div><blockquote>"The replacement of a leader--or any team member--is probably the most frequent and typical crisis in the life of a team. The effect of adding or removing a member depends quite sensitively on the group structure, and many a manager has been unpleasantly surprised at the change in performance resulting from the removal or addition of an 'insignificant' group member. "</blockquote><br /><br /><div style="text-align: left;">If we need proof that programming is a social activity, we need look no further. Unless you are the sole programmer working at a company or on a project, there will always be a social aspect to what you do. I'll go even farther and say that unless you are the only person who will use the application, there will inevitably be people involved, from the person who asked you to write the app to the person who will be using the app.</div><br /><blockquote></blockquote><blockquote>"A member who is competent but who does not get along with the others can be an even more serious problem for the democratic group than an out-and-out incompetent. In an authoritarian group, such a member would not have much contact with others on a working basis anyway, so as long as he gets along adequately with the leader, he presents no particular problem. Indeed, some programmers prefer to work under a strong, centralized leader in order that they do not have to socialize with their fellow workers. But in a democratic team, an antisocial member cuts lines of communications and is a constant impediment to consensus in team meetings."</blockquote><br />Sometimes we are <a href="http://codewright.blogspot.com/2009/06/we-have-met-enemy.html">our own worst enemy</a>. If we want to stay our of our own way, we need to remember in software development, <a href="http://alistair.cockburn.us/Characterizing%20people%20as%20non-linear,%20first-order%20components%20in%20software%20development">people are the biggest cause of failure</a>.<br /><br /><br /><br /><br /><div style="text-align: center;">Summary<br /></div><br /><div style="text-align: center;">Questions<br /></div><br />For Managers:<br /><br />- Are your hiring practices such that you get more uniformity on teams that you would like? When making up teams, do you try to see that a good "mix" of people is on each one, or do you strive in the opposite direction?<br /><br />- Do you ever do things to try to inflate the appearance of your technical competence in front of the people who work for you? Describe some of these incidents, and also some incidents in which it was discovered that your technical competence was in at least one respect inferieor to one of the people who work for you. What were the consequences of that discovery, and do they justify attempting to cover up?<br /><br />- In setting your own working goals, what part is set by what is passed down from above, and what part is set by what comes up from below? Are you satisfied with this arrangement, or would you like to alter it in some ways?<br /><br /><br />For Programmers:<br /><br />- What part of programming work do you do best? Are you permitted to contribute that best part of your work to your team, and is it generally recognized that it is the best part of your work?<br /><br />- Has your manager ever done anything to make you doubt his honesty? If so, describe the incident, what ultimately happened to your doubt, and how your work was affected.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0tag:blogger.com,1999:blog-16341181.post-38698338071369604962009-10-01T09:09:00.006-05:002009-10-30T17:32:25.403-05:00Peanut Butter ProgrammingWhen I first started messing with dynamic web pages it was using Perl and CGI. It was fun at first getting a page to respond based on some algorithm. It was also easy to overlook the growing mound of HTML strings embedded in your program. It soon became apparent that this approach doesn't scale very well. Keeping track of which tag needed to be closed and when was too much like keeping track of dynamic memory allocations in C.<br /><br />Java came along with Java Servlet Pages (JSPs) and it seemed like a huge improvement. By inverting the relationship between code and HTML, you didn't have to have your HTML all strung out in little bits in the program. When you wanted to include some program logic in your page, you had two choices: write an extension so your logic could be expressed like an HTML tag, or you could embed it as a code-snippet directly in with the HTML. While there were plenty of examples of how to create your own tags, the overwhelming amount of JSP code I've seen took the other approach. To the extreme. When some behavior was needed in multiple places, sometimes it refactored into a common file and then referred to from multiple pages. Other times (which translates to whenever possible), it was copied and pasted around with the justification of "I just need it to work". The result was a file with little bits of program strung out through your HTML. Sometimes mixing two things can prove to be a good thing. remember the the TV commercial for peanut butter cups? "You have your peanut butter in my chocolate! No, you have your chocolate in my peanut butter!" Unlike that TV commercial, mixing HTML and code is a recipe for heartburn. Peanut butter may be tasty but will stick to everything it touches and you'll end up with a greasy mess to clean up if you're not careful. That's why I call this "Peanut Butter Programming".<br /><br />Why do developers keep using approaches like 'cut-n-paste' even though they usually know better? When the choice is between doing the expedient thing and the right, people typically want to do the right thing but only to a point. If 'cut-n-paste' is simpler or easier than doing the right thing, the playing field becomes so tilted that some other motivation needs to be strong enough to deter choosing the short-term solution. Code standards are one example of that kind of motivation. They express a value judgment that the increasing maintenance costs of supporting bad code is not worth the time saved by taking short-cuts. If the programmer knows he'll have to face his peers and explain why he took a short-cut, his choice becomes "I can do it quick-and-dirty (QaD) in 5 minutes instead of the right way which would take 15 minutes. But if I do it QaD, I'll have to spend 30 minutes arguing at the code-review. It's not worth the argument so I'll just do it the right way and save myself the trouble." This sort of balancing act shows up naturally during pair-programming where having the second coder around makes it harder to justify writing messy code on the first pass.<br /><br />Recently, I went to a class on Microsoft's ASP.NET technology. Setting aside any feelings for the company, the way they approached the problem of mixing code and HTML was to make it easier to do the right thing. They introduced the concept of a separate 'Code Behind' file which contains the C# or VB code for a given page. By making it easy to manipulate objects on the page and respond to events while keeping the code separate, they've made the right way also be the easiest way.<br /><br />Even experienced developers will justify taking a short-cut, however short-sighted, if doing the right thing is hard enough to do relative to the short-cut. Different people have different tolerance level for short-cuts. Understanding why people do the things they do isn't easy but gives us the perspective needed to address the problem.Kellyhttp://www.blogger.com/profile/08846371280799024151noreply@blogger.com0