Burning Ones

Posts in ‘Techvana’

• Structure over Flexibility

  From February 25, 2010 @ 8:35 am

  At one time or another, someone thought that each of the following control structures was a good idea:

  …

  • Ability to have the program generate code on the fly and then execute the code it just wrote.

  …

  At one time, each of these ideas was regarded as acceptable or even desirable, even though now they all look hopelessly quaint, outdated, or dangerous. The field of software development has advanced largely through _restricting_ what programmers can do with their code. Consequently, I view unconventional control structures with strong skepticism. I suspect that the majority of constructs in this chapter will eventually find their way onto the programmer’s scrap heap along with computed _goto_ labels, variable routine entry points, _self-modifying code_, and other structures that _favored flexibility and convenience over structure and the ability to manage complexity. – Steve McConnell. Code Complete 2e

  I guess Mr. McConnell isn’t too much of a fan of Lisp. Especially considering that everything he finds wrong with these strange control structures seem to be what Yegge and The Wizards seem to appreciate about the language, although I suppose that Lispers would argue that their language allows them to be far more expressive and semantic about what the crazy things they invent to solve their unique problems are than crummy goto statements…

• Get Kill/Yank and ispell Working in Emacs.app 23.1 on Leopard

  From February 09, 2010 @ 6:00 am

  I recently upgraded from Emacs 23 alpha (the version MacPorts installed by default for a long time) to 23.1 and it broke a few things. I’m going to document how to fix them in a few posts here.

  I’m entirely indebted to the friendly folks at the Emacs Users Mailing List for every solution that I present here. One of these days I’ll know Emacs well enough to troubleshoot my own problems.

  The first issue I noticed was that Kill/Yank (Copy/Paste for all you Emacs laymen at there) no longer worked. The problem lay in the save-interprogram-paste-before-kill function, apparently, but the solution presented to me on the mailing list didn’t make me happy either as I don’t like inside Emacs like many people do. I need to be able to enter text into an Emacs buffer and then get it into other programs. I stopped using Emacs for awhile at this point.

  One day, I decided to try to open Emacs.app via Finder.app and suddenly everything worked! Unfortunately, this also broke any dependencies Emacs had on any software I had installed via the command line. This was because Finder.app doesn’t inherit the bin PATH that you set via .bashrc because, well, it’s not bash.

  The solution here is to continue to open Emacs.app via the command line, but instead of using /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs as I’d been doing prior to upgrading to 23.1, use open /Applications/MacPorts/Emacs.app instead. I don’t know why I never thought of this before. It makes a lot more sense than what I was doing before even if before 23.1 it was working!

  As a corollary to this, another issue that I discovered when I upgraded was that ispell no longer worked correctly. This was a big deal because I don’t like to spell check my own stuff. M-x ispell has to work. The problem was that it could no longer find my installation of aspell because it didn’t evaluate .bashrc to find my PATH settings. Using the open command from Terminal.app solved this as well.

  To review:

  Instead of starting Emacs.app via

  /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs
  

  use

  open /Applications/MacPorts/Emacs.app
  

  from the command line so that interprogram-paste and ispell work.

• Mag+

  From December 20, 2009 @ 6:00 am

  Kottke recently posted an article about this video over on Vimeo from Bonnier R&D about the Mag+, which is an attempt to conceive of what the future of magazines could look like. I thought it was quite compelling. I especially liked the interface for heating up elements in the magazine and then marking them. Having the interface pop up around your finger is a really good idea.

  Anyway, enjoy the embed or click through to watch in HD…

• I Took It…

  From December 16, 2009 @ 8:07 am

  Despite this feeling just a little like those HIV commercials from the mid 90s:

  

