10,000 Foot Developer

Several times over my career I’ve been in places with legacy management styles that plain do not understand software development at all.  And I am always told this by those businesses:

“Software development is just a skill.”

Its always by people who have never been a developer in their lives at all.   They almost always hire the rock-bottom priced labor, and always pay for their received product three times more by over-micromanaging and ignoring the fact, the fact, that to create software a particular skill is just a piece of the set of things required to make good sound software.

How about some analogies:

• Painting is just a skill.   But would you say there is a bit of difference between Picasso’s work, and the Museum of Bad Art?  Why is that?  After all they both had the skill of painting.
• Aeronautical engineering is just a skill.   But why would the Douglas DC-3 deemed as the world’s most successful commercial plane ever, vs. the Spruce Goose who’s time was past when it attempted flight.
• Management is just a skill right.   That’s why IBM and Enron should both have succeeded.
• Writing is just a skill.  That’s why Pearl Buck’s “The Good Earth” and the Penthouse Forum are equivalent in literary impact.

The places that get drained of funds by software have the “skill” attitude.   I’ve seen it at the low level, I read about it n WSJ at the 10,000 foot level.

Part of my job now is to educate the people on why development extends beyond just a skill.  There are a LOT of inputs to consider:

• Culture: Poor or good technical leadership.  PM’s cannot provide this, and using non-technical people to do technical leading can result in failure.
• Culture; Setting up command-and-control environments.   These environments will drive away self-motivated engineers, because they will not be able to act; and only attract people comfortable in showing up and doing what they are told.   A place can’t have both, sorry.   It’s culturally based, that’s why.
• Culture: innovation.  So your company wants innovation?  How are you going to get that if you hire followers and give them no time to innovate?  Or do you think that people not involved directly in the technology you want will be able to to think up uses for it?
• Oil changes.  Software needs upgrading, and if it doesn’t get it, you will suffer.  Oh yes you will.
• How do requirements get translated into reality?
• The moving-targets of new technology and support and staff rollover.

Development involves a whole slew of highly cognitive activities including technical prowess, communication skills, the ability to become experts at software that manages a business they have not studied, keeping up on the tools and new tools and technologies, and of course the highly, highly difficult part — the actual making of software so that it works, is testable, supportable, and does the goal of the business.  Not everyone can be a developer — not at all.   To write it off as “just a skill” is painful to my ears.

A little while ago a good friend architect of mine told me about a crazy over-engineered project he was working on; the application had two or more caching mechanisms, and took over a week for a new developer to get onboard.   At a gig I had last year (and I’ve written about this) I worked on a project that had three persistence mechanisms and two dependency management mechanisms.  A pure nightmare

How does this happen?  Well, I think in a recent article I mentioned that one cause is human nature and the failure to really understand something, and thus dismiss that and put in their own solution.  Now I am seeing a second cause: the need for demonstrate technical prowess for its own sake.

Recently I was approached by an architecture team to look at a home grown service bus mechanism –never mind that there were great solutions out there, they had a home grown one in the last year and blahbity blah blah.  Situations like this re-inventing the wheel are nothing new but of course being an implementation type, I shot off several questions about maintainability, performance, and business ROI that I didn’t feel they were addressing.

It became clear that the team did not know how to refactor, and the team wanted to maintain creative control to the point that it was detrimental to their project.

Now on my projects I am not against a little bit of useful complexity.  But with a lot of projects under my belt, and knowing its so rare to see something elegant, I started to scratch my head at a team that couldn’t even explain the fit of their created technology into their companies business!

Recently I have been reading the Cathedral and the Bazaar.  In that book the author makes a statement, that Linus Torvold’s genius wasn’t creating complex hings so much as he kept things simple and did them well.  This perpetuated Linux.

We see this pattern throughout the world.  Simple, effective design like sharks and Armani suits survive the test of time.  Design can definitely be complex, or not obvious.  But complexity for complexity’s sake is a bad thing; its costly, its wasteful, and its ugly. Complexity is NOT innovation.

Its interesting to watch this code smell continue.  Every month or so I hear from them, I guess we’ll see.

Many years ago I was working on a website and I had to do some image manipulation for the graphics.   The company I was working at wouldn’t let me get a copy of Photoshop or anything close to install on my computer — if you installed anything out of bounds the monitoring service on your machine took it out almost immediately.  I ended up having to use Pixel Paint and a bunch of .dll’s from the command line to make some proper graphics.  The cost was four times as much.  But worse, it was disheartening.  It soon became apparent that almost anything I had to do for their site involved undue hoop jumping.

