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

Business of Software

Time to Leave Your Job?

The Future Awaits - from http://us.123rf.com/400wm/400/400/rjmiz/rjmiz0804/rjmiz080400085/2836581-business-slogans-on-a-road-sign-exit.jpg
An article was posted over at Mashable titled 8 Signs It’s Time to Leave Your Job. I can see their perpective on all of their points, but to me their 8th point was the main point.

You are no longer passionate about your work and dread going to the office each day.

That is my number one criteria for looking for new employment. Do I dread going into work? Am I excited about the kinds of things that I get to do at my job? Not every day is a mountaintop, but if you have a prolonged period of dreading work, then you should consider moving on. All of the other points roll into that one. They talk about politics and high profile work, etc. Different strokes for different folks and some people aren’t affected by the same things that affect others. It all comes down to whether or not you die a little inside when the alarm goes off in the morning.

Assuming that you’re getting paid basically what you can make elsewhere (give or take a few percent) and that your benefits are fine, the only other consideration in my mind is whether or not your skills are being allowed to grow, or whether they are stagnating.

For example, if you are a .Net developer and your workplace is still working on the .Net Framework 2.0 and you are only using Web Forms and you are on SQL Server 2000 with no chance of an upgrade, you should think about going even if you are happy. Your alternative is to get very involved in “new technologies” in your spare time so that you don’t become easily expendable.

The days of working somewhere for 40 years and retiring with a gold watch and a pension are basically extinct. If you allow a job to manage your career for you, you will find a time where it is 2013 and you are looking for work and you have been doing FoxPro 6 or Classic ASP for 15 years and now you can’t find a job that will pay you anywhere near what you need to support yourself and possibly a family.

So it is all summed up very simply as to whether or not you like going to work every day. If you love the place and it is feeding your career, then you already know that you shouldn’t be looking anywhere else.

If you love the place and it is strangling your career, consider whether or not you have the time or inclination to put in the work “off hours” in a very big way to gain the requisite experience in “new technologies” that you may or may not use professionally. If you don’t have that time or inclination, look to move on, even if you love your job.

If you don’t love waking up in the morning to go to work, get out. Life is too short for almost anything else to matter.

Rant

How Deep is the Rabbit Hole

Programming is Hard, Let's go Shopping. From http://memegenerator.net/instance/30286782Rob Conery tweeted about a blog post that “Kakubei” made back in May of 2012. You can read about it over here.

I find it interesting that the author starts off the post making a comparison between himself and his brother. That his brother’s academic success and his own academic failings (and subsequent self-taught programming skills) are at odds and that the industry would view one of them as a “real programmer” and the other one as not a “real programmer”.

As I often like to point out, every programmer is a self taught programmer. You may get the fundamentals at college and learn some things that can make you more efficient or a better designer of computer systems, but with the pace that technology is changing, you have to constantly learn to keep up.

That being said, Kakubei’s main complaint is that Rails is hard to learn. He compares the canonical “15 minute blog” demos to what it takes to do “real world” Rails development and he comes up with a big differential.

What I find funny is that he seems to have come from a PHP background. That means that he had to know the PHP language, possibly a PHP framework (like Cake), HTML, CSS, JS, probably MySql, etc. I say that to say this, he had to know a lot to work and he wasn’t coming to Rails from zero.

The author complains that to use Rails, you have to know Ruby and that you have to know MVC, Gems, RVM, Active Record, HomeBrew, HTML, CSS, JavaScript/jQuery, Rake, Capistrano, etc. My point is that he probably already knows HTML, JS, and CSS. If he owns a Mac, he has probably already encountered HomeBrew (it isn’t just for developers). If not, this was a fine time to learn.

I think this all boils down to something else, though. What does it take to be productive or at least “mildly useful” in a language/framework?

To me, I was able to follow a simple Rails tutorial and starting using Rails almost immediately. Know what I didn’t need? RVM. Just starting out, I just used one version of Ruby and Rails. As for Gems, in order to do my tutorial, I had to say “gem install rails”, so I already had an idea how it worked. After that, you can pretty much avoid using it if you don’t mind rewriting code that is already a “solved problem”.

What about HomeBrew? Don’t need it. Active Record? All you need to know to actually make stuff happen is in the “15 minute” video. Same with the MVC pattern. I didn’t know anything about making MVC websites and I was up and moving with minimal instruction from the video. Rake? Didn’t need anything special there, either, because I hadn’t created a very complicated system yet. Capistrano? I need an automated deployment on day one?

My point is that every rabbit hole is very deep. .Net? WebForms or ASP.Net MVC? HTML, CSS, JS/jQuery. Dependency Injection with AutoFac/AutoMapper/Ninject. ORMs like Entity Framework, NHibernate, etc. Don’t forget the language (C# or VB.Net or F# or whatever). How about Nuget for package management? Don’t forget source control, like TFS or Git. What about knowing testing like NUnit, xUnit, MSTest? Deploying with MSBuild and MSDeploy or one of the bajillion open source tools?

I could follow the same path to describe getting started in web development with Node.js or Python or whatever you could think of. It is silly to think that you can go from 0 to Amazing in 15 short minutes. That pattern doesn’t work.

What you have to know is how to learn. You have to know how to Just-In-Time the information so that you can be productive from the jump off. Yes, that means that you’ll always be learning, but if that concept doesn’t excite you, then you are probably in the wrong field.

I believe that that sort of complaining (“The development stack is too deep/rich”) shows a certain level of professional immaturity.

I realize that after Rob tweeted, Kakubei added an update after people started commenting, saying:

“I’ve been using Rails for more than a year and I still use it. In fact, I’m in the process or rewriting our main application’s API in Padrino with ActiveRecord, Thinking Sphinx and deploying to Heroku and it has been a primarily positive experience despite some teething issues. The admin for our database I’ve written in Rails 3.2 and there is a lot to like there. The idea was to write another post after this one titled “Why I love Rails” but I never got around to it. Even though this post is a rant, I still feel that way about Rails, so keep those comments coming, but don’t feel you have to convince me that Rails is good, I just take umbrage with some of its complexities and with the people who sell it as being simple and easy to learn. In the meantime, I’ll keep ranting.”

I understand his response and understand that he was probably frustrated when he wrote the post and he is not really apologizing for it. That leaves me to still consider my criticism valid that I believe that he faced the problem all wrong (or at least described a method that did just that).

To me, you learn the basics of the thing. You see what skills you have that you can already reuse (HTML, CSS, JS, SQL, whatever). Then, you pick up what you need, working with the “training wheels” that the frameworks or languages give you. Then, steadily over time you start to grow and move deeper in the tooling until one day you are someone that others look to for advice.

That’s the only way we’re going to make it in this crazy development world.