• Emacs Wonderful Little Tip™ #n – Don’t Manually Capitalize… Manual Capitalization Is For L00s3rs!

  From November 26, 2008 @ 6:00 am

  I recently picked up Emacs again after being Internet-Slapped by Yegge. It’s funny, but way back in the day after I got my first 13″ iBook (still, in my opinion, the cutest computer every made, which is saying a lot) and began to dive into wondrous Unix (we were still tcsh back then), Emacs was the first program I attempted to learn. Who’s masochistic? /me raises both hands and jumps up and down.

  Anyway, I didn’t know any better at the time and over the years I got tired of trying to integrate Console based Emacs into my daily work flow. All that has thankfully changed, and my cheek still hurts like heck.

  Intros aside, what I have today is a Wonderful Little Tip™ that will be accompanied by other Wonderful Little Tips™ because Emacs is the kind of app that allows you to find Wonderful Little Tips™ all the time.

  I often find myself typing in a title or something to that effect which I would like to have most or all of the words capitalized. The title of this post would be an example. In regular editors, the way to do this is to capitalize every word as you go along manually. This presents a few problems.

  1. Because you’re in an editor other than Emacs, when you forget to capitalize things, it’s a messy process to either arrow-key or delete key backwards to the mistake, delete the mistake, and then reenter as a capital.
  2. Typing capital letters is hard (OK… It’s a bit of a stretch, but I wanted a list, so I needed it), requiring precise and dexterous finger movements which even for seasoned Dvorak touch-typists like myself, every once in awhile goes awry.

  What is the answer to this morass of efficiency conundrums? Who will deliver my hands from this editing of death!? Enter Emacs (OK, now I feel slightly uncomfortable with the subtle Emacs=Jesus suggestion there… That’s just weird, although RMS might actually think that, after all Emacs helps people more than babies do)! Emacs provides these nice text transformation functions that work like magic. They are bound as follows

  • M-u: upcase-word
  • M-l: downcase-word
  • M-c: capitalize-word

  The relevant control sequence for our tip here is M-c. The magic of this is quite simple; Type out a phrase, and then either M-b back through the words, M-a back to the beginning of the sentence, or if it’s all on one line, C-a to the beginning of the line. Then, using a combination of M-f and M-c, capitalize to your heart’s content.

  This is so much faster than actually typing out the capitalized words. I can’t verify that it would save you time to do this for every capitalization everywhere, but for a long string of them, the added benefit of not having to type a separate key sequence each time you want to capitalize a word is astonishing. In fact, it’s so astonishing that I’m going to put together a little video of this function in action…

  You know… because it’s that cool.

  OK, here’s the video:

  
  Emacs Wonder: Text Transformation Control Sequences. from Tim Visher on Vimeo.