This place has a large Culture of Can’t which is a culture that does not enable its employees to do their profession but instead steps in the way of them in the name of control — they figure that its safer to just pay for the extra work than to take a risk on people they interviewed, vetted, and hired who also have skills their company does not excel in.  These places shut down ideas and innovation, for countless reasons like job security, power hunger, or fear.

Some crazy incidents of the Culture of Can’t I’ve run into recently:

• I met a person at an Agile conference who so thought that developers were messing up their software that they bought and gave them all that famous book “The Inmates are Running the Asylum”  and complained about usability problems with the software.  Upon further digging I found out that developers and QA were put on an assembly line and had to build everything to the specs and time lines agreed to by business and management.  The build teams were just trying to keep up.  The tools were locked down, and no real manifestation of usability was ever put into the specs (shadow requirements).
• A business colleague of mine wanted to do some things for his websites.   He was told flat out by his IT department that he couldn’t do those and summarily dismissed.  This is very interesting, because business is the source of most of the high level design and that earns the money that keeps the place open.  The requests were very doable, in fact.
• At a place I worked at, myself and a few team members wanted to blog about our stuff on the company’s wiki.   We were told by the architects that we couldn’t.   We looked into their blogs and basically saw that they were making blogs akin to writing books.  But none of our teams benefited from their work — we didn’t get any architecture designs, enterprise views, infrastructure support etc.   We had our suspicions.
• A high level dev manager/architect visiting from another state asked me explicitly how to hire and retain good talent.  I inquired about the culture from a few of his employees and found a lot of turnover; unreasonable schedules and an attitude towards build teams that disregarded their expertise for a command-and-control environment.

The two themes in a lot of examples seem to be either 1) cowboy developers gone wild or 2) organizational hierarchy enforcing bad design because of people afraid for their jobs and told no.    And in my experience as a contractor/consultant at a ton of corporations I’ve run into #2 most of the time; in fact, 90% of the time.  And often someone billed as a “cowboy” has simply been handed a sack of buffalo pucks and is trying to keep things in order enough to have time to eat, sleep and maybe see their family.

So in my development and management experience I’ve come to these conclusions to build a culture of innovation and success:

• Empower people.  When you hire these tech people you probably cannot do their skill.   So trust them.  People want to do good.  People are happiest and perform best when they are allowed to act of their own accord on things they enjoy working on.
• Set up a system of accountability — and that means for EVERYONE.  Including management.  Too many places have management working under the table.  People are intelligent and they know what’s going on and when they see this they will act in the manner they are treated.
• Help workers chew on some other problems besides just busy work that will engage them and create business value for your business.   You can’t have it both ways — hire creative inventive people and then “control” innovation.  Doesn’t work like that.
• Remember, there is more than one was to skin a cat.  Just because a person doesn’t do it your way doesn’t mean it isn’t correct.
• Let the people own their stuff.  Then they will also own their outcomes.
• Failure is OK.  Especially if you set up a safety framework of trial-and-error.
• Make your own work transparent, and others will follow and ideas will be generated, people will be happy, and productivity will follow.

I realize that a lot of this is a pipe dream, to immediately drop this in.  But these ideas are more than just “things to make work better” — they are competitive edges.   Huge competitive edges.   How much more productivity do you get from a colleague who likes what they do, and is empowered to execute it?   How much more business can you create with the power of your whole workforce engaged towards innovation?

This kept coming up from several of my colleagues at my current gig, at some other sites and then touched me this week.

Its, working without a mission.  Or a work statement.

If you read some management sites, or about human nature in general, human nature seems to be motivated on the need to be doing something meaningful.  In fact, I read somewhere that a lot of people leave the place they work if it becomes empty and meaningless; even money can’t keep people there.

My personal feeling on this is that we only have so much time on this planet and if we can spend that time doing what we like that is the best case.  We all have to do some drudging things, but working exclusively for a paycheck with no joy of work or minimally the people we spend over 40 hours a week with breaking bread for lunch is empty and a sure path to unhappiness.  And I don’t know about you, but I work best when engaged and happy with satisfying work.

So a lot of us have been discussing that we consult or contract and very little do we ever get a mission statement or anything that’s expected of us.  It’s terrible.  Its stressful.  It leaves any evaluation of us to be based on other things other than our actual performance because there can be NO ACCOUNTABILITY if there is no work statement.

Since I am at that experience level where I get to mentor and manage I have to know some things that motivate people.  Personally I like empowered people who like their work and are responsible, and know that I am backing them too.  Though I am also a developer and prefer that, plus the management stuff.  Why not?

