Enterprise IT: immature and simple?

Once you've admitted to yourself that you're a bad programmer, you can stop all the silly posturing and pretending that you're great, and you can look around and find the best possible tools to help you look smarter than you are.

- You're a Bad Programmer. Embrace It.

People pile layers on top of layers, abstractions on top of abstractions, complications on top of complications, crap on top of patches, and patches on top of crap until everything collapses onto itself and the singularity appears.

- Comment to Ryan Dahl

Recently I was confronted with the following problem:

• Which x maximizes u?

I remember that I had solved similar problems in analysis lectures about a decade ago, but I had no clue how to approach the task today.
I also have the impression that it would take weeks if not month for me to get back into the subject. Ok, I can read the wikipedia article about the quartic functions but I don't think I will get it without investing some major timespan. I am even doubtful if I could suck the knowledge I need from the internet, or if I finally would have to go to the bookstore and buy an analysis book ...

This made me think about my everyday work as a "coder for hire"/consultant working in the trenches of enterprise IT projects.
I am confronted with problems I have never dealt with almost on a daily basis. However this makes me not nervous at all ...
For instance in a recent project it turned out that I had to write reports with SSRS and integrate them in some custom SharePoint controls. I have never done that before. I never came near to SSRS before and I delibarately had kept a long distance between me an SharePoint. Still I was not afraid of those tasks. I was quite confident that I could solve the tasks within the expectations of the customer (however I am sure there are many developers that would have provided better value for the customer). When I look at the quartic function above I am much less confident and would be get quite nervous if I had to solve that task ...
I started wondering about that fact and came up with some theories:

• I am just a natural talent in everything related to enterprise IT ... nah, I don't think so :-)
• Enterprise IT is a simple domain. We don't really deal with substantially complex or challenging problems, at least not in the technical realization. We mostly deal with trying to understand technology that has been created by other people. Trying to find out what the assumptions and intentions of those other people were and how to match that as good as possible to our context. If we are good, we try not to apply the technologies in a wrong way. (note that I differenciate enterprise IT from other areas in IT like i.e. scaling a cloud infrastructure like facebook or developing new algorithms for video compression, there I think we still have real innovation and technical challenges).
• In the IT industry, especially in enterprise technologies, knowledge is extremely easy to come by. Probably the only real skill you need, is to effectively search the internet. Then you can almost solve any problem. Just ask Goolge and spend some time on Stackoverflow ... you don't need a CS degree for that. Of course that was deliberately provocative: The small challenge remaining is how you combine and apply the knowledge you sucked from the internet. And of course the ability to know when not to apply a technology and look for another solution.
• The IT industry is very immature, at least in the enterprise environments I usually find myself. For each project I get hired, I usually have to go through an interview process. These interview processes have quite different flavors of sophistication but the people conducting the interviews think they check that I am suitable for the job. They usually get the requirements for the job through some obscure windings in the organization, but in most cases it has nothing to do with what I end up doing once I really get in touch with the project. It seems the enterprise IT industry has a hard time defining its specialists. The result is that a bunch of generalists like me are stumbling along doing a mediocre job ...

If you like this, follow me on twitter...

Programmers Stockholm Syndrome: Don't get addicted to crappy projects!

Episode 1.1.1 of "This Developers Life" discusses an interesting theory: Programmers Stockholm Syndrome.

Why are we participating in Death March Projects? Why are we staying in dysfunctional environments? Why are we putting up with jobs we don't like?

The answer: The Stockholm Syndrome. The more we get abused by our project environment the more we get sucked into it and the more we define ourselves by the project and its goals, however stupid they are. We get dependent, even addicted to the dysfunctional environment.

Read Chad Fowlers blog post bringing up that theory.

Scott has another interesting theory in this podcast: Like the career of successful Hollywood actors is defined by the scripts they have turned down, programmers careers could be defined by projects they have refused to be part of ...

Then Scott goes on and gives the opinion that failed projects finally are the experiences that makes us good developers. We should write on our CVs in how many failed or botched projects we have worked...

On this last point I tend to disagree. Of course I believe that we can learn from failures, but this learning is limited. And it diminishes with every additional failure. I think you can learn much more from participating in successes and in reflecting them.

