I've been on a few projects recently where "no one wants it", "no one wants a part of it", "it's terrible", "oh you're on that ... good luck" and every type of don't-want-it you can imagine. The type of project you -really- want to ask the people that were there before and ask them just WHY. The client knows it, you know it going in but you do it anyway. Then something totally unexpected happens... it doesn't fail. It may even become an amazing success, and even more oddly, it usually does.
So why don't they fail?
Since I've been off a particularly challenging project, I've had time to not only be on another failure assumed project, but think about what happened. Interestingly, a video game summed it up. There's an intro in modern warfare 2 that talks about the characters being on a suicide mission. They know they're going to die doing this, but there's a bit of liberation, a freedom that occurs when you know something is -going- to end but you get to decide that outcome. It releases your mind to do things you normally wouldn't consider acceptable, much less possible. "It's stupid enough it just might work" is a requirement.
This is where the original problem was kept, hidden from view.
I've now sat here for half an hour, writing and rewriting an explanation of a blend of contained creativity and fear of failure seem to truly cripple projects. I can't come up with concrete examples nor even theoretical examples -- yet somehow the argument still seems valid. I'm not sure if the expectations need to be adjusted, such as on style. Who says "this is the way yee shall render a grid!" ... there's reasons why cars, homes, businesses all look different. When people are told "we have no idea how this is going to work, but we want to you to <accomplish something>". Maybe a focus needs to be on the resulting end goal instead of all the problems on the way?
To return back to my own promise of posting "how long did this take" -- this post took 2 hours and one review by someone not in the tech world ... at all.
Don't believe social engineering can become viral like the latest youtube hamster video? Think again.
From my best count, 12 people every 3 seconds were falling for this. The website is very vague, claiming its safe ...but with whom?! Do people really fall for this? Why yes, yes they do. People want to know who's stalking them ... and yet they can protect their tweets quite easily. Doing a quick look up on them, they're registered via godaddy and their proxy service so you can't really see who they are. Any real service won't do this (yea, I said it, watcho gonna do about it?) so wonder how much damage this will do ... and how many people won't learn there lesson?
Twitter can't stop this either, not without taking out everyone else that's using the API. Might be time for them to issue API codes.
Do you have nice day?! :-)
*** UPDATE ***
Now the site displays the following message
and its straight HTML <center> and the text you see above. So was it a hack of a hack? Hmmmmm interesting. It's too bad they don't have contact info because now I'm curious.
Talked about this during a lunch I went to with Brent Huston (web, twitter) and he asked me had I done a write up on this ... and I haven't so I shall. It's a good piece of info that I think everyone should master - Ask the right question, get the right answer. This pays off in so many ways, it isn't funny and you can use it and abuse it everywhere, in everyday life. This isn't a great theory that doesn't work in reality, this is a basic foundational requirement. Yes, I feel very strongly about this and Brent suggested I should write up how I managed to teach it so here goes.
I hinted at this when I mentioned a good friend of mine, Jay Saunders, was graduating. I tortured him for a solid 2 months (probably more), teaching him this practice. When he started, I told him the number one thing was teaching him how to ask the right questions. Purpose being is multi-layered. First, without asking the right questions, you waste a lot of time figuring out what they (the users) really mean. Second, if you take a minute to think about what you really want, you also should think of the possible reactions of the person being asked -- I will come back to this because there's a lot of nasty pitfalls that need to be addressed. Third, it forces a different thought process and finally, the real goal, it forces the person being asked to NOT give a wrong answer. More...
This is a continuation of my mentoring post made a few days ago but on a more fundamental level. I have no doubt that within every organization, every team and their members are thinking the same thing, but no one is saying it. There's a lot of reasons why and none of them are good. So what's the problem? Communication. People are afraid of looking stupid, asking a dumb question and generally don't want to look like the guy that doesn't know. Well, I usually don't know, so I ask and I've noticed a trend that doesn't surprise me - discussions begin to spawn awesomeness but they're not happening everywhere.
A perfect example came around a few weeks back. I got some time to sit back and learn something so I asked Jon Kruger about what I should be learning next? It's a huge, open ended question but he had a quick, exact response - learn TDD. He didn't say read up on silverlight or ruby or any thing else, he went right for a practice that he's using, regardless of its language. Ok, great, so I asked him "point me in a direction" ... he didn't find anything that was particularly good so, bonus, it spawned a lot of discussions and a few blog posts ...
TDD Starter Kit - Sample Projects and Links
What should you learn next?
Even more important, he did a Lunch and Learn -- we had a full house, around 60 people showed up. That's a great turn out and even better for Jon (people need to listen to him) but when I left I noticed yet another issue ... a group of people, 5 of them were discussing among themselves how they didn't understand where his mocking came from and how his structure map was working because "it was a custom written thing". The fail was simple : They didn't ask. If they would've went up and started talking to Jon about it, I'm sure Jon would have tore it apart and showed them anything and everything -- maybe even wrote a supplement post on it. But they didn't and the general take away was "I don't know how this part works, so I don't need it". Again, this is the fear of asking stupid questions in it's perfect sense.
So what's my point? Start the discussion. Take a chance, ask and find out. The excuse of being silent and pretending "I get it" doesn't apply if you sit back and don't ask. The biggest result that can happen is a wide, sweeping discussion that hashes out a ton of stuff that no one knew everything else is thinking.
My past rash of posts have mostly focused on hardware, servers, linux and other related devices and I'm glad to say, I'm heading back into development. Granted, its VB but its development. So what have I learned in my nearly 6 month absence? Quite a few things, some of which will change my approach on a variety of things. More...
I've recently went through a number of production planned outages of a group of systems we've recently taken over. I like these outages because of that magical word planned. This isn't planned like you put it in your planner and write down a time, no this is a concrete list with no surprises, no unclear roles, everything is laid out and everyone knows what they are doing. This doesn't seem hard and it really isn't, just takes some attention. Being my 2nd or 3rd one on this current project and I'm noticing some good stuff and possible fail routes that can easily be avoided. More...
If the custom module wasn't enough, I'm now wondering off into encryption land. A quick scouting of the System.Security.Cryptography namespace shows me a ton of stuff to play with.
Ooo, AES. I like AES. It runs on my router(s) @ home and is viciously annoying to crack (TKIP f0r t3h w1n!!!11). Cool, let's use that, its good enough for top secret docs for the gov so it should be good enough for me. But, as with anything else, there's a catch or ...20. Here's some basic considerations.
Will this data be searched?
Searching encrypted data is a royal PITA and a huge overhead. Example : saving data to a db with encryption happening in the business layer. A perfectly viable user says to the application "hey, find this" -- you cannot directly ask the database to find it, it is impossible, so every search that happens comes across, ALL OF IT (say 2 million records), decrypts, the search happens, find the records necessary and passes that on. Not very reasonable nor scalable. 2nd option for this is do it on the sql server itself. Fundamentally I have a problem with this for 2 reasons. 1, a purely architecture standpoint, this should never be passed off to the data source. In the real world, it's probably ok to offload some of that overhead, but still, using the OSI model alone says "no no" -- encryption happens in the presentation level and offloading it means you pass though all 7 layers ONCE before you encrypt -- bad bad bad. 2nd, unless the data connection between app/server is encrypted to hell and back itself, your encryption is trumped and effectively worthless.
How much protection is necessary?
The question of the ages. Understanding the CISSP-ism of protection and risk management: the amount of protection spent on it should be equal to the amount of total loss of one breach by the inverse of the possibility of recurrence. So say the data is worth 10 million dollars for ONE loss. The probability of loss is once every 5 years. 10m/5y = 2 million a year should be spent to protect it. No really. Now, if there's no REAL value to the data, ie, its personal junk you keep at home for giggles, then whatever the server can handle works fine. Otherwise, use reasonable + 1.
I'll stop there. Other questions can range from "Who needs access to it?" to "Where will the server be physically housed" -- but thats somewhat outside of the scope of this post. Not saying they're unimportant, just "too much" for this post. I think my first task will be working on getting something simple to encrypt, like a file or a string and work up from there to see how much overhead this thing creates.
One often overlooked aspect of programming is that
evil legal side. Case in point, you are keeping user records of some kind. Now, I'm not talking about SSN, Health Records (HIPPA) or bank info. No, I'm speaking of retaining a users home phone, address, first name, last name, etc. At what point does this fall into the legal consideration category? The answer is "check your local codes". Yea, it sucks, but there's hope.
Within 5 minutes I was able to find the state of Ohio's code regarding (legalese warning!) Private disclosure of security breach of computerized personal information data which is a fancy way of saying if someone steals enough stuff to grant the ability to steal someones ID or other non-public records. The Federal govt has a law(s) for it, but local laws usually reach further and are more clear (as clear as a law can be) as to the actions necessary for this (typically notification and credit monitoring). In this case, here's what the Ohio Law says "Private" information would be... Article 1349.19 section 7 chapter B items 1-4 (I don't make this stuff up)
(b) “Personal information” does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records or any of the following media that are widely distributed:
(i) Any news, editorial, or advertising statement published in any bona fide newspaper, journal, or magazine, or broadcast over radio or television;
(ii) Any gathering or furnishing of information or news by any bona fide reporter, correspondent, or news bureau to news media described in division (A)(7)(b)(i) of this section;
(iii) Any publication designed for and distributed to members of any bona fide association or charitable or fraternal nonprofit corporation;
(iv) Any type of media similar in nature to any item, entity, or activity identified in division (A)(7)(b)(i), (ii), or (iii) of this section.
If you can't get it though normal means (public records, mass media or publication), its considered private information. Still leaves room for "what is public" but something to consider.