Categories
development leadership quickfix ux wtf

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.

Advertisement
Categories
c++ code development programming

Chimera wishlist : !NullReferenceException

What features from other languages do you wish your main development language had?

As someone whose first real applications were written in C++, the thing that always bugged me about C# and Java (after they got generics and autoboxing sorted) was the way they handled references. In my C++ mind, C# and Java pass pointers around, and pointers are allowed to be null. So every single time I have to use them, I have to check them for null, or set up the caller to make sure they’re not null. As Anders Hejlsberg points out, that single fact causes more problems than anything else in C#.

Also, I wish C# allowed const references like C++ to guarantee an object isn’t modified within a method when passing by reference, which is always useful to avoid copying large objects. C# would have to support const methods too, of course.

50% of the bugs that people run into today, coding with C# in our platform, and the same is true of Java for that matter, are probably null reference exceptions. If we had had a stronger type system that would allow you to say that ‘this parameter may never be null, and you compiler please check that at every call, by doing static analysis of the code’. Then we could have stamped out classes of bugs.

But peppering that on after the fact once you’ve built a whole platform where this isn’t built in… it’s very hard to pepper on afterwards. Because if you start strengthening your APIs and saying that you can’t pass null here or null here or null here, then all of a sudden you’re starting to break a bunch of code. It may not be possible for the compiler to track it all properly.

Anyway, those are just things that are tough later. You sort of end up going, well ok, if we ever get another chance in umpteen years to build a new platform, we’ll definitely get this one right. Of course then we’ll go and make other mistakes! But we won’t make that one.

http://www.computerworld.com.au/index.php/id;1149786074;pp;3

So, what do you wish for?