What makes Engineers Grumpy?

Nicholas Zakas has the answer. What I like most about this is that he's clearly dientified the source and the solutions to the grumpy issue. While problems aren't always so simple, and organizations can have more systemic issues, a  triest like this definitely shows the perspective from the creative part of a development endeavour

http://www.nczonline.net/blog/2012/06/12/the-care-and-feeding-of-software-engineers-or-why-engineers-are-grumpy/

What he also presents is a note about how building software is like building a house. This might be worth making more visual.

Adventures in DUKPT-istan

Wouldn't it be awesome if we could limit the exposure of sensitive information (ok, small amounts of it) while it travels over the internet and through devices?

Wonder no further, DUKPT to the rescue. Derviced Unique Key per Transaction is a method to generate a key for each time a device is used. These all have the ability to be decrypted with a master key given only the addition of what amounts to a sequence identifier. These typically show up in swipers, and I suspect that most commercial swiper products use this when needing to exchange keys.

The trick is that a unique transaction key is derived from a base key using only non-secret data. The non-secret data can then be transmitted along with what you've encoded (for instance the CC) and the master can decode.

Making better use of this blog thingy

OK, here's the problem. I have random thoughts.

The problem really is that I don't record them. So whether it's for work or a cool technology or just an interesting thought or website.

So let's kick it off.

SSH Port Forwarding

Every now and then I want to access my home computer, so I happily use SSH port forwarding.


There are tons of resources out there, but here's my simple guide.

1. set up ssh tunnel (this one does both a socks proxy on 8088 and tunnels localhost VNC)
1. ssh -D 8088 -L 5900:localhost:5900 username@machinename.com
2. if you don't want a shell throw -N in there, although I don't really get the point for the most part.
2. set up foxy proxy for firefox
1. make a new proxy localhost:8088
2. make sure it's set to "SOCKS" which is a bizarrely unchecked check box even when you nominate socks5
3. use proxy for all traffic (obviously you can be a lot more sophisticated than this)

That's it!

Chapter 2: KICFJS (Keep it Complex For Job Security)

Note from author: Yes, this is a new blog, these posts are from a 'paper' I wrote along with a friend on Cynical development. It was a tongue in cheek attempt at explaining what we see in the real world in our various development experiences. These posts might seem rambling, but basically that's because I cut and past them from a different format.

Having reviewed dozens of code bases for dozens of applications it's amazing how some things can only ever be understood by the original author. This can only be explained by the simple (and easy to pronounce) acronym KICFJS. Put in another way, if your code base is simple enough that anyone can come in, and within a few hours understand the most basic architectural decisions and component interactions, then you could be out of a job in an afternoon. The only way to truly protect yourself is to make decisions that address symptoms. If you're asked to add a field to a form for an entity, then by all means, make it a completely new entity, name it something convoluted, and persist it in a completely different mechanism than the original entity, perhaps relating it through a shared child object or parent. After all, if someone can figure that out in an afternoon, then they deserve your job. Furthermore, you can justify your code by spouting out tremendous technological jargon such as "decorator pattern" and "persistence unit"

Spaghetti code might be a good start but can be accomplished through mere incompetence. To really obfuscate your meaning and thereby achieve immortality (or at least your paycheck) takes more malice and creativity.

First, name your variables things that are actually counter productive, not merely non-descriptive, but actively dissembling.

Second, abuse data types. Need an Integer? Make it a string and cast when necessary. Need a String? Make it a char[]. Need an internationalizable string? Make it a short[]! Virtually everything can be stored in more complex data types.

Maybe you're writing a financial application and it's database. Varchars can hold virtually everything, and random sizes are key! varchar(57) should appear at least once, as a warning, to other Cynical Developers. This will tell them "Don't mess with your code, lest you be doomed to insanity"

If you DO eventually give in, for your own sanity, and use numeric datatypes, under NO circumstances should you use decimal places. That'll just make everyone's lives easier, and we certainly wouldn't want that.

Cynical Developer Process

We as developers often realize when a specific enhancement, feature or project is a complete waste of time. Our reluctance is often based on a more clear understanding of the potential pitfalls and complexity surrounding a given feature. This reluctance is an underutilized indicator of the eventual time over-run, estimation, and success of a project. In order to leverage this key indicator I present the Cynical Development Process, in which a developers instincts about complexity are valued as highly as the sales-force desire to include a "trivial" enhancement, or even the customers desire for a feature laden rich application.

Chapter 1: Cynics are Psychics

Often when asked to add a feature to an application developers ask the question "Why?" This might seem counter-intuitive to their role, after all it's our job to say "How high?" rather than question the customer's instincts as to requirements. This is because as developers we often know things about an application that the sales force doesn't. On occasion this can be communicated as "Why? It's already there." or "Why? It's a stupid feature that will break other features." The point of our questions isn't to question the customer as such, after all, if said customer is willing to pay for a feature, who are we to turn down a paycheck? Rather the point is to wonder if the amount that the customer is paying for that feature is of a standard ratio to the complexity and amount of work to add that feature. Many features, while seemingly simple, have far reaching effect on other aspects of the program. A "simple" database change can often require not only a complete re-testing of a component, but may also multiply the testing and maintenance of that component for years to come. How many reports need to be rewritten when you add a payment type?

Lesson 1) We have all been a part of a well implemented project that failed. It happens. 

This is apparent in how many successful companies operate. The first question must be "Build the right 'it' rather than Build 'it' right"

Google's Patrick Copeland provides the following manifesto that all Cynical Developers can benefit from and I'm sure agree with:

the pretotyping manifesto

innovators beat ideas 

pretotypes beat productypes 

data beats opinions 

doing beats talking 

simple beats complex 

now beats later 

commitment beats committees

See: http://qconsf.com/sf2010/speaker/Patrick+Copeland