Tuesday, November 12, 2013

Deliverables, what it is really? I've seen so much horrific code delivered by "senior developers", I could almost cry. Is it really their fault? Is it because they are not familiar with the current industry which they are trying to develop some functionality a specific customer wants? Or it is the customer's fault for not being specific enough? Is it the platform they are developing for is inadequate? Is the time frame too short to actually deliver something which is just a bit better, or even great? Or they are just not good enough?

One particular thing is that if you have consultants making the deliverable they, too often, develop like they did on their last assignment. Or like a jack-of-all-trades developing a back end service like it was some front end webpage. The customer, is happy since the application works, but the code is bad. Should I care as long as it works?

I watched a video with Java Champion and rock star Adam Bien where he says "I don't understand why architects always insist of putting things in different projects." Well for a small projects it might not be necessary but for large projects this is absolutely fundamental because there are so many people are working on the same codebase. The code starts deteriorating into the infamous ball of mud. And it really doesn't need to that large before the effects of the ball of mud starts showing. Even the tests starts deteriorating into testing that the method invokes (Unit tests are a different topic, and some of you might scream "code coverage"). Also when starting out you have to layout the fundamentals for maintaining your code since you won't have the time to fix it later.

One thing in common of these deliverables you inevitably write stuff for deliverance, keeping release dates, not maintainability. If you are developing a shoot-and-forget project (you don't need to pick it up and maintain it) I guess that's a feasible way of doing things. Although if you are ending up maintaining it and expanding it you have to be really careful with deliverables or you'll end up rewriting it.

Most companies ends up in this situation. It starts out with a rather major refactoring of the current system to adapt to new expectations or business needs and it starts to ripple through the whole system, and soon you are in a black hole you can't see the end of costing a magnitude of money and time. I've just seen a such thing where the project is coming to an end, but the functionality is just halfway and has to be "maintained" to finish, if ever. And that's one of the problems, system never gets finished but somehow we always act like this is the case.

I believe the agile manifesto is utterly rubbish, however a great idea. I do believe in incremental development, however it requires a huge amount of knowledge to do it, and in the real world you are not getting people which fully understand the whole complex reality of the systems interacting. The problem is really: When solving the problem at hand, whose problem are you solving? Are you solving your programmatic problem, the system's or customer's problem. Also if you are doing a change to a system, how much work should be done to satisfy, not just the "business value" but also the system? With the change you have just done are the code needed of refactoring? Will you do it or will someone else do it? Most of the times no one will do it because there's no time or money to do it. Most of the times it ends up building a intersection without any connecting roads. The intersection works but what about the rest? The most important thing, as I wrote in my earlier post, your company is as flexible to change as your system is and you'll probably end up with the refactoring anyway.

Business value is a misused term, since your systems are your heart of your company and systems must be built for tomorrow. Your system is business value, not the current product you're currently creating. Your company's future relies on that fact, developers, projects managers, architects, management needs to understand this.

Monday, November 11, 2013

I talked to a friend a few weeks ago about why his former company didn't succeed with their IT solutions, even with a huge workforce and a big budget. He said that some other rival company did so much better with less budget and people, ergo they have to be doing something better. The rival company is about a quarter of the size of my friend's ex company.

We argued a bit about it and then he said "I'm tired of IT when it becomes some sort of self-worth entity in a company" meaning that it was consuming so much time and effort just doing "nothing". He said "They [the rival company] just changed their system with little effort, from a terminal based consoles to modern GUIs." My guess is that they had wrapped their old system with a GUI. I know that the rival company doesn't do anything if the change hasn't been through an rigorous screening process, even before being developed. They are not even close to being an agile (not as in "agile development") company.

I spoke with a former CEO of a company and he told me that they had invested a huge amount of money in a purchased system to automate their distribution. After the budged being spent and the transition failed they gave up and started over to develop the same thing from scratch and ended up in the same situation as the purchased situation. A product no one wanted or could use. The first case the product wasn't satisfying their needs because the product couldn't adapt to their process, and with the self developed product the budget was heavily underestimated to build whatever process they needed. ie simply ran out of money. They started out too big and failed to reach the goal.

I think the the main problem is the idea of IT being just a tool, particular when the systems are automating your company's business, and the leadership regards it as "just a tool". IT should be a tool and simple things are, but immediately when you start out incorporating your business into a system, the system becomes your company. Your company is as flexible as your tools. As an side effect, if your tools are depending on each other to function the harder it is to change, so just buying more tools won't do it. So to create a flexible company you have to create a flexible toolbox.

When using a tool you can only do whatever the tool is designed for. If you buy a rocket it won't serve as a car, and vice versa. You could build a rocket car but you would have to make trade offs, and its not even certain that the technology is invented to build an effective rocket car.

As an example: Excel is a tool, great for different "business" things. A person can create models and number crunchers quite easily, but even when you start out with filling in the first cell with some value you have to maintain this spreadsheet. The more complex the spreadsheet it is the harder it is to maintain, and the more of the business' information represented by the spreadsheet the harder it is to change. The more people that uses it the more general it has to become, since you want more and more functionality out of the same set of base information. The more people using it the more dependent they become of the tool. As more and more business information is put into the spreadsheet more different parts of your business relies on it. Also at some point you will find yourself with a something you depend on but can't do that new thing which would be so critical to have.

If you decide to automate a process into a system you have to really think of the following parameters:
What am I replacing by automating the business process (what would I have to have instead in form of manpower).
What would be the cost of not doing it.
What would be the cost if I throw away the system (how important is it).
How much will it cost me if we decide to replace the system with another system (are we going to be flexible enough, because this is going to happen).

However these are really hard questions to answer, but I think, they are really valid. I'd say to the first question is that you replace a significant amount of people doing the same job (people can always do the same job as a computer, but in most cases a lot slower). So lets say, I get a system which would replace 50000 people that could cut down costs. The missing problem here is that the system is dumb and can only do what they are told to do. Also that you lock your business with the weaknesses of that system. If it can't do it you either have to buy another product which might do the thing you want and merge those two system, or replace.

Systems can't do everything you want it to do. If you want something out of the ordinary you have to do it your self. The smaller the building blocks needed to create that system you might find some product which does some part of it, but you still have to develop most of it.

And in most businesses what they are doing is quite complicated. A human is a lot easier to "reprogram" although could do what ever they see fit according to the situation, as a computer won't (humans do mistakes, computers don't). You could regard this as, if considering the 50000 people as a system, the endpoints of it is a lot smarter than the endpoints (programs) in a system. And in regards of the third question same applies for the 50000 persons, wouldn't it hurt the company if you fire all of these people and you'd loose a significant amount of your business knowledge since, they outline your business. If not, don't buy/develop that system.

A person is always replaceable, 50000 persons is not, it would probably bleed your company too much if you try to replace all of those at the same time. The same thing if you would just pull the plug on a system, your company will probably not survive.

The same applies to your system. Its relatively easy to write a system. Its really hard to write a modular system, most of the times people say its modular but its really not since there are no (current) ways of knowing if it is. SOA is a good start but its not a guarantee. The recipe for an agile company is to have a system which is always built for tomorrow, e.g it has to be modular, contained and restricted. There has to be a strategy of always change and to be able to do it quick. Even so this is incredible hard to achieve and everyone has to realize that the system is your company and when you have a system, your company will not be more flexible and market responsive than your system is.