Business of Software

Decision by Procrastination

Decisions, DecisionsToo many times I see indecisive people put off making a determination because they are too scared to make the call. However, as the Rush song goes, “If you choose not to decide, you still have made a choice”. If you put off making a decision long enough, you end up with the status quo or the decision of least resistance.

I do know someone who uses that to their advantage and allows certain decisions to be delayed, knowing that they will ultimately not get made, and that the hare-brained plan will end up never taking off.

Don’t let that be you. Don’t live your life on the path of least resistance.

There is something to be said for making sure you have enough information to judge wisely, but more often than not indecision is about fear. Consider the data, think about the options and tradeoffs, include your experience and the experience of those on your team, and “shoot the three”.

Business of Software

Programming is Not a Zero Sum Game

Zero Sum GameSimply put, a Zero Sum Game is a situation where in order for one person to win, another person has to lose. Or, in order for someone to gain something, someone has to lose that thing. Think about poker. In order for you to increase your chips, you have to win them from the other players, decreasing their earnings. At the tournament level, the game ends when one player has everything and everyone else has nothing.

It seems that a lot of people try to treat programming/technology like that. I know the counter argument to that is that I’m blind and crazy. Haven’t I seen blogs and been to conferences and user groups? People are sharing knowledge all of the time. That is true and that is great. Unfortunately, those people aren’t even close to the majority of developers. The majority are the Dark Matter Developers, and they are what is out there*. Additionally, this kind of selfish behavior I’m describing has shown itself to be human nature in all areas of the workplace.

No matter what the industry, people are often reluctant to share knowledge with others. Sometimes they are afraid that if someone else knows how to do “their thing”, that they will be easily replaced by someone else – probably someone else making less. The key is that if you can be replaced over one or two things, you have larger issues. If someone else knows how to do the thing that you are holding on to, that frees you up to learn something else and grow your skills and your worth to the organization. If nothing else, the act of teaching something to another person will build your own “instruction skill”. Being willing to always teach others also makes you more valuable to your employer because it shows that you are a team player.

Besides job insecurities, another thing that will keep developers from sharing their knowledge is that they like being the only one to know things. I’ve met several people that fit this bill and I’m ashamed to admit that 15 years ago, I fit this bill. This one is pure ego and sadly, our community is known for some very big egos. If you are holding on to knowledge because you like being the keeper of that knowledge, you need to let that go.

When you were first learning, someone had to teach you. Even if you were “self taught”, you most likely read manuals/documentation, books, blog posts, Stack Overflow, attended conferences, user groups, etc. Most people did not gain their entire technology education by hacking around and figuring out 100% of things for themselves and never learning from anyone. I would wager money that if such a person existed, their code would be full of bugs, security holes, and performance issues because they’ve never learned what hundreds of thousands of “thought hours” have worked through.

If you learned from someone, teach someone else. Pay it forward. Pass it on. Give back. Mentor someone. Whatever you need to hear to get you motivated, hear it and act. Helping others ultimately helps you. If you’ll allow me one last cliche, “a rising tide lifts all boats”.

* Incidentally, I realize that this post may very well be preaching to the choir, since these Dark Matter Developers would probably not be reading this. My hope is that this post can be instructive, or at least serve as a reminder as you are out in the world to help recognize your own bias as well as the biases of those around you.

Business of Software

That’s Why They Hired You

Frustration!I think that we’ve all been to the place of being frustrated at work. There are lots of sources of frustration, but today I want to talk about a specific kind of situation.

If you’ve ever been a consultant – either for yourself or others – you may have gotten the chance to work on a large project rather than a staff augmentation role. There are basically two reasons that a company would hire a consulting company to tackle a project for them. Either their plate is too full to perform the strategic work or they do not have the proficiencies in their staff to tackle the project. Honestly, most interesting projects fall into that latter category. And *that* is what I want to talk about today.

To win the project, you probably responded to an RFP and you had to demonstrate your experience and proficiencies with the technologies at hand. You may have had to be interviewed and show prior work, proving that you didn’t just Google the thing on the way over. Basically, you are the closest thing to an expert in this area that the company has contact with. Since you are the chosen one, you should be able to just come in there and do your thing, right? Surely, they won’t have any opinions on technologies that they are entirely unfamiliar with?

Of course not and of course they do.

I’ve been on a few projects where the consulting company was brining entirely new expertise into an organization. That never stopped that organization from asking questions… and they should ask questions. Where the frustration arises is when you make a thoughtful and careful decision, write a recommendation showing why you went that way and you still have to defend it. Not against solid questions that you forgot or didn’t think to address in your recommendation, but questions that come about because someone with a lofty title Googled “{insert technology} sucks” and just read you objections to the technology.

Those discussions can be fun, but not when the antagonist can never take the discussion beyond the surface because that’s all of the research that they put into the topic. Here is an absurd (made up) example of what I mean:

Sample Conversation:

Them: “Why don’t you use MongoDB, I heard it was Web Scale?”
Me: “The requirements call for this application to be used by your accounting department, which consists of 8 people.”
Them: “But, what if we want to put this in the Cloud to make it Web Scale?”
Me: “None of your systems that this needs to talk to are Internet-facing and you have a corporate restriction against having point-to-point VPN connections with machines that you don’t control or machines that aren’t in CISP certified data centers.”
Them: “Fine, why can’t we run MongoDB locally.”
Me: “You could, but your entire organization runs on Oracle. Why wouldn’t we just put the 3 tables we need into your existing database, saving costs, implementation time, etc etc?”
Them: “I don’t understand why kind of consultant you are if you are if you are afraid of modern technology.”

