Comparison of two open source and two paid continuous integration servers:
Comparison of two open source and two paid continuous integration servers:
August 11, 2009 at 06:41 PM in Continuous Integration, Java, Software, Usability, Web/Tech | Permalink | Comments (4) | TrackBack (0)
"We spend between 15% - 30% of our time
dealing with customer or support issues, so we have no concept of uninterrupted
development time."
I was told this in a recent email plea from a former developer-colleague-turned manager. He wanted suggestions on how to role out Scrum in a such a scenario. My answer, below.
...
Sacrifice a developer to hire two or three Support folks. You'll be far better off.
This assumes, of course, that you actually have a developer to sacrifice.
For a typical development project, you only really need three to six developers, anyway. Sure, you'll slow down your rate a bit but you'll be able to do things with Scrum and you'll be way more efficient in the long run. It's best to let folks be focus on what they do best.
This was one of the biggest challenges I faced in a recent consulting engagement. The customer simply did not understand the mutually exclusive nature of Application Creation and Application Support. In mingling these, creation always got sacrificed. Other than not getting things built, it's really bad for all-round morale.
With Application Creation, tasks are long-running (three to six weeks) and require extended periods of coordinated concentration. This is what is needed to create a working application. In a free economy, the salaries of those that are capable of doing this prove that it's no easy thing.
With Application Support, tasks need emergency response. Turn around time is of essence. Otherwise, things in Application Support Land may be slow - even a bit boring. But that's the price of high availability.
Application Support folks are like firemen or infantrymen.
When issues come in things get hot in a hurry. And they'd better be
ready. In the end, the customer must be given a fast, satisfactory
answer, above all else.
Why not merge Application Creation into the 'slow' times of Application Support, you ask? Good question.
First off, there's the immediate problem of context switching. A considerable amount of ramp up time is needed for a developer to reach optimal 'flow', where: their Application Creation tools have the right windows open, the right file in the code base is in view, and the control-flow for a particular area of the code base is in mind.
By 'area of the code base,' I mean variable names, APIs they're using, the chapter in a technical book that has examples of the kind of problem they're solving and more. They must remember application framework conventions, team coding conventions, check-in procedures, etc, etc.
I could go on. In general, the more things a developer can bring into their working context, the more productive they'll be. For development, there are a seemingly infinite number of things that need to be loaded into short term memory.
Only when all these details are recalled and then fade into their collective contextual background can the developer create new features at maximal efficiency. When this happens, time begins to fade away. A new feature emerges. Then another. This is flow.
Flow is invaluable to a developer and the best ones know how to block things out to get it established. Except...
But, then, their phone rings. It's their manager. Perhaps, an application support call. Or, even worse - a manager needing support.
It's as if someone pulled the lever on the developer's flow grid. Click. Baooouump. Show over.
And we shouldn't forget that ramping-up to an Application Support context has it's own set of challenges!
Bottom line: throwing the context-switch is enormously expensive. If I haven't explained it well enough, Jeff Atwood of Coding Horror does a great job in his post, The Multi-Tasking Myth.
Mixing Application Creation and Support is also a tragically inefficient waste of talent. The Two-Bridges metaphor illustrates this...
Imagine a bridge project. Like a software application, each bridge is a little bit different due to geographic and demographic variability. Also like a software application, in the course of a bridge's life it will be designed, built, tested, operated, and fixed.
Now, suppose a civil engineer has successfully built Bridge A and
is now in the middle of building Bridge B. Note that Bridge A has an
automated lane flow-control mechanism for shifting traffic during rush hour.
Who repairs Bridge A's automated lane-control mechanism that has suddenly failed at 4:30 PM due to a power surge?
Right answer: A repair tech.
Wrong answer: The civil engineer who is currently building Bridge B.
If no one else is available, could you pull the civil engineer off the Bridge B construction project for a few hours to fix Bridge A lane changer? Probably. He's a smart guy. Heck, he *builds* bridges!
He wouldn't be the best to make the fix. He'd need some help from people in other areas of bridge maintenance and may need to scramble to find the right tools. The repair might not be timely and traffic would still back up. But one way or another, he'd probably be able to get it done.
Now, imagine that this engineer gets similar, 'urgent fix needed' calls several times a week during Bridge B construction.
The problems with this should be obvious. Bridge B may never get built. If it did, it would be impossibly delayed. This is a staggeringly wasteful and demoralizing use of the civil engineer's time.
The civil engineer is the only one who can make key decisions during Bridge B construction. He's the only one who can interpret engineering drawings and make on-the-fly calculations for life-and-death structural concerns. With his frequent absence, Bridge B construction would either grind to a halt or get built with inadequate supervision, thus posing a deathly risk for untold numbers of future bridge goers.
The real result of management policy that uses Application Creation talent to do Application Support is that the Creation talent leaves. For the organization, it means the end of their ability to build significant, reliable applications.
In the software industry, for a developer to lose their proficiency due to lack of practice quickly makes them obsolete and non competitive. This is a risk few, if any, good developers should ever be expected to take.
July 08, 2009 at 10:33 PM in Software | Permalink | Comments (0) | TrackBack (0)
To continue from an earlier post on the WACD methodology, here are some tips for keeping the pesky 'team' concept from eroding your development sovereignty.
First off, developing applications in teams runs the risk of contaminating your line of thinking with inferior logic. The fewer people on your team (ideally, just you), the more freedom you'll have to solve problems the right way.
Sure, developing in isolation may lead to duplication of efforts in your IT organization but that's OK - IT organizations are full of redundant waist and it's not your job to fix it. Besides your solution will undoubtedly be superior to your look-a-likes. Everyone will benefit by learning from your example.
Development teams like to second guess each other by doing code reviews. This is just a crutch for weak developers with no guts. Be smart and write the code perfectly to begin with. As you already know, writing near-perfect code eliminates the supposed benefit of second-guessing weasels.
In the rare case where factors beyond your control caused you to write a bug, you'll be the only one who'll understand it. Not only is this is great for your job security but it ensures a peaceful debugging process where you're not constantly being asked questions that begin with "Why did you... blah, blah, blah." So friggin annoying.
Last but not least, teams often talk of 'camaraderie' and 'morale.' My advice here is simple: Camaraderie is for commies, morale for pussies. Don't be either. Clint Eastwood didn't ride into town with a Cowboy Support Group and neither should you.
June 10, 2009 at 09:06 PM in Philosophy, Software | Permalink | Comments (0) | TrackBack (0)
C:\some\long\windows\path\to\files\you\cannot\deleteto a new path like this:
C:\a\a\a\a\a\a\a\a\a
May 27, 2009 at 07:02 PM in Software | Permalink | Comments (0) | TrackBack (0)
March 06, 2009 at 02:43 PM in Software, Usability, Web/Tech | Permalink | Comments (1) | TrackBack (0)
It's back. At least, for now.
March 04, 2009 at 09:57 AM in Web/Tech | Permalink | Comments (0) | TrackBack (0)
March 04, 2009 at 08:38 AM in Web/Tech | Permalink | Comments (0) | TrackBack (0)
We cannot spend our way to good economic health, even in the short run. We have to produce.
John Stiglitz, Chief Economist of the World Bank from 1997 - 2002 took callers on CSPAN this morning, one of which was a democrat who suggested (paraphrasing), "With the economic downturn and the tax payers being the problem, with the bad mortgages and such, why not just give every American one million dollars? Then people would spend money, helping businesses, and letting people keep their houses and jobs."
Why stop at one million?? Why not 10? How about 100 million? We'd all be set for life.
I'm all for consumption as a important part of market health. However, the problem with consumption based on money given versus money earned is that, when given, you have no skin in the game. No risk taken. This changes everything. If you lose it all because of a bad decision, oh well.
With money earned, you have a vested interest in not seeing it disappear. With money earned, you do your best to get the maximum value you can for every penny. This kind of incentive works. Money-given based consumption eventually reduces productivity to point of total dependency. This is socialism and, as history shows, has a strong track record for destroying markets.
October 14, 2008 at 09:44 AM in Current Affairs, Economics, Philosophy, Stuff | Permalink | Comments (2) | TrackBack (0)
SproutCore is slick; has a RoR + Apple pedigree & leverages Javascript very nicely. MobileMe integrates it. Apple contributes heavily to the project. Silverlight, AIR, and Google Gears compete. Silverlight and GG require browser plug-ins. Only GGs is open-source. Here's a good overview: http://rapidappsgroup.com/content/desktop-web-applications-using-sproutcore/
August 23, 2008 at 05:35 PM in Rails, Software, Usability, Web/Tech | Permalink | Comments (1) | TrackBack (0)
Considering Groovy for your next big project? We did. All things considered, it figured to be a safe choice given its Java pedigree. From the limited exposure I'd had to Groovy up until that point, it looked and felt remarkably familiar to Ruby (a good thing). I had even heard you could cut & paste any amount of Java into a .groovy file and it would just work. Depending on what 'work' actually means, this is mostly true.
One of the small untruths about Groovy behaving 'just like Java' is worth serious consideration - especially if you want your .groovy code to become API-ready.
July 31, 2008 at 11:58 PM in Groovy, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)
I got lazy and didn't blog about DHH's key note last night. So, before I get on with Kent's salient story-style wisdom, I'll quickly catch up with DHH's.
Continue reading "RailsConf 2008 Saturday Night Key Note: Kent Beck" »
May 31, 2008 at 09:47 PM in Current Affairs, RailsConf2008, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)
Continue reading "Summary: Dialogue Concerning the Two Chief Modeling Systems" »
May 30, 2008 at 06:08 PM in Current Affairs, RailsConf2008, Ruby, Software, Web/Tech | Permalink
|
Comments (0)
|
TrackBack (0)
May 30, 2008 at 03:48 PM in Current Affairs, RailsConf2008, Ruby, Software, Usability, Web/Tech | Permalink | Comments (0) | TrackBack (0)
I'm at RailsConf.
Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM. Everything about the burger was above average. And it came with hot, crispy, slightly salty fries. It was all devoured with sips of a local wheat bear that I forget the name of.
So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place. New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc. Good stuff.
I'll pretend I blog and let you know how it all goes.
May 29, 2008 at 07:17 PM in Current Affairs, Rails, RailsConf2008, Ruby, Software, Usability, Web/Tech | Permalink | Comments (0) | TrackBack (0)
Sketching User Experiences: Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences. Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject. He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.
Continue reading "Book Review: Sketching User Experiences by Bill Buxton" »
May 07, 2008 at 10:42 AM in Books, Software, Usability, Web/Tech | Permalink | Comments (0) | TrackBack (0)
In SOA and Agile: Friends or Foes?, Amr Elssamadisy opens a discussion on the perceived disconnect between what should be the mutual admiration societies of SOA and Agile developers. Most of the comments to Amr's article are also informative and and well-written. However, in the discussion, not mentioned are the non-technical forces in play which, hopefully, this response can illuminate.
April 24, 2007 at 05:55 PM in Software | Permalink | Comments (0) | TrackBack (0)
Like my development environments, things change. Since my next project is to extend a product written in Java and, since I used to develop Eclipse rich clients in my webMethods days, I figured I'd install Eclipse on my MacBook Pro.
We use SVN so, I also installed the most excellent Subclipse Eclipse plug-in. All was going well until, I tried to synchronize to the repository. When I did, I got the following error:
Continue reading "Subclipse Installation Problem on Mac OS X" »
March 06, 2007 at 01:53 PM in Eclipse | Permalink | Comments (13) | TrackBack (0)
Ever had a long string like this: "myveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongstring" and wanted to turn it into something much shorter, such as this: "myveryvery...longstring"?
Here's a little snippet that does just this. It works great in HTML select lists which, to my knowledge, are impossible to dynamically resize as the user drags their browser window larger or smaller.
Continue reading "Ruby Snippet: Shortening Long Strings For Display" »
December 28, 2006 at 08:16 PM in Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)
If you're new or semi-new to TextMate and you're collaborating with someone on the same development project, file change collisions are inevitable. Textmate has nice support for resolving file conflicts when they show up after updating to the latest SVN depot revision.
Note: This post assumes you are on a Mac :^).
Continue reading "Resolving Files with TextMate, Subversion, and FileMerge" »
December 14, 2006 at 01:15 PM in Ruby, Software | Permalink | Comments (2) | TrackBack (0)
As a former Java developer and new to the concept of blocks, these API options seem perplexing at first. They're not. All three take a block. How they use the block is what distinguishes them. You should read the RDoc for yourself but, if you want a quick a dirty summary, continue reading this post.
Continue reading "Ruby Arrays: select(), collect(), and map()" »
December 06, 2006 at 11:48 AM in Ruby | Permalink | Comments (4) | TrackBack (0)
Recent Comments