Somehow one of my users managed to get a vertical tab stuck in a text field (ascii 0x0B) for a CRM Entity. How they did this is quite beyond me. The problem though is that once it made it in it basically made that entity useless. Trying to pull it up causes CRM to puke. Actually, not CRM itself, but the XmlSerializer underneath throws an exception about an invalid character in the XML document.

Tracking this down was a real PITA. Luckily I new the entity was created on a specific day so I was able to narrow things down until I knew precisely which entity had the data. Then I was able to go to the DB and look for it. Now comes the problem:

I have administrator access inside of CRM. But I’m a fairly restricted user on the DB side. If I had Admin access to the DB this wouldn’t even rate a mention. However, I’m not certain of the table name so I can’t just write the query and send it over to the SQL admin to do (He is in another state). Plus he is in an all day meeting. What to do?

The solution isn’t too bad really: write a simple console app that retrieves the entity without any of its properties. Add the property you need to fix (I copy and pasted the value from SQL and replaced the offending character with a space) and then use an UpdateRequest to finish the job.

My bigger concern going forward is how to prevent this in the first place. Do I need to write a plug-in that scans every single entity as it goes in? Or add script to every form to check fields? Either way seems like a ton of work.

Or maybe this will be a one every few months deal, in which case just a quick breakfix job might be good enough.

So start here: Darpa: U.S. Geek Shortage Is National Security Risk

Darpa’s worried that America’s “ability to compete in the increasingly internationalized stage will be hindered without college graduates with the ability to understand and innovate cutting edge technologies in the decades to come…. Finding the right people with increasingly specialized talent is becoming more difficult and will continue to add risk to a wide range of DoD [Department of Defense] systems that include software development.”

If a kid with the brains to be a hot shot software developer is going to take one look at the IT business and say “fuck no!”.  If I was 18 right now and entering college I’d go in to a something besides computer science and engineering.  I’d probably still learn to program some, but I’d focus elsewhere.

Why?  When you sit in a meeting discussing projects with idiots that tell you they can take the project to India and get Indian developers to do the same work for $8/hr you think a few different things.  First is: no, they can’t.  Second: please do so I can come back in 6 months after the project fails and charge you $120/hr to recover the pile shit you just made.  Third is: no fucking wonder everybody else is running for the exits.  Most people aren't as obstinate as I am and won’t stand to fight for their ground.  I could probably make more money by just giving in and moving up stream in to management and leave the program to people that don’t really do it very well.  But I can’t.  And I can absolutely see why other people (Americans) are choosing other professions. 

I hope Darpa is able to find a way to get more American kids to study Math and Science seriously.  I hope some of those kids become software engineers.  But unless the Harvard MBAs wake up to the reality they are setting themselves up for in the future: forget it.

A friend of mine invited me to attend the IASA IT Architect Regional Confrence. It looks interesting and for $150 it’s a pretty good deal. I could probably even get Slalom to cover everything. However, I looked over the agenda and I only saw two items that interested me: “The Myth of Developer Productivity” and “Forecast:  Partly Cloudy.  How Cloud Computing Can Fit into Traditional IT Architecture”. So drive 6 hours (3 down and 3 back) for 2 hours of content. Worse a quick Google turned up “Myth” as an article. So I’m going to keep shopping. Also, this type of Architecture stuff makes me break out in a rash.

Reading the “Myth” article just reminds me of everything I hate about big organizations, PMI, and other bureaucratic institutions. “Local efficiencies” are bad. Got that? See if I can use Code Smith and ReSharper along with my evil Visual Studio to generate 80% of my client’s needs in three days I’ve just caused a huge problem for all UAW workers further down the assembly line. For shame. They might actually have to do some…..work.

The article focuses on how making developers more efficient isn’t the same as making the over system more productive. It never actually dares to suggest a solution: trim down the team and hire people who are better more flexible developers. Oh no. Instead we get criticism of Visual Studio and tools that provide developers with a lot of leverage.

The criticism is that the developer goes off and ‘hypercodes’ to generate a huge backlog of the testers to test. While the testers work through their backlog the developer proceeds on building on an untested platform.

The problem in my view is this is a completely false premise. Perhaps at NASA or other huge bureaucratic institutions have such a rigid role definition that a developer would never have the audacity to do something as radical as write a unit test for his code. Or perhaps have a buddy or two eyeball it. Or lets get crazy and use a tool like ncover and FXCOP to make sure the unit tests actually test stuff and that our code has been delinted. No that would be heresy because the UAW says only testers test code, only Business analysts determine requirements, only PMs create project plans and *gasp* only architects set architecture.

Right

No. Join me in the real world. Real companies don’t allocate budgets for battalion style development projects. We don’t use card readers to load our applications. We don’t use stencils to draw flow charts before we write code. We either deliver what the client has asked for in something close to their budget and time line or we get fired. Not a Myth. A simple cold hard reality. How do you keep customers happy? Deliver what they ask for, control scope creep, bring change control to the process.

The reason the developer generates the huge backlog for the testers is basause during the time he was working the customer added 3 new features and changed how they wanted 2 of the existing features. The customer didn’t formally allocate additional time or budget but they know it’s there. The developer, at least a good one, is going to try to keep things going so instead of waiting he gets going on the newly created backlog that was handed over. This cycle does 1 of two things: either the developer burns out and becomes an Architect or he gets smarter. He starts writing unit tests for his code. He starts using existing frameworks and builds his own addons for those frameworks. He figures out that if he can generate his entire DAL in 15 minutes with some extra work on those templates he can also get unit tests for the DAL. He figures out that if his WCF service will give up WSDL he can write a template to generate a lot of his basic unit tests or at least have the boilerplate stuff generated. He figures out that using a tool like FXCOP can help spot problems early and a tool like NCover will indicate whether or not his unit tests are effective.

He also starts to figure out that there is a huge world outside of just being a kick ass software developer. He starts to talk directly to the users and customer. He starts learning about their business and learns about things like business processes. He starts learning about project management. He talks to the administrators that support the applications he and people like him deliver. He takes what he learns and he applies it directly to his code. The result is a better, more flexible software developer able to effectively use tools and strategies to deliver to what his customer wants.

This idea however is not even remotely consider in “Myth”. Why? B/c it requires the developer to be more than just a developer and the UAW wouldn’t like that. It also would leave executives questioning why exactly they have these people called “Architects” anyway.