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

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

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

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.

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.

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.

There 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.

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.

Jaimie sent me this link the other day, Don’t Repeat Yourself, saying something about hearing my voice as he read it. I have to say I like it. I live and die by it when it comes to software architecture and database design. I don’t make decisions to duplicate data lightly and will exhaust every available alternative first. To a fault some may argue.

Why? Simple, it’s painful and expensive to duplicate data.

Duplicating data is typically pretty innocuous stuff in the moment and I find it often isn’t even viewed as duplication. Say you’re youtube. Sorry, say you’re google, and you keep a table of data containing a row for every video viewing. It contains some simple data, let’s say video id, date of viewing, user id who viewed, etc. If you need to calculate how many times a particular video’s been viewed then you can perform some type of simple select:

select count(*) from VideoViewHistory where ixVideo = ‘1’

A very common form of data duplication would be to have this table as well as having a column in the Video table called NumberOfViewings. Each time the video’s viewed, we insert a row into VideoViewHistory as well as incrementing the number in Video.NumberOfViewings.

This approach is very common, bordering on a standard. It’s considered an ‘optimization’ as you’re saving a trip to the database and what could be a relatively large select statement being run very often.

I agree that it also may be the best design and it makes good sense in a lot of cases, however, what is often ignored during the design process is that this is an expensive and less maintainable approach. Trust me, any form of duplication increases your chances to introduce bugs and makes the code base more expensive to maintain.

All of this must be factored into any decision to duplicate data which is what this approach is doing. You have to write more code to ensure the multiple data sources are in sync. Guaranteed you will at some point have to deal with edge cases when the two sources of data get out of sync.

Developers often winch that the biz guys don’t understand technology. Well geek boys, it works the other way too. If you’re the one paying the bill to maintain this code base five years from now, do you care more about some extra database trips or the brittleness of your code base? Brittleness translates directly into dollars spent. There’s far more to designing good software than database trips and performance…..I think……

I was explaining jajah to my wife the other night. I explained how anyone can go there, enter their phone number, enter the number they want to call. Then your phone will ring, you pick up and it phones the number you want to call and you’re done. Free phone calls, well mostly free phone calls.

She looked at me skeptically saying “well then why doesn’t everyone use it?”

I didn’t have a decent answer to that. Now that earl’s on the scene, I’m using jajah through bbcalls and it works fairly well. It’s integrated with the address book allowing me to simply choose a contact and select ‘jajah call’ and go.

Wow, interesting that I wrote a post today with the words digital tether in it and just now I received an email about the impending domain expiration for the domain digitaltether.com which I apparently own.

Ok, that’s actually not interesting at all as I read it over. Anyway, I never came up with anything interesting to do with that domain.