IT is killing itself

I just spent 90 minutes on a technical customer support call with the ShareBuilder Corporation.  I could not log into my account to place a stock trade.  After level one exhausted his decision tree it on to level two and then three.

  

1.    What browser are you using?

2.    Which version of the browser?

3.    Do you have browsers other than IE 11 and Chrome 34.0?

4.    Please delete all your browsing history

5.    Can you restart your computer?

6.    Would you be able to use your smart phone?

7.    Do you have another computer?

8.    Please enter this "special" URL into your browser and tell me what is says.

After an hour of this crazy the level three guy tells me he added three free trades as a token of their appreciation.  "The next time you log in..." WAIT!  I CANNOT LOG IN!  The guy tells me they rolled a new software release out over the weekend and they were being bombarded with complaint calls from customers who were unable to access their accounts.  I ultimately hung up and am now working to port my funds over to TD Ameritrade.  During this whacked out call, it occurred to me what the problem is -- Corporate IT has grown to be so large that it is killing itself under its own weight. I asked the level three guy who made the "improvements" to their system and he said different parts were managed by different groups and he had no way of knowing who changed the log on codes.  I asked him if my money was safe and he assured me it was. Clearly they didn't have testing around their log on code so how could a customer be certain they had any testing procedures around their money management code?

If software systems were bridges, many of us would be dead.  Corporate IT executives have no freaking idea what the thousands of techies do in these massive programming departments.  Moreover, there are so many people with their hands in the code base that it's a wonder anything works at all.  If you work in one of these Goliath software shops do you think for a minute that you understand what is going on inside that mountain of code?  Do you even realize how the tiny little change you are making today will impact the next production release?

I have lived in the belly of the corporate IT beast and I know firsthand how out of control it has become.  I recently resigned because I couldn't stomach what I was witnessing and many times required to participate in.  So who is to blame?  I would love to see a new breed of technical liaison emerge who knows IT well and yet advocates for the business.  The bullshit has got to stop while the big pig still has a pulse.

What's Next in IT? Part 1

Micro-Service Architecture

Micro-Service Architecture will finally put an end to complex and massive application systems.  After all the maintenance, patching and myriad engineers hanging changes all over it, there is no mystery as to why nobody understands it.  

Many IT shops are too busy mopping their floors to turn off the water.  They are truly collapsing under the weight of their own technical debt!  They can't keep up with their competition and freshly graduated engineers look away from their hiring departments.

What if we pulled out a blank piece of paper and designed the next generation of software as disposable loosely connected pieces that are superior at performing their role and responsibility for the application?  Get outside the traditional application system and clear your minds.  Think about your car for a moment.  What if you could not replace a failed battery without breaking your car?  That would be stupid, yet most software systems in production today break for such trivial reasons.  It’s called coupling and can be thought of this way.  Suppose the battery in your car has the red and black wires connected permanently and whatever is on the other end of those wires is also welded onto their parts?  The mechanic might have to tell you to buy a new car even if only the battery needed replacing.

This is an example of tightly coupling the parts together so trying to change one thing immediately breaks another.  It’s called collateral damage and is the basis of the game Whack-A-Mole.  You whack one mole only to find two more pop up elsewhere.

Micro-Service Architecture is sort of a weird idea that is actually brilliant in practice.  Rather than a monolithic application of stacks and parts of inter-coupled layers that honestly nobody really understands, we start from simplicity.  Tiny objects that an engineer can totally understand in a few minutes time.  If the consensus is the object is too confusing you throw it away and try again.  Moreover, if after a few months a better object would do the job, you discard the current and plug in the new one.  Whatever object is the best for the job is only a point in time thing.  Even the best object today will be replaced by a better one tomorrow!

This panacea is rooted in the notion of an endpoint producing behavior or data for a consumer.  Note we did not mention programming languages machine types or anything else that will inevitably be superseded by something better. 

If you develop your architecture based on certain obsolescence, you will have a future-proof application where parts can be easily disposed of and replaced by better pieces.

Think about this idea for yourself while I begin producing a sample application of these little Micro-Services Part 2.

ABC of REST

Always Backward Compatible!

You find this awesome REST service that delivers just the stuff you need for your cool new app, but are afraid to use it!  I hear this all the time.  What if it changes?  Isn't this why SOAP/WSDL is better?  First off, SOAP/WSDL is not even better than sending smoke signals so let that go dude.  Secondly, REST can work just fine if we all agree on a few basic things.  I publish and consume REST services from mobile and heavy apps and have never had a problem.  Like anything else, it requires thinking about the service evolution a little before throwing it together.

1. Will my service need to evolve
2. How can I support different versions of my service

First off, provide a header element in the request that allows the consumer to specify which version of your service they require.  Switch on the version and provide the response they know and love.