• Working the Stand-Up

  From November 20, 2008 @ 1:09 pm

  The organization that employs me began to implement Daily Stand-Up Meetings a little under a year ago. So far, it hasn’t been going well at all, at least in my opinion. First, I suppose I should try to enumerate the purpose, advantages, and disadvantages of the daily stand-up before I discuss what I feel like we’re doing wrong.

  What is the Daily Stand-Up?

  The stand-up is an attempt to promote high-visibility and co-ownership within a team of people working on a singular project. In lieu of the more traditional status meeting approach to the problem of low-visibility, effort is made to keep have short, sweet, to-the-point, and team- (rather than manager-) lead stand-up meetings. Apparently (I’ve never had the good fortune to be actually involved in one of these atrocious things), status meetings have a tendency to descend into nothing more than low-energy wastes of time where people who shouldn’t be involved with each other drone on for an hour, reporting to the boss about this and that configuration item. Commonly, in a stand-up, the emphasis is placed on answering 3 questions with a great degree of brevity (to be clear, I’m lifting these questions directly from Shore and Warden:

  1. What did I do Yesterday?
  2. What will I do today?
  3. What problems are preventing me from making progress?

  In order to maintain energy and to reduce the feeling of interruption, some organic pressure on keeping the meetings short is required. As The Old Boy so elegantly puts it in his excellent essay on daily stand-ups, “We stand up to keep the meeting short.” The thinking is that sore feet and legs will soon remind any gabby team members to speed things up.

  A daily stand-up can also be attended by non-developer stakeholders in the product. This involvement can take the place of a typical status meeting but can also be somewhat destructive. The problem comes when the people who don’t need to be directly involved in the stand-up start to take too much attention away from the real task at hand. For instance, gasping or getting visibly angry if a team member reports that they were not able to progress far enough on a particular configuration item and thus have to push a release date back would be trouble on many fronts. First, it would reduce team members’ ability to speak freely about development issues they are having for fear of blow-back from the stakeholders. Other issues can be left to the reader to imagine. However, despite the danger, oftentimes the stand-up can be a terrific opportunity to state which stories you’re working on, how their coming, whether you think you will meet the project guess date, etc. which in a properly organized team with high customer involvement should be most if not all of what your stakeholders are interested in knowing.

  To sum up, the daily stand-up is a tool for promoting visibility among a team and the relevant stakeholders working on a single product or tightly knit set of products via a low-cost daily event that helps focus the team on important issues and increases the likelihood that any problems faced by a team member will be known to the whole team quickly (at most a day late).

  What isn’t a Daily Stand-Up?

  A daily stand-up should not be any of the of the following.

  1. An opportunity to inform an entire organization of the goings on within a specific project.
  2. A status report meeting used by a manager to gain insight into the goings on of every project under his or her command at one time.

  I’ll address each of these points one at a time. However, before I do that I’ll just point out if you didn’t already catch it that the common theme here is using the stand-up to do more-than-one-team operations. I believe this is a perversion of the stand-up concept and should be rooted out as quickly as possible. This, unfortunately, is how my organization uses the stand-up meeting, and I believe it is contributing to the relative hair-pulling nature of our practice.

  First, the meetings cannot be used to inform an entire organization of the goings on within your project. This misses the whole point of the stand-up in the first place! The idea is to foster communication between interested parties and team members, not to try to report to people who have no stake in what you’re doing. Beyond missing the point, it’s impractical. In my organization, for instance, there is implicit pressure to dumb down what you are reporting on because most of the other people in the room aren’t aware enough of what you’re talking about to be able to intelligently listen (I’m at the very least speaking for myself… 3/4 of the developers at my organization are Main Framers, and I’ll be the first to tell you, I know nothing about main frame programming). Notice, please, that I’m not saying they aren’t intrinsically intelligent enough to be capable of understanding, just that they aren’t aware of the project enough to be able to listen to statements as compact as what a true stand-up calls for.

  We recently began to do a stand-up meeting with just the team members of the project that I’m on (a :cringe: VB6 DB-driven Inventory Tracking System) and the difference is night and day. I feel free and encouraged to share deep technical issues that I’m dealing with because I know the people I’m talking to have knowledge about what I’m referring to. Beyond that, there isn’t as much of a need to preface everything that I’m talking about with lengthy and pedantic explanations because the people I’m talking to know the system at least as well as I do. We’re all in it together. Comparatively, in the whole-organization stand-up I take part in, I know 3/4 of the people have absolutely no stake and very little knowledge about what I’m doing. This is counter-productive and as such it’s harmful to morale and motivation. My manager has to virtually drag people to the stand-up every morning and encourage people to get started, rather than it being an organic, team-led event, I believe specifically because people know that the rest of the developers there are mostly uninformed.

  Second, and related, the status-report-to-the-manager mentality has no place in a stand-up meeting. In fact, according to the best literature on the subject, a well-run stand-up meeting should eventually have no need at all of a manager. The intrinsic value of knowing what your co-team members are doing, having difficult problems that you face solved with your team members’ help, not having to attend long status meetings with every interested party etc. should eventually garner interest from the team. At my organization, this is decidedly not the case. In fact, a new rule was recently instituted that stand-ups don’t have to happen unless my manager is present. This is of course, counter to the whole idea. A manager should be present when they can be there, but in the end they should only be there as an outside observer, rather than a direct participant (unless of course the manager is specifically acting as the team lead, in which case that is the role they would be appearing under, not as the branch manager). It is this status report mentality that The Old Boy addresses in the Reporting to the Leader section of his essay. This is a surefire way that I have personally experienced of killing the stand-up. When people are not talking to each other and are instead talking to the manager, the stand-up is going to feel impersonal and worthless.

  Are There Any Disadvantages to a Daily Stand-Up?

  The main disadvantages talked about in the literature seem to indicate the following:

  1. When a stand-up is run wrong, it quickly becomes just one more unwelcome interruption to your day rather than a time for team communication.
  2. Even if a stand-up is run right, there is a possibility that it’s timing will distract people from getting work done because either the stand-up starts the day late, or it isn’t at a good time to set the focus for the team.

  Obviously, point one is easily addressed. The remedy for a poorly run stand-up is to stop running it poorly. This might include getting some help for running your stand-up from a more experienced team or consultant firm. The Old Boy does contend that a poorly run stand-up will almost certainly not just ‘fix itself’ and if it is not helped, the likelihood that it will simply die is very high. Point two is a much more difficult problem, however it’s something of a non-starter. The challenges of finding the best time to do your stand-up are small compared to the benefits of a well-run stand-up.

  So How Could We Fix the Stand-Up At My Organization?

  In brief, there are two basic teams at my organization: Main Framers who program mostly in COBOL, and what has heretofore been referred to as Client/Server folks (I think we’re updating that name to Web Appers). The former comprises roughly 3/4’s of the developers. To this day (yes, even after almost a year of stand-ups), I’m still not sure I understand what the Main Framers are working on. I know that there are basically 2 products that the Web Appers are working on and an additional one that is in a state of regular maintenance. That’s our situation to the extent of my knowledge. There are several solutions that I see to the problem we’re facing at my organization, and maybe your organizations face similar issues that could be addressed in similar ways:

  1. Depending on how closely knit the Main Framers’ side is (I sometimes get the impression that it is very closely knit, although I know there are multiple products), the stand-up could at least be split between Main Framers and Web Appers.
  2. The stand-ups could be split up on a per-project basis (this would be a ‘traditional’ stand-up).

  First, there is one advantage to the model that everyone participates in one stand-up. It means that no one has to attend multiple stand-ups. Unfortunately, another characteristic of my organization is that most people are assigned to multiple active-development projects. This is of course quite separate from the notion that once a project is put into maintenance mode, you go on to developing other things more actively. So, if you approach things this way one does not have to do multiple stand-ups. Wonderful… Of course this approach ignores the fact that when you include everyone in a single stand-up, they either have to report on everything that they would have reported on in their smaller per-project stand-ups (yielding the same time spent on balance, and in a much less focused way) or they have to simply not report on things the way they would have otherwise (mucking up the purpose of the stand-up to begin with). Both of the approaches above don’t directly address this problem, however they don’t necessarily have to as the goal is to have only interested parties at any given stand-up anyway so the problem of having to ‘pick and choose’ is a moot point because people will want to be at these stand-ups.

  I see solution one as an incomplete but perhaps necessary solution. The problem is that some people have to be involved in multiple projects and in theory the more stand-up meetings you have, the harder the scheduling becomes. Ideally, my manager would simply travel around to the various stand-ups and listen in to get his status information. Anyone who had multiple stand-up commitments would simply have to work out a schedule with his or her various team members that works for everyone. If absolutely no solution can be found (I can’t imagine this happening, unless severe interpersonal issues were already present), then I would expect the correct solution would be the removal of the person from one of the teams for the sake of focus. However, it’s possible that on the Main Framer’s side there is really only one system that has many parts that they all work on together. It’s not the case on the Web Appers’ side, but it’s a possibility. If this is the case, then the Main Framers at least could gather as one body and this would reduce the chance of scheduling conflicts, as well as promoting chances for self-organization between the different parties. Also, this would at least keep people in their various expertise domains. This would allow people to refer to specific but widely-applicable technical issues they are facing (problems with a specific tool, issues with a particular coding construct, etc.) that the people present would be likely to be able to address.

  However, the true Holy Grail here would be splitting things up into teams. Most of the teams at my organization are no more than 3 or 4 people (usually less) as far as I can tell. That would mean that a given stand-up could go into great technical detail and yet still last for maybe 5 minutes. In contrast, when the whole group gets together and things are time-boxed to 15 minutes, the emphasis on brevity and the problem of global comprehension make it difficult to communicate anything significant briefly. In this solution, people would schedule, of their own accord, stand-ups involving only the team members specifically assigned to that project and would inform the relevant stakeholders (including my manager) of that time. Allowance would have to be made for every stand-up to occur at a unique time (to give floaters the ability to attend them all) unless a situation easily allows for multiple stand-ups to be happening at once. Then, the stand-ups would occur, regardless of my manager’s or stakeholder’s presence, as a team-led effort. As the teams get better at doing these stand-ups, will to do them would also increase. I don’t see the issue of floaters as being a viable one for the reasons I stated above: They should be reporting on everything they’d say anyway, and because of the people involved in any one stand-up, they should feel encouraged to do so.

  Conclusion

  Well, that’s all a mouthful. It boils down to this: Stand-Ups should be brief, to the point, and single team. The challenge of involving a second uninvolved party of any kind simply increases friction and reduces energy. If your organization is doing something like mine is, consider writing something like this as a proposal for change, because the stand-up is too good of an idea to just let go because of bad implementation.

  For Further Reading

  I’ve linked to The Old Boy and Shore and Warden in the article, but here they are in a nice list:

  • It’s Not Just Standing Up – Martin Fowler
  • The Art of Agile Development – Shore and Warden
  • Stand Up Anti-Patterns

  For Pity’s Sake

  I think I understand why my manager is doing this. The culture at my work place is distinctively non-agile. I think that approaching a very valuable practice like the stand-up in this manner is seen as a way to ease my co-workers into the practice. The problem is that the way it is being done is making people less interested in the stand-up, not more. If we really want to get this practice going, we need to do it right.

• Lifehacker Feeds For Your Every Whim (Almost)

  From September 17, 2008 @ 6:00 am

  I’ve been trying to comb down the noise in my feed reader lately and one of the feeds that I still wanted to be aware of but didn’t want to have to process every day was Lifehacker. Awhile ago, Gina Trapani (Note: For some reason her site is down at the moment…) had published on Lifehacker a collection of different RSS feeds that you could subscribe to if you wanted some more catered content, however I have had terrible difficulty turning up that collection in numerous attempts to search for it (BTW, if someone knows the URL for that feed list, please send it to me). However, recently I discovered something that is possibly better and probably has been posted numerous times elsewhere, but… whatever… :)

  There are numerous ways to filter the content in Lifehacker. You can click on the category link at the top of the post, you can filter by author, etc. However, the tip I’m going for works with any of these, I think, because it’s a URL trick.

  Once you filter the site the way you want to (say, by clicking the Highlights Tag) and the URL in the location bar has changed appropriately, simply append index.xml to the URL and, ¡voila!, you have your new feed to be added to whatever reader you choose.

  Of course, if you want finer tuned control, you could go all out with Yahoo! Pipes, but that’s another story for another day I think.

  Enjoy!