The Creepy Floating Head

Xml Commander Beta Begins

2010-06-29T12:19:00.001-06:00

This is a project I've been working on in my spare time for a few months now.

If you've ever used XML Notepad to edit XML files, you may have found it a bit lacking. So I decided to roll my own XML editor with the same hierarchical editing format, but with an often asked for feature thrown in: namely tabbed editing.

This software is far from complete, so it might not technically qualify as a beta. Let's call it "very beta". You can download a 30-day trial from here.

Complete Denial of the Chicken and the Egg

2010-04-19T08:31:00.000-06:00

Google's new Chrome OS has a slight drawback:

http://techland.com/2010/04/16/googles-os-predicament-how-do-you-print-from-the-cloud/

You'd think that a company that's come as far as Google would have a better strategy than this. And that they wouldn't have their heads in the clouds with all this wishful thinking.

Companies will only build cloud-enabled printers if they feel it's worth it. This is why drivers exist, to create a layer of abstraction that permits any piece of software to use your hardware.

But Chrome stands in the way of that model. They want this cloud thing to work and they want you to beleive it too.

Essentially, you'd have a printer that requires very little setup aside from taking it out of the box and plugging it in. There'd be no software to install anywhere but you'd need to connect it to your network to get it online and then establish a link to it using your Google account.

You mean, I have to sign my printer up with Google? Using that tiny calculator-like screen a printer generally comes with? You want me to SURF THE WEB on that? So I can register it with google?

Great Ideas

2010-01-28T12:32:00.000-07:00

If you think you've got the next great idea, theres a question you need to ask yourself.

If my idea is so great, why has nobody executed that idea before?

Right answers might include:

- Because they wrongly came to the conclusion that its unfeasible, and I found a way to make it so.

- Because they couldn't deduce who they would market it to, and I have.

- Because it solves a problem nobody thought they had. I now see that they DO have that problem, and the customers will see that too.

Wrong answers include:

- Who cares why they didn't think of it, it's GOLD!

When you reduce someone else's headaches...

2010-01-13T09:35:00.000-07:00

...you win. Because they win, and now they have a vested interest in helping you win.

Closed Mindedness

2009-12-10T09:53:00.002-07:00

For my next project at work, we're switching from native C++ to C# (Mono). The only reason this is able to happen is because the companies most staunch detractor for C# has left the company. He's quoted as saying that he'd rather die than program in C#.

Which I think is a bit over-religious. Did he even stop to consider the advantages (or disadvantages) of one language over another? No. He simply had decided that C++ was the way to go. And that's that.

Maybe C# isn't the right language for your project. But I think whenever you say "I'll never write so much as a single line of code in that language for any project ever" whether that's C#, Java, C++, Assembly, Visual Basic, Python, Javascript, Perl, Ruby, or friggin bytecode, whenever you say that, you're proving that you are completely unwilling to evaluate the costs and benefits of one language over another.

Most People are Honest...

2009-12-09T12:17:00.001-07:00

...but the liars are louder.

Singletons

2009-12-08T14:53:00.000-07:00

It's a pretty universal observations that Singletons suck. But few give any rationale as to what it is about them that sucks.

To me the best argument is: They may save you time today, but they'll take all that back and more tomorrow in the form of inflexibility.

Think Trench Warfare

2009-12-07T09:02:00.006-07:00

Let's say you've got 6 soldiers in a trench, 5 privates and a sargeant. In 5 minutes, these men plus other units elsewhere must go over the trench and push into enemy territory.

Let's imagine now that way back at HQ, there's a general. And this general is worried about the push because he has gotten the idea in his head that the men are not cleaning their weapons well enough.

So what does he do? He individually radios each of the 5 privates and orders each one to clean his gun. Those guns must be ready for the push!

The sargeant sees one of his men cleaning his weapon frantically and says "What are you doing? You just cleaned that 20 minutes ago!" And the private would have to respond "I'm sorry sir, I was ordered to do this by the general."

What can the sargeant do? He can't override an order by a higher ranking officer, so he allows his men to finish.

After cleaning and reloading their weapons, the unit is over a minute late for the push, and the entire effort falls apart.

What went wrong here?

If the general had called up the sargeant, the sargeant would have explained that the men were ready and able to carry out the mission. Instead, the general has overridden the sargeant's authority to keep his men combat-ready. The only order the general should have needed to give was "go."

The lesson?

As a leader, you need to either be in the trenches, issuing low-level orders and observing the situation, or back at HQ, giving high-level orders that set policy, and delegating that low-level responsibility to your sargeants.

You can't have just one foot in the trenches.

The next time someone says I told you so...

2009-12-03T07:48:00.001-07:00

...maybe you should respond with "yes, I should have listened to you."

Regular Expressions are Just one of Those Things

2009-12-02T10:30:00.000-07:00

They're powerful. They can solve huge problems. And everybody swears by them.

So you pretend to swear by them too, because everybody else does, and you know that in the end it IS going to be the most optimized way to deal with a certain problem.

So you lie to yourself (or to others) and say that you'll be able to write a regular expression without needing to take hours out of your life to debug it. You pretend that you won't come back to it 2 months later when it starts coming across situations you didn't account for (or maybe you thought you did) and spend more hours banging your head trying to fix it.

Project Ownership

2009-12-02T07:52:00.008-07:00

I've seen alot of projects go bad for one simple reason: The person or persons in charge of that project didn't have enough authority to execute the project as requested, and are nonetheless expected to be responsible for the success or failure of that project.

I don't find this cartoon funny, I find it sad, because it's true.

