June 10th, 2008
Matt Jankowski from GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS just posted an article alluding to his new book (SWARM) and specifically as it related to Kelly Johnson’s 14 Rules of Skunk Works. I found his comments poignant and very applicable to the agile development arena. I have copied his table here for your review — excellent work. I recommend reading the full article at this link.
| Rule |
Skunk Works |
Comment |
| 1 |
The Skunk Works® manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. |
When we bid on a project for clients we explain that they are hiring us for a purpose and because of our expertise. As a result: the more control they can give us, the better the solution that we deliver. |
| 2 |
Strong but small project offices must be provided both by the military and industry. |
We have yet to do military work, but we do send people on site, and when we can get them in a small group with the client stakeholders, a lot can happen. |
| 3 |
The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems). |
Too many cooks ruin the soup, and too many developers or managers ruin the software. A small talented team will consistently out-produce an ‘average team’ many times it’s size. |
| 4 |
A very simple drawing and drawing release system with great flexibility for making changes must be provided. |
Design driven development, with rapid iteration. |
| 5 |
There must be a minimum number of reports required, but important work must be recorded thoroughly. |
Invoice based on trust, not paragraph-long line items. Comment code only when it’s crucial to a future developer trying to understand the problem. |
| 6 |
There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don’t have the books ninety days late and don’t surprise the customer with sudden overruns. |
Always keep the next milestone in sight, and always review whether you’re still focusing on the larger business goal of the project. Don’t spent 40% of development time and money on a feature used by 1% of the audience. |
| 7 |
The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones. |
We’ve gone one step further here – and we refuse to subcontract for another vendor, or to hire a subcontractor when we’re the primary vendor (we’ve learned our lesson on both fronts). Commercial bids are almost always better than non-profit bids (including those for government or quasi-government entities) |
| 8 |
The inspection system as currently used by the Skunk Works®, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don’t duplicate so much inspection. |
We attempt to maintain a set of code quality standards and development best practices which are literally the best in the industry. We want to consistently exceed, by a large margin, any standards or policies that a client has in place. |
| 9 |
The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn’t, he rapidly loses his competency to design other vehicles. |
You must have a staging server that accurately represents the production server. If you don’t maintain your test suite, you cannot work with confidence as change requests come in. |
| 10 |
The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works® practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended. |
Implementation doesn’t start until design is done. Design doesn’t start until a contract is signed. A contract isn’t signed until the spec is done. |
| 11 |
Funding a program must be timely so that the contractor doesn’t have to keep running to the bank to support government projects. |
Work on a milestone never begins if there is a past due outstanding invoice. |
| 12 |
There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum. |
Communication failures kill projects. Daily ‘scrum style’ meetings, or at least regular communication via an online tool is absolutely critical to project success. |
| 13 |
Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures. |
Honor your NDAs. |
| 14 |
Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised. |
Hours worked, meetings held and emails sent are not metrics for success. Quality produced, milestones completed, and profit made are. |
Posted in Uncategorized | No Comments »
June 10th, 2008
Bonjour Services are all the rage now — well at least in the Ruby and GitHub communities they seem to be. Most of these new services are constructed in fast to use Ruby code, which bears the burden of having to get the dnssd gem installed, thus making it not the easiest thing for all users. I think the concept inherent in these microapps is amazing, but really its best when they are all uniform and visible without having to open a separate shell for each. Along those lines, I took some inspiration from the great Twitterrific which provides a similar interface to passive notification information while retaining historical focus. I am working on this Cocoa based Bonjour notification and action application on my off hours and I would love some support. It is posted on GitHub under the project name DuJour.
Posted in Code, Iterative Designs | No Comments »
June 5th, 2008
As if life wasn’t crazy enough (new business, new office, new language learning group, etc.) I have also recently signed up with the new HACDC organization here in Washington, DC. I am not a full member yet, but I have signed up and very excited to get involved with this organization. From their website here is their mission and core concept:
HacDC is a non-profit organization and space dedicated to technical, artistic and social collaboration. We are technologists, tinkerers, crafters and codemonkeys who call DC home. We collaborate across disciplines for the benefit of cultural, charitable and scientific causes. We create, learn and teach as a group, inviting our neighbors around the block and around the world to join us!
If that isn’t the coolest thing ever, I am not sure what is. Very excited about this group.
Posted in Code, Iterative Designs, Personal | No Comments »
June 2nd, 2008
During RailsConf/CabooseConf, Chad Fowler released Gitjour to GitHub. Gitjour is used to serve git repositories and advertise them all using the Bonjour/ZeroConf protocol. It was pretty cool especially in a geeky way, so I took it and ran with it. I am building out GitjourCocoa, which is a RubyCocoa wrapper around the basic concept. This will allow you use Gitjour with the command line and without having to constantly refresh for new repositories.
GitjourCocoa - Fork it.
Posted in Code, Iterative Designs | No Comments »
June 2nd, 2008
I understand that this will either become flame-bait or disregarded, but I felt compelled to say something. I just returned from Portland, OR for RailsConf 2008 and it left such a disgusting taste in my mouth, it will most likely be the last time I go. Mind you, I had my issues with RailsConf 2007, but these for some reason feel drastically different and deeper rooted, so I was compelled to share.
Even before I left I felt that the schedule was incredibly lacking for the nearly $700 (early bird) I had to plunk down just to be allowed to attend. I wasn’t alone in this vain as is evidenced by the uprising of CabooseConf, sort of an alt-RailsConf. The presenters were not the issue either, it was the content. There are serious issues within the Rails community (the view comes to mind) that were just wisked away by presentations about complaints, introductions, and skimpy content. There were standouts, MagLev and Fuzed stand out in my mind and on most people’s twitter feeds, but those were few and far between (and often booked at the same time). A poor schedule is one thing and most times easily overcome, this year was not the case.
What I took away from the conference based on the keynotes was the following unfortunate points:
- You guys don’t know what you are doing and I can prove it by getting you to spend almost (and in some cases more than) $1000 and have a presenter crap on you. Thanks, Spolsky.
- Kent Beck campfires are probably not too exciting, but good if you find 1960’s floppy disk jokes humorous then he is your main man (enjoy that all two of you).
- And the winner that sits in your stomach like plutonium, DHH telling you that its probably time to start looking into other things. You know, flying, buying more O’Reilly books, whatever because well lets be honest, rails isn’t much longer lived.
Seriously, I paid $700 for that uplifting piece of work? If you are going to be an inspirational community dictator leader, then at least take a couple hits of Red Bull and be energized for it. The morning keynotes were dry and most didn’t even cut through the previous night’s first course of drinks. I realize I am starting to sound all Zed Shaw, but thats what this conference needed — something not corporate-y. There needed to be a Why the Lucky Stiff or Zed causing trouble, reminding people “Hey there is a revolution going on, what are you doing about it?” The feeling like we were driving somewhere important was gone and all that was there to replace it was that nasty we just got screwed feeling. The core team was a lot more accessible this year, an issue I had with RailsConf 2007, but that didn’t make up for the overall corporate feeling of the now huge and impersonal conference. Why does RubyConf have a lower cap for attendance than not RailsConf even though RubyConf should encompass Rails? Because RailsConf is the new cash cow of the Scripting community and everyone wants to get at that money-dripping teat before it dries.
I have no thoughts of leaving Rails or Ruby and am committed to getting more involved with things like Merb and DataMapper. All that said, it is highly unlikely at this point that I will go to RailsConf again.
That is all.
Posted in Code, Personal | 3 Comments »
April 25th, 2008
I have recently decided to move one of Iterative Designs internal projects from Prototype and Script.aculo.us over to the lighter JQuery. Without question, I do not recommend migrating a project mid-stream, the changes are just too different and I had to just punt on a couple areas, which on another note helped to identify “used-less” functions.
I wanted to post about an issue that I ran into that is not very well documented and thus decided to add my documentation. If you are using Ruby on Rails with the JRails plugin for RJS compatibility, there becomes a problem with IE 6/7 when you try to delete an object through AJAX. IE 6/7 just doesn’t like the “delete” HTTP verb, meanwhile Firefox almost demands it when connecting to Rails. I spent many nights working on this and decided on to use JQuery as it should be used, which I recommend highly for anyone who is doing this as well. JQuery has adopted as a foundational paradigm the concept of unobtrusive javascript and plugins like the excellent LiveQuery allow you to be unobtrusive during updates as well as onload. My decision was to have rails delete the object using the link_to as opposed to the link_to_remote function and then using JQuery and LiveQuery make it dynamically delete it using AJAX. Even when you do this you have to take into account the special case of IE 6/7 which just dies on the “delete” verb in the $.ajax type attribute. That was the first hurdle of flipping the verb from “delete” to “post” and using the well-known _method=delete hack for getting Rails to route the message correctly. (I say hack, but really its not - its just a way of working with browsers - *cough* IE *cough* - that are stuck in the stone age). After this, IE will nicely pull the attribute for you as an anonymous function instead of string (kthx) which really violates the spec, but hey it wouldn’t be IE otherwise right? Anyhow lots of work to hack this to reality, but now that I have gone through you just need to paste this in and update the selector “a img[@alt=Delete]” to whatever is most appropriate for your system. The nice thing is that if the accessing client does not use javascript, it will work the “old school” post route and degrade gracefully.
Pastie link for the actual Javascript code
Sidenote: I cannot say enough how excellent LiveQuery is, it is the reason all my projects here on out will be JQuery.
Posted in Code, Iterative Designs | No Comments »
April 2nd, 2008
It’s a comic, but quite a funny one. [diesel sweeties]
Posted in Uncategorized | No Comments »
March 31st, 2008
This is for my wife architect who always gets the most interested when people ask what she does for a living. She gets frustrated sometimes when she says she is an architect because EVERYONE “was going to be an architect”. What a glam job (or at least so it seems in the guidance counselor’s office). I think these cards provide a better way to say that she is an architect, hope she prints them out and takes them with us to the next tech happy hour.
I’m an Architect link
Posted in Uncategorized | No Comments »
March 28th, 2008
This evening under much encouragement from Laura, I opened up my home brewing kit and started brewing my very first batch of beer. An Australian Lager is what we will hopefully be enjoying in four to six days. For posterity sake, I recorded a video with my new Flip video camera just in case I actually end up being a brewer some day, click the image below in order to start the movie. I hope to look back on this entry as the start of my next career and ideally my retirement. Ok so that was an awfully big dream, but we all have to have one!

First Homebrew
This beer is truly brewed for me, the next batch is yours!
Posted in Brewing | No Comments »
March 21st, 2008
As badged to the right, I am attending RailsConf 2008 at the end of May. I have already started to plan the places I want to visit, and by places I mean breweries. After going out there last year, I realized I need to be more prepared, planned, and coordinated for this year’s travels. I want to visit more of the breweries that are local and less of the obvious (though necessary - like Rogue). Here is a list of my top contenders for visitation at this point:
Let me know if you can think of any that I might have missed!
Posted in Beer Recommendations, Personal | 1 Comment »