This is scary stuff!

I just read a story that scared the living $#!^ out of me. In this story. written by Ryan Naraine, entitled Hackers Selling Vista Zero-Day Exploits, it says that with $50,000 you could by your way into a Vista hack.  Now, I just installed Vista on one of my home machines to explore how applications react, and ways I might develop applications for that environment, so I noticed and read the story at eWeek.com. 

But, the scary part of the article was not about Vista, it was about this auction that hackers have.  Evidently there is an auction that hackers buy and sell everything from back-doors into software to credit card info including the pin numbers.

Imagine people sitting around bidding on your credit card number and pin that some hacker stole from you because you went to a phishing site and didn't know it.  These people, they buyers and sellers, are the scum of the earth and should be prosecuted to the fullest extent of the law.  No. I take that back.  They should be strung up by their toes, with a vintage 1998 Colorado Tape backup drive hanging from each of their ten fingers until it is determined that they could never write another line of code.  Then they should be neutered so they could never have a child.  They should have an electronic bracelet that would send a shock through their system if they even come close to mouse.

Some people may feel that I am being a little harsh. And maybe I am. But, do you enjoy spending 5 hours at a client's site removing mal-ware?  I don't. if it weren't for Grisoft and with ewido and AVG I would still be there trying to get rid of that trojan!

To SCRUM or not to SCRUM

I am faced with a dilemma.  It is not a life or death problem, nor is it even important in the grand scheme of life.  However, it is a dilemma I face with my team.

Let me try to explain my dilemma.  We currently are using TFS as our source control application.  we are slowly beginning to utilize the Tasks for development and will continue to move toward integrating QA etc..  We are using the Agile Team Project template that ships with TFS with some minor modifications.  We now have about 17 Team Projects with more to come.

The problem is that our development process is more like SCRUM.  So, low and behold, I found what I thought was fantastic. www.scrumforteamsystem.com developed by Conchango.  This is great! I thought.  I downloaded and put it in our sandbox.  I played with it and found it almost perfect.  Now,the crux of the problem.  Without major surgery,  I can not convert my current Team Projects to use the Scrum templates. 

My dilemma is: Do I bite the bullet and create new Team Projects with the Scrum templates?  Do I spend time upgrading my surgical skills and TRY to convert my existing Team Projects?  Or do I do nothing with the current Team Projects (mine included) and only use the Scrum template for new Team Projects?

I have sent an email to Conchango asking if they provide a utility to convert the Team Projects.  No reply from them.  I must admit, what I know of TFS templates, it is not a trivial task to convert Team Projects to a different template.

If anyone out there has any ideas, I am open to suggestions.

Starbucks only latest in long line

As a developer, I know the draw to have that database right there on my laptop.  I don't have to worry about permissions on the dev database. I can execute any SQL changes and test my SQL code with data that is quick and convieniant.  But, boy does this have security implications, as Starbucks has recently found out.

In my industry, knowledge is power.  I consider my company, and the CEO just happens to agree, to be a knowledge based company.  Sure, we offer Insurance Policies as our product. But those policies and premiums are based on our knowledge of engineering a specific occupancy to its exposures.  We call this Exposure Driven Engineering.  To put it simply: We look at the type of business that is the primary occupant of the facility, we then look at the predominant losses for that occupancy over the years and concentrate our engineering recommendations to those losses or exposures.  You may ask what this has to do with insurance.  I think if you go to FM Global's web site they can answer that better than me. 

All of this loss information we have acumulated over the last 170 years or so is pretty valuable. Along with all the insured information. At FM Global, they kinda think this is important not to expose to anyone else outside the company.

So, back to Starbucks and how this affects me.  Starbucks somehow either didn't make the connection between a laptop being portable and databases on that labtop being vulnerable or someone made a mistake and broke the rules and the whole company is now suffering because of it.  Well, for me at FM GLobal,  the former is definately not the case. (Did you hear that Basem? I understand why I can't have a copy of the DBs on my laptop) FM Global understands the connections and does everything it can to prevent such things from happening. 

How does this affect me?  It makes some of my work harder to do but not too hard.  Given the likes of Starbucks and other companies recently "losing data", and knowing the value of that data to my company,  I think I can work around my little inconvienance. 