Minimize the Intangibles

2009-11-27T13:19:00.001-07:00

Working with the iPhone in XCode, one of the main beefs I have against it that it feels so disconnected with the app I'm trying to create.

Take modifying a xib file for example, you open it up and you see First Responders and Delegates and Owners and you drag them around to get things done, and then maybe you have to create a few more crazy little objects that mean nothing to you but the tutorial you're reading says you really have to do it this way.

"Where is the toolbar?"

I'm sure it all makes perfect sense if you've spent more time working with this stuff than I have, but for me it's just a bunch of really abstract, intangible concepts that have nothing to do with what I want to get done.

"Just show me where the toolbar is."

I want a Window. I want to put a button on my window and when I click it, a function I specify gets called. Is that so hard?

Because of this simple concept, Visual Studio's editor can be picked up by anybody in a matter of minutes. Drop a button. Double-click it, now you're editing the code that gets called when that button is clicked.

What if editing in Visual Studio consisted of things like adding a "Primary Framework Broker" object as a child of the form and then dragging it onto the form's "User Experience Instantiation Handler"? It would be a nightmare and you'd need tons of documentation to even get started.

So the next time I write an app, I'll ask myself if the concepts I'm asking my users to deal with are tangible enough.

"Please select the appropriate EmployeeSalaryReviewLinkage object."

The Reduce-Embarassment System of Prioritization

2009-11-26T08:09:00.000-07:00

Sometimes it's hard to know what to tackle next, especially when you're doing a project yourself, or when you're the manager of a project.

I like to build things in priority order, in other words, most important thing first. Common sense, right? But how often have you stalled your project by focusing too hard on getting that tiny portion of your program juuuust right.

To avoid that trap, I try to give everything in my projects a priority value, and whenever I find myself working on something that's a lower priority than something else, I switch.

But how do I know what should take priority over what? I use the reduce-embarrasment system. Basically I ask myself "if I were to release my software today, which incomplete item is the most embarrassing not to have completed?"

When you start your project, it's at its most embarrassing stage, because there's nothing on the screen. And you reduce embarrassment from there.

Foreign Code and the Obligatory "WTF?"

2009-11-23T09:11:00.002-07:00

Whenver I look at somebody else's code I am compelled to think they're crazy at first.

"You don't need that! What were you thinking?" I scream at them, even if they're not around. Especially if they're not around.

Lately I've begun to realize that the reason other people's code looks so bad is that, you're looking at the solution to a problem you don't know about. Why did Joe Blow use a series of classes just do to the same job as an enum? Well dive a little deeper and you'll find the giant switch statement he was trying to avoid. He just wanted an enum with code in it!

But you didn't realize at first that that would be a problem, and you convince yourself that he's done all this work for naught.

It's like Jeopardy. The format of the game is backwards, they give you an answer and you tell them what question needs to be asked to bring about that answer. But you just KNOW that there's no way you would have gotten the answer if the question was asked forwards. Nobody could.

Just like you can't see all the problems that somebody else ran into just by looking at the solution.

Don't Fear the Truth

2009-11-20T07:48:00.002-07:00

Those who fear the truth will have, at best, mediocre success

Have you ever worked at a company that mandated you to not to talk to other employees about your salary? If you raised your hand (and it's very likely that you did) you've been the victim of an organization that's afraid of the truth.

That organization doesn't want you to talk about your salary because then people will realize that the last person in gets the biggest pay. Why? Because while some may be content to stay in an organization at low pay, few will enter an organization at that same pay.

Shouldn't the most talented, most loyal employee get the biggest pay and the biggest chance of advancement? And to me one factor in measuring that is time spent with the company. Seniority. To do otherwise discourages loyalty, and who wants that?

These organizations come about because the person at the top is in it for himself. Numero uno. And any successful person knows you have to be in it not for 'me' but for 'us', for the team!

Many of these clueless bosses will be outraged when they find out that you're not a 'team player' when they have done nothing to help the team themselves.

They see you as a neccessary evil. They wish they could replace you with a robot and they live to maintain the status quo. They fear the truth, and they will never have anyone but themselves on their side.

Thus, mediocre success.

So the next time you're in an interview, maybe one of the questions you should have for the interviewer is, "Will I be asked not to discuss my salary with other employees?"

It's All About the Cake

2009-11-19T14:22:00.007-07:00

A cliche often spoken by non-programmers is: "why can't we build software the way we build bridges?" But I think the metaphor works better if you say: "Why can't we build software the way we bake cakes?"

The answer is, you don't bake the cake. You create a recipe. In cake building, you slap together components you already know work (eggs, flour, milk) and voila, you get a cake!

In RECIPE building however, you experiment with a hundred different variations of those ingredients. You don't bake the cake, the compiler bakes the cake for you, using components it knows already work (classes, functions, variables); but in the proportions and order that you've specified.

Therefore programming is about finding the best recipe for the type of cake you want, which means:

You have to have people around to taste your creations to see how good they are (beta testing)
Once you've found the right recipe, you can build a cake factory. (distribution)
The cakes will never be perfect, and a few of them will collapse. (crash)
And it's possible that a competitor will create a cake that's not only chocolatey like yours, but also nutty! (extra features)
So you refine your recipe to make your cakes tastier (version 2.0)
You could start from scratch, or add to an existing cake mix (third-party libraries)
But you can't take away ingredients from the existing cake mix (lock-in)
And the cake mix is meant to appeal to everyone and so is less likely to perfectly fit your needs (leaky abstractions)

Mmmmmm cake... where was I?