I think in our industry a lot of us have assumed this pseudo-darwinistic position of "what does not kill us, makes us stronger". We use this as an excuse to stay on a failing or botched project. We say "at least we learn how not to do it" and try to stay through it. However if we never learn "how to do it right" all this learning "how not to do it" will never help us. We can take a thousand ways of "how to fail" to our graves without ever having experienced any success ...

 

As expressed by the guys from 37signals:

Learning from mistakes is overrated!

 

Or as Tony Hoare puts it:

If we could only learn the right lessons from the successes of the past, we would not need to learn from the failures.

follow me on twitter, I need some friends :-)

Quotes of the Week: Motivation

I love my work. Yet put me on a team with unclear goals, little collective responsibility, arguing, and infighting, and I'll wake up dreading going into work.

- Energizing Work by James Shore

On the morning of his two year anniversary at the cubicle company, Ashton was driving to work when he realized something.

Not one line of code that he had written had ever run.

Not one thing he had done in two years of work made any impact on the world.

- The Story of Ashton by Joel Spolsky

In corporate environments the product don't have to be good. Sometimes they don't even have to exist ... if you are a thoughtful developer, you are in the wrong place!

- Jeff Attwood on Stackoverflow Podcast 41.

In reality I have almost never met a passionate developer, that is really happy with his job.

- I do like my profession, I don't like my job by Jonas Bandi

The productivity difference between a happy developer and a disgruntled developer is enormous, and constantly underestimated.

- The Framework Myth by Mike Mooney

 

follow me on twitter, I need some friends :-)

Rewrite It!

For a lot of projects a throw-away prototype would be the right thing to do... but people are very afraid of throwing away software.

This idea of throwing away your project can even be taken further than prototypes! TekPub has proven that, read it here:

• Architecting TekPub - Moving from ASP.NET MVC to Ruby on Rails
• Upgrading Tekpub with Rails 3

It seems that TekPub has been completely rewritten two times since going into production about a year ago (and several times as spikes before and after going into production).

This is the very realization of some interesting concepts:

• Deliberate Discovery
• Build Less
• Race to Running Software
• Ship It
• Rework

 

Compare that to your corporate legacy enterprise project ... sure it can't be compared, but why? Couldn't a rewrite be more effective than the uncontrolled growth we all observe in legacy applications?

It would mean that you also have to keep your enterprise applications slick and lean. Why is that so hard in corporate IT?

The challenges in rewriting legacy enterprise application are probably the missing stakeholders, the missing original goals and the lost knowledge of the current teams. And those rewrites that are attempted often end up in a gigantic technically driven framework monstrosity... probably because that is easier to do than thinking about business value.

This seems to be an omnipresent pattern and leaves the sour question if corporate IT is really the place you want to be ... especially if you compare it to the seemingly challenging and adventurous parallel universe of web startups.

follow me on twitter, I need some friends :-)

Cassandra Syndrome: Knowing that failure is inevitable, but nobody is listening

Cassandra's doom was to predict what others refused to believe.
While Cassandra foresaw the destruction of Troy, she was unable to do anything to forestall these tragedies since no one believed her.

[Wikipedia]

In death-march projects the developers are often suffering from the cassandra syndrome: They know that the project is doomed to fail, but they gave up on trying to change anything long ago.

In several big enterprise projects I have been in, developers just stopped caring, they gave up on craftmaship.

This is the typical No pigs, just chicken antipattern. The courageous pigs left, the coward pigs broke, the chicken remained ...

A typical pattern for dysfunctional projects I have come across is that there are several layers of hierarchies between the stakeholders of the project and the developers.
These intermediate layers have absolutely no interest in communicating any problems to the stakeholders above. And the stakeholders are completely content with being lulled in the comfort of getting smilies or green traffic lights in their high-level status meetings.
Usually at the point when the smilies stop smiling or the traffic lights get yellow it is too late. The project has gone completely off track and is doomed to fail badly...

Recently I came across another name for this symptom:

The Green Effect:
The higher a status-report goes in the organzational hierarchy the greener it becomes.

The following Dilbert strip illustrates this brilliantly:

When I voiced my Cassandra analogy on twitter, Scott Ambler replied to me:

@jbandi if developers learn to communicate effectively with the business they don't need to be Cassandras

- Scott Ambler, on twitter

Well, in my experience it's not that simple. I consider me as a developer that can communicate (more or less) effectively with the business. But I find me repeatedly on projects where there is absolutely no process established for effective communication between the developers in the trenches and the stakeholders. And establishing such a process is not feasible because of several organizational layers between the trenches and the stakeholders.

