Archive for December, 2006

Office Christmas Party

December 22nd, 2006
[ Office Gossip ]

drunkSanta.jpgSo the one thing I certainly do miss about not working in a big office is that last week before Christmas when, let’s face it, productivity is almost non-existent. Oh, and that last day before the holiday break when productivity may actually total up to a negative value, I do miss that.

In honor of that maybe I’ll try to incorporate some of the usual trappings of the day around the house today. I’ll get on the bad santa hat, have a few naughty nogs this afternoon, corner the chooch and bore him with some disorganized non-sensical stories only to eventually pass out in my cubicle and hope an office mate can give me a lift home.

On man I miss the office.

One Percent

December 21st, 2006
[ General ]

Jamie Johnson is an incredibly rich kid. He’s heir to the Johnson & Johnson vault of cash. He’s in his mid twenties and makes movies, primarily about being rich and what it’s like in the inner circle of the obscenely rich. His current project is titled “The One Percent“.

Jamie’s a trust fund kid. He’s part of a family of people who spent a large part of their energies coming up with ways to keep the money they have. Trust funds, off shore accounts, whatever it is they do. People this rich are less concerned about earning money then about keeping the airplane hangers full of cash they already have.

Contrast the Johnson family with Warren Buffett, Warren not Jimmy, currently the second richest man on the planet. While I haven’t heard this first hand, the rumour is that Warren’s stated he will NOT leave his money to his family.

What’s the point? Both Warren and the Johnson’s are part of that infamous one percent who possess 99% of the world’s wealth. In the case of the Johnson’s, they have every intention of keeping it in the brood.

I find it fascinating that Mr Buffet is planning the exact opposite. People like Robert Reich will tell you how the former can impact a society. Societies who feel they can never access that 99% of wealth are ripe for anarchy and literally ripping themselves apart at the seams.

I think I had a point but I’d rather leave it at that…So, no point, or it’s your turn to come up with the point….Any point I find seems to make me feel like either a capitalist or a communist, neither of which I consider myself….

Kids in the Office

December 14th, 2006
[ General ]

322481060_3e326799ec_b.jpgI don’t recall being told NOT to draw on the children.

Hey, whiteboard’s aren’t cheap.

30 days of HyperStrike

December 14th, 2006
[ General ]

Cathy at HyperStrike sent me a stack of 30 day free trial promo cards. If you’re interested, contact me.

Product Development Crowdsourcing

December 11th, 2006
[ Geek ]

CrowdSpirit is aiming to take the crowdsourcing movement into electronic products.

Making the Switch

December 11th, 2006
[ Geek ]

Ok, I’ve finally made the switch. It’s amazing the strange looks I get, everyone must really think I’m a PC guy.

319574856_9604c5ee36_o.jpg

Create PDF’s

December 7th, 2006
[ Geek ]

I use this a lot. It’s a free print driver that prints to a pdf file. It’s slick because anytime I need a pdf I can hit print, no matter what application I’m in, choose the pdf driver, watch a bad ad, and I’m done. No switching applications, exporting, importing, etc.

Debugging A Software Specification

December 6th, 2006
[ Software Development ]

Oh yes, another from No Silver Bullets:

“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”

You best believe. I love this explanation. For starters it unburdens the people tasked with spec’ing the software from having to spec something that’s actually buildable. In most cases those people are UI specialists and business analysts who technically don’t know the first thing about actually building software. How could they realistically be expected to spec buildable software?

So in taking a specification and building it into actual software, we are effectively debugging that spec. Nice. Are you getting this Andrea? You’re off the hook, sorry not off the hook.

Designing Software In Photoshop

December 5th, 2006
[ Software Development ]

From No Silver Bullets:

“In the pitiful, multipage, connection-boxed form to which the flowchart has today been elaborated, it has proved to be useless as a design tool — programmers draw flowcharts after, not before, writing the programs they describe.

Second, the screens of today are too small, in pixels, to show both the scope and the resolution of any seriously detailed software diagram. The so-called “desktop metaphor” of today’s workstation is instead an “airplane-seat” metaphor. Anyone who has shuffled a lap full of papers while seated between two portly passengers will recognize the difference–one can see only a very few things at once. The true desktop provides overview of, and random access to, a score of pages. Moreover, when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. The hardware technology will have to advance quite substantially before the scope of our scopes is sufficient for the software-design task.

More fundamentally, as I have argued above, software is very difficult to visualize. Whether one diagrams control flow, variable-scope nesting, variable cross references, dataflow, hierarchical data structures, or whatever, one feels only one dimension of the intricately interlocked software elephant. If one superimposes all the diagrams generated by the many relevant views, it is difficult to extract any global overview.”

Tools like UML are nifty, and if you have no choice but to convey a software design on paper then that’s where I’d point you. Remember though, it is still an ugly hack, in my opinion. Architecturally, at BOC, we strive for a design-build methodology where the guys designing the software are the guys building it. Sure it opens yourself up to the hit-by-a-bus syndrome but experience tells us that very few of our people get hit by a bus on a regular basis so it’s an acceptable risk.

The ideal tool for describing a software design is a modern programming language, in other words write code. In The User Illusion, Tor Nørretranders explores a powerful metaphor for human consciousness. One of the examples he uses is maps. As you add more and more detail to a map you have to add more and more information. In the end the only map of the world that has enough information to convey it accurately is the world itself. Anything else is just a best guess and is missing valuable information. The same applies to software, the only thing that conveys a piece of software completely is the piece of software.

Restaurant-UML-UC.pngThere are good reasons to document the software development process like conveying a design to a team of developers who are tasked with implementing your design, or documenting what’s been built for subsequent development, etc. A reason I’ll never put on that list is that it makes for better software. Am I saying you don’t have to plan a lot on paper before hand? No. Am I suggesting you always jump to code and write first? No. I’m suggesting you only document on paper what you as a designer feel will move you towards better software.

Even in the cases where I have to document a design in order to hand it off to a team, I will typically design the system in code. I’ll write up a simple, stripped down version of the application in code and then I’ll document the application I’ve built in order to create documents to hand to the team. If you think about that it ain’t optimal.

Software Development, Best vs Average?

December 4th, 2006
[ Software Development ]

Okay, if you haven’t read the paper No Silver Bullets then you best start there before someone yells at you.

One point made in that paper talks about the gap between average software development and the best:

“The gap between the best software engineering and the average practice is very wide, perhaps wider than in any other engineering practice.”

Based on my personal experience, I tend to agree with Mr Brooks. Not only that, it is just that very gap that allows me to dream of what’s possible with boc.

At one level we continually strive to be at the ‘best’ end of that gap and be able to leverage the fact that there aren’t a lot of us over here. On another level, we also hope to be able to share that by growing more people at that end. By grow, I mean people. School’s try but few, if any, will get you to the right end of this gap. Working with us at boc will get you there. We’re new at this part and it’s something we’re only scratching the surface on, however, it’s the part that gets most of us excited.

We already know how to grow the best software, now we’re learning how to grow the best software people.