Very few modern managers seem to understand this.  They pull these kinds of shenanigans like never answering emails, or committing to nothing, verbal non-committal communication only.    Things become very gray for an employee and in these situations and the only feedback they get is bad, never good.  It’s like walking on a ledge in the dark: as long as you step right its good, but you can’t see where you are going, and pretty soon BAM!!

Here’s how I approach these situations:

• I ask for things in emails or writing.  If I get no answers, I have the emails as an audit.
• I play the game as long as I can but then I have to draw back and read the rest of the team as to what we all are supposed to be doing.
• I make myself credible and accountable and set an example.  Always.
• I try not to talk about it to a colleague unless I trust the person a LOT.

This situation is corporate waste and LIFE waste; unfortunately its not avoidable in all situations.  Its political, and life is political because power is involved at work.

But rest assured many of us out here understand.   Code and have fun when you can and don’t sweat the rest.  Create a daily mission for yourself and you’ll get through.

Do you know what this is?

Chadburn

It’s called a Chadburn, or an Engine Order Telegraph.     I don’t know if they make these things too much anymore, maybe they do.  You can see a bunch of them if you visit the Queen Mary, or maybe ride the riverboats Mississipi Queen or Becky Thatcher.

A Chadburn is how the captain would communicate to the engine room: how fast to go and which direction — forward or back.  That’s it.

The reason I bring this up is because I keep hearing more and more and more stories of management thinking agile works just like this.  The think this because they get tools like Greenhopper or Rally or Mingle or VersionOne and then they get to tweak the “daily” operations of the teams.  Big AAgile has enabled poor management.  Instead of enabling their team to succeed, they have in effect introduced micromanagement and put all of the accountability on the team for  work it did not agree to.

Unfortunately these management captains are nothing more than insane Ahabs forcing long hours and stress on the engineers hunting white business whales.  They forget that the software steamship needs fuel to run, and it can only go so fast or what we call “velocity.”  In fact, the very tenets of agile have been cast aside — it works best in the build box, and the people who do not know how to do that work should stay away or they severely impact the team’s productivity.

Agile is a contract.  Business says what they would like.  The PM prioritizes with the business and helps intra-team coordination.  The engineers and QA do estimates, and say they can build this much in that time based on their engine size.  Simple.

But now Big Agile is making empty promises to the management teams.  You don’t really have to be “overly technical” no!  You can make the estimates for your engineering team and hold them too it.   They think Agile is this:

But that’s not what software is.   Six Sigma failed trying to do this, and ISO 9000 failed trying to do this.   The breaking point is always the same: management wants the creative process to be predictable and controllable and on a time table.  Well, it isn’t.  Software making is creative, not manufacturing.  Sorry, but thats the reality.

Large companies are getting sold the wrong Agile bill of goods.  More heirarchy is being enabled because of the strict process the tools lay out onto the teams.  And in the end, what happens, is that watching the process so closely changes the process and people use the tools to report what management wants to see, not reality.  And as I’ve said time and again, when that happens, there is usually a shadow process happening to get the work done.  Management becomes a team impediment.

And then, at the end, with changing scope teams never agreed to, work being driven outside or reasonable capacity, burnouts happening your engine room ends up looking like this:

And that is not cool at all.

I’m currently consulting on a project and got one of those classic “consultant workstation” spots to sit at.  Cramped legs and a very, very high traffic area sitting next to customer support people wearing headsets.  Also what had been happening is that people were also taking liberties with our row’s personal articles (pens, papers, chairs even cases) so I told the person in charge of who sits where about it, and that I wanted to move (a lot of my team worked from home, but I asked for them too).  The person in charge was more concerned with missing chairs than the waste of paying a lot of money to a consultant and giving them a practically useless workplace — but we had a common interest in missing things.  So she started to decide where I would sit . . . .

And this is where it got interesting.

The people who were deciding the logistics of where people sat and what resources were available didn’t have a CLUE as to how software got developed.  In fact, when we moved (moving in the corporations is as common as management turnover — every few months) she completely ignored my current dev manager’s requests and we spent an afternoon  arranging cubes.

Its amazing, AMAZING to think that something so seemingly small could impact a project so much.  Here are some of the things I mean:

• Almost no access to meeting rooms — death if you are doing agile.  At one place we had scrums in stairwells.
• Developers getting the exact same machines (and privileges) as people who work in MS Word all day.
• Teams not getting notebooks — crucial for agile style or just working offsite.
• Seating far far apart.

It’s just a few.  This time, the floor manager said “what do you do?” I said “development” and she’s like “great, I’ll put you up with the developers!”