follow me on twitter, I need some friends :-)

Craftsmanship means we should refuse to work in dysfunctional environments!

My post "From coding whore to opinionated developer" last year had quite some comments.

I was taking the position, that we developers do not have to put up with everything. As professionals we should set some minimal standards and if they are not achievable then we should not be here.

I was focusing on rather technical aspects of development. One and a half year later I have come to the conclusion that we should extend our standards to all aspects of development. In my opinion it is a sign of professionalism to insist on certain standards in our environment. If these standards are not met, we should try to change things, but if this does not work we should strongly consider the option of leaving.

Jumping on the crusade of Uncle Bob et al. for craftmanship in the software industry, I think we as craftsmen should refuse to work in projects where the clearly unproductive political and organisational overhead is in no relation to the actual essence of the project. Our professional pride should not allow us to accept certain conditions.

Symptoms of such dysfunctional project environments are:

• Having to sit in overstaffed meetings where we don't have to say anything and won't get anything out of it.
• Working on short term contracts that do not match the assigned tasks (you don't know if you will finish the given task)
• Starting to work without a contract
• Having to start urgently and immediately on a project but when you start working there is actually no work for you to do or nobody has time to introduce you.
• Starting on a project but the necessary infrastructure is not available (hardware, software, accounts ...)
• The only times your manager is approaching you is when you made a mistake in your weekly time-report.
• Having to feed bogus status reports to three different managers that do not talk to each other.
• Having a horde of business analysts on the project, but not knowing who they are, where they are, what they do and how this should effect your work.
• Having no chance to get to know the real stakeholders of the projects.
• Knowing that any concern you voice is just draining away in the maze of organizational overhead.

Accepting symptoms like this is a sign of resignation, it means that you accept that you will never deliver what you are capable of (which is quite a comfortable excuse for mediocrity), in essence you are giving up on being a professional.

Sadly I observe that contracted developers in big enterprise projects put up with almost everything (I am including myself here). Some of us struggle, but we give up at some point. We can't identify with the project any more, we do not care any more. We are just executing tasks. We cling to the cheap excuse that at least we are getting paid ... we have given up on being craftsmen.

This is the typical No pigs, just chicken antipattern.

 

(Note that I am aware that a lot of us developers are suffering from the "I do like my profession, I don't like my job"-syndrome, I am not arguing that we developer should be treated like divas, but I think that there are a lot of environments where we cannot bring any change ever, and the only way to achieve a change is to refuse to accept them ...)

Braindeadness successfully achieved ...

Today it was finally confirmed, that my journey to braindeadness was successful ... Im officially a Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5 ...

Actually it was quite a challenge, because even though my brain was already proven dead, I had to personally ask Sun support because it was not confirmed on certmanager after six weeks ... supposedly there were technical problems preventing my automated step into zombie land ...

I wish I had already reached the next level of salvation, and could actually make sarcastic comments about my achievements... oh wait, did I just do that? ... braindead ...

follow me on twitter, I need some friends :-)

Go ahead, make my day!

Are you tired of a hard day working in the trenches of enterprise IT?
Are you frustrated for spending another day in a big ball of mud?
Is your brain filled with WTF from reading wagon-loads of legacy code?

Then I have the right thing for you. Go listen to Stackoverflow Podcast 41.

In corporate environments you are building products, that will never see the light of day in any meaningful way. They are only used by internal people for very narrow things. These are products that would never survive in the outside world. They are just that bad. They have bad features, they are not usable, they don't meet a real need, even to the business... yeah it's really sad ... if you love the stuff, if you are a thoughtful developer, you are in the wrong place!

In corporate environments the product don't have to be good. Sometimes they don't even have to exist ...

-Jeff Atwood

The corporate environments are awful!

-Robert Martin

Do you like some more? Then go along and read: Why Do Enterprise Applications Suck?

Ok, maybe it's time to call a shrink for some midlife-crisis-treatment ...

follow me on twitter, I need some friends :-)

I can offer a lot of that ...

Once again I was loosing myself in blissful braindeadness (learning for the ISTQB Foundation Level Tester Certificate), when I stumbled over a term I actually liked:

Professional Pessimism

This is supposed to be a desired trait of a software tester...

... well, I think I can offer a lot of that :-). Probably enough to dedicate a new category to it ... we will see.

follow me on twitter, I need some friends :-)