And… scene.

Fortunately, I haven’t had exactly that conversation, but I’ve had some conversations that make about that much sense and have been accused of worse. It is very easy to get frustrated at that point. But, I’ve found that it is best to take a step back when this happens. Why are you expecting them to ask you questions like they are an expert when they brought you in to be an expert? They are asking questions about an unknown thing because they are curious, or because their butt is on the line if you mess up, or just because they want to do “due diligence”.

Remember, if they already knew all of the answers, they wouldn’t have needed you. They would have set their own direction and if they were understaffed, they would have just gotten some warm bodies to meet demand. Instead, they hired you for your expertise, so try to remember that during your discussions and explanations.

Bonus tip: For the love of all things, don’t be condescending in your discussions. You might say, “Of course”, but I can promise you that it happens and many times it was not your intention. Guard your words and your attitudes and you’ll be appreciated.

Classic POS

Dumb Things I’ve Done in the Name of Crypto (part 2)

Collision, originally from carinsurancecomparison.comLast time, I showed you guys a method of encoding and decoding values that I created and used to send “secret” messages back and forth. It was stupid and naive, but didn’t hurt anyone because it was only used privately. However, I did step it up a notch the next time and it turns out that I knew just enough to be dangerous.

In a production system (albeit an internal one), we had to do our own authentication. I was “smart” enough to know not to store passwords in plain text in the DB. I also knew that storing them with my weak system wouldn’t be good enough. Somewhere I had come across the idea that you store the passwords as the result of some one way mechanism and then when you want to authenticate, you perform your mechanism on the input and compare the results.

That was all well and good.

What I didn’t know was that this was basically what hashing was. What I also didn’t know was that I had several built-in ways to hash values. So, what I did was modify my original encoding code to make it so that I could no longer reverse the process to get the original values. I figured that I could just do some multiplication or division and ditch the remainder, which would ensure that I could never actually recreate the original value.

I don’t remember exactly what I did, but this code below follows the same general idea and is just as dumb.

The results of the horrible 'hash' function

In this case, the values Abcdef1 and Abcdef2 both “hash” out to 6199818961914390671, which is called a “collision” and which is BAD. When done this way, it means that someone with a password of Abcdef1 could also use Abcdef2 to get into their account. Any number of valid passwords greater than 1 is a FAIL!

I realize that there are collisions in MD5 and SHA1, but even those would have been more secure than my nonsense. However, at this time, I had SHA256 available to me and could have been reasonably safe (given the limits of computing power at that given time). The worst part is that my “solution” was audited. We explained that we were one-way hashing and that was good enough. The auditors didn’t know enough to realize that errors could be there.

The moral of the story is that you should NEVER try to write your own cryptography or cryptographic hashes. You probably aren’t smart enough. Even the people who are smart enough publish their work and their very very smart peers try like crazy to break their work. I mean, if Bruce Schneier wouldn’t even use his own algorithms without strenuous peer review, then you shouldn’t either.

Be smart and learn from my mistakes. Use safe, tested, tried and true solutions and never ever roll your own crypto.

Classic POS

Dumb Things I’ve Done in the Name of Crypto (part 1)

Let’s just begin with the obvious. I’m an idiot. Fortunately, (I believe) that I’m less of an idiot now than I was over a decade ago. I mean, I see why this stuff is dumb, so that has to count for something, right? I sleep better at night believing that that is the case.

I’ve always been fascinated by security and encoded/encrypted messages ever since I was little, even before I was interested in programming computers. I used to play the game Hacker on my Commodore 64 and pretend that was me doing things for real. I used to pretend that I was a spy who could get into anything. I used to make up “unbreakable” secret codes so that my friends and I could pass “secret messages” at drops around the neighborhood and school. You get the point.

Well, as soon as I learned anything about programming when I was older, one of the first things I did was “invent” a way to encode messages back and forth. I decided to take a page out of the old A=1, B=2 code book and use the ASCII values for characters. The problem was that if they were left as a string of 2 and 3 digit numbers, it would soon become obvious what they were. I decided that I would just mash them all together and make one long string of numbers to kind of disguise what they were (yay, security through obscurity!).

My first issue was that while A is 65 and Z is 90, a is 97 and z is 122. I can’t easily figure out from a long string of numbers how they should be chunked. I needed them to always be available in a predictable chunk. I figured out that if I multiplied the ASCII value by 4, every character that I cared about would become a 3 digit number. Finally, I had my chunking.

I created a VB6 program that had two textboxes and two associated buttons that encoded and decoded messages for you. I don’t have the source code for that program handy (I’m sure it is on a backup somewhere), but it was easy enough to recreate the important methods here below:

The results of running that program are here:

The results of my encoding/decoding program.

You see that it basically works as advertised. I used it over IM with my brother-in-law a few times to prove the concept and was pretty happy with myself for the results.

Any of you who have your thinking caps on are already starting to see several problems here. If someone got ahold of the program, they could try some things to see if there is a predictable pattern and there is. For instance, A always shows up as 260. Once you know that, you can easily figure out any message with a simple decoder key. You don’t even need a computer at any point. Even if you don’t know that, the encoded messages are still vulnerable (for that reason) to frequency analysis and every other basic code breaking trick.

Pretty harmless exercise as it stands now, but next time I’ll cover how I parlayed this into something that was actually colossally stupid.

Part 2 is located here