(But Basem, couldn't i have a sandbox on a server somewhere? Please????)

TFS Checkin Policy for CI

I just read Buck Hodges blog about a great idea! One that I wish I had thought of. Clark Sell created this custom policy for TFS that checks the CI process via a web service to interrogate the status of the most recent build attempt.  If it is red then you can not check in your code. I've got to have this!

My team is still trying to come to grips with moving our CI process to retrieve code from TFS instead of VSS.  Steve St. Jean, one of my former team members, talks a lot about some of the obstacles of moving from VSS to TFS that our team has hit, among other things, here.  One thing we have struggled with is knowing when CI is Red.  CCNet is great but it is so small in tray and sometimes (often times) gets over looked.  We've talked about creating a web page that would interrogate TFS and turn the whole background of the page what ever color indicates the status of the build.  We would put this on a huge monitor in the middle of the team room for all to see.

But would something like that stop a dev team from continuing their work and checking in their code?  More than likely not.  Enter said checkin policy. It seems to me the devs would get so ticked off about not being able to check in code that they would make sure everyone on the team would know they couldn't.  This might lead to faster build fixes.  On the other hand, how could you check in code that would fix the build??? hmm.. just override the polcy right..  OK, maybe my theory about the devs getting upset is not really that realistic. But you get the idea of how good this checkin policy could be.

I sure do!

patterns & practices team lives the life

At the end of day four of Microsoft's patterns & practices Summit in Redmond Thursday we got to go on one of the best tours I have ever been on.  Tom Hollander was our tour guide and he guided us through a place he knows well:  the patterns & practices development team's workspace.  All I can say is WOW! It must have been embarrassing for my co-workers to have to walk around with me as I drooled all over the floor throughout the entire tour. 

We first started outside of the p&p building where Tom started with the story of Microsoft's building 7.  It seems that Microsoft, with all their expansions and construction, just by-passed building number 7. Tom didn't offer any explanation as to why, but he did say that someone has discovered the mistake and they are doing something about it. They are finally constructing building number 7. Now Tom and the other's @ Microsoft can't send their newbies and co-ops to building 7 to get some paperwork for them and watch as the newbies roam around campus looking for building 7 only to return hours later exhausted.

But, I digress. We entered the building and Tom talked about how the p&p team would borrow conference rooms for as long as they could to facilitate their development style.  Their cubes just didn't work.  Sometimes they would get lucky and stay in a conference room for up to a week without being told they needed to vacate. This went on for a while until some exec got wind of it and decided to do something about it. And something about it, they did! One by one each member of the team was interviewed about what their ideal working environment would look like. An architect was hired and designed a space based off that input.

As I walked through the halls of the building headed toward the p&p space I looked in at the offices of one of the other groups that share the building with the p&p team. I thought, cool they really get to make themselves at home I their offices. One women even had a red throw rug on her office floor with all sorts of little things all over the office that made her feel like she was at home.  each office I passed had little personal things that made each person's office their own.  We stop at the end of the hall in the back part of the building at the entrance to the p&p space.  The wall was adorned with the p&p logo in shining letters.  There were all the p&p books displayed nicely on the right.  But what was this on the left?

A team room.  Not just a team room, but a room where a team could work and be effective.  All of the walls were made of glass.  Some of the glass was white, some of it was clear.  But all of the walls had writing all over them. There were tables in the middle with double monitor stands on them and some of what looked like they could be the most comfortable office chairs you could imagine.  There were three of these types of team rooms.  One even had sliding walls that could slide open to make a bigger team room.  Sorrounding these rooms were the personal offices of the team.  But most of these were shared offices where up to three people shared one office space.  And the lounge.  The plasma TV must have been 60 inches!

It goes to show how much affect your working environment can have on the quality of the work you produce.  Maybe not directly, but definatly indirectly.  When you have the room to communicate and work together, whether you are pair... oops... realtime code reviewing or having standup meetings or design meetings and writing on the walls, you will be more successful.

I leave you with one last thought on this rather long post:

It was a great ending to a week that was full of ways to make me more productive.