Wow.  I said “slow down there.  I’m not working with them.  I’m working on a project with a owner, designer, a UI person and  PM for several websites and we need to sit together.”

It became very clear that someone who did not understand development was organizing people in functional areas, when some of us were clearly on component teams and not functional teams.  To separate us was to stress our already stressed communications and decrease our productivity.

I don’t have any real solutions for this, but it has to be confronted.   You have to say: “do you really want to decrease the team’s productivity, because it is?”  And “The impact on our team is such and such because you are doing this to us.”

Be aware of things outside your project influencing your project, especially for people with preconceptions about it that don’t understand how development gets done.

About every month or so, no matter where I am, someone comes to me and says: “well, we are going to take you off this project.  I hope its in a place to be taken over by someone else.   We are going to use you somewhere else.”  Then walks away.

From a management or product owner standpoint, some of this makes sense.  They want to avoid having one person in a singular spot, that is, dependency on just one person.   A critical person.   I don’t blame them.

On the other hand, there are implications for this kind of “tech resources are widgets” approach:

• First, the loss of institutional knowledge.  If you swap people around all the time, you probably aren’t going to get the domain coverage you want.  Maybe that’s OK though.
• Team building.  On one hand, you spread the building efforts around the company.  This is good.  On the other hand, it takes 3 months-1 year to get a team to work well together; you lose that.   Maybe that’s OK though. Dunno.
• Planning.  The fact that tech people get pulled off like this means they can’t follow through on their planning and execution of major pieces.  It is my belief that this is why applications become over-complex and hard to maintain.   Everyone does things different.  Again, the “tech resource is a widget” works against the project here.
• General well being.  I am happy with what I am working on now; I have a lot left and I want to master a few things.   But taking me off of it means I only half-develop my knowledge which means less skilled implementation.
• Team coverage.  If I know more of their platforms I can help out debugging the crappy architecture on more systems.  lol  I say this because the people they let “create” at some places are scary; usually you have to be overly verbal and political to get to design something, it just doesn’t fall on your lap.

So the bottom line is this: developers are rarely ever business domain experts and that is a plain fact.  Go into most shops and ask a developer to reproduce a users experience, very few can.  Maybe that’s OK though.  If we are just brick layers, we don’t need to know about electrical conduit.  Or do we?

Now my personal miff about this is that I am a planner.  I plan, I execute.  In much of the agile way I am doing requirements and analysis and improvements as I am developing — it allows for better design, architecture, and execution.  But if my time is short, or I just don’t know, my planning changes.  I look at short term solutions which aren’t optimal instead.   That’s probably the biggest problem.

One thing we have in our hands though, is to work on projects we want to work on.   So if things get weird we are free to find another project and work on it.

I honestly think that a lot of this “agile speak” has gotten too big for its britches.  I’m seeing an interesting trend where management consultants who won’t work with small organizations are talking about scalable Agile.  These people aren’t developers, probably never were, and are getting inside the build box and making things, well, krufty.

So what do developers do?  Parallel process of course!

A parallel process happens when you are faced with an impossible reporting process usually called “Agile” that delivers zero value to your development effort.  It’s for management only, and they think it helps but it doesn’t.  You play the game, report in it — erstwhile the team has its actual process going on.  maybe on a local kanban board, or in free instance of pivotal tracker or a spreadsheet.  its the idea that management (at times, not always) can be an impediment but a developer, without power, can do nothing to remove it.

I was pondering this today during a release.   At the end of our successful release on four new sites (and a scary incident with an old CMS that likes to freak out) everyone started hanging up and people I DID NOT KNOW where on the phone had their names checked off by the automated phone meeting voice.  We were being monitored by non-task people for status.  Status.  Such a strange notion, status.

It threw me back to this weird and uncool gig I had a few years back.   We had scattered teams and were doing scrums with call-in numbers.  Sometimes, we would hear weird heavy breathing and would say “Hello” and no one would answer!   Later we found out the director and the PM’s would call in to monitor our scrums on our phone line, but we weren’t supposed to know.

Does ANYONE think that’s cool?  Really?   Well then you have a problem.  Most of us developers spend a lot of time building trust, accountability and transparency.   These aren’t qualities you take an online company CYA test for (i.e. compliance tests, data safety training etc.); they are internal things.   To be treated like that is just disrespectful, if not humorous.  It definitely doesn’t garner trust with management.  And it has a severe impact on teams.   When we gathered this info our reporting changed massively.  Our scrums became — status — our reporting in Rally became — status.   And we made another process for ourselves on the side.