10,000 Foot Developer

I have an old 2nd-gen MacBook with a core 2 duo processor and ram maxed at 4 gb (although, due to the bus in this, only 3.3 are used).   Running Snow Leopard.  It had a 320 gb 5400 rpm drive so I thought I squeeze some life out of it before I buy a new Windows machine for my Ruby and Android dabblings.

BTW — the old Hitachi drive the machine came with BLEW OUT.  Long time ago, lost data.  Won’t let that happen again.

Here’s how I put the new drive in.

1. I purchased a new WD 7200 320 gb Scorpio drive off Amazon for $55.  I bought model BEKT  because it does NOT have the atuo-shutdown it it detects a fall — I heard there were some incompatibilities for other models.  Also, I purchased a SATA external drive enclosure for $5; since I would like to use my old drive for a while as mobile storage.
2. Swap out the old drive for the new drive (after backing up and shutting down).  I do incremental backups with Silverkeeper, BTW — a free LaCie utility.  The drive sits by the battery in this model; the process is the same almost as replacing RAM — three screws and a bracket.
3. Put the old drive in the new enclosure.
4. Get your Snow Leopard disk, and start the machine inserting the disk and holding the “C” key down — boot to the CD like you are installing Snow Leopard.
5. Go through the language screen, then choose “Disk Utility” from the menu at the top (don’t install Snow Leopard!!!).
6. Important: FORMAT and PARTITION the new disk.  It’s not enough to clone it.  After you are done, exit the Disk Utility and start Snow Leopard Installation (you will stop this though).   If the installation will let you choose your new disk an an installation disk then the format/partition was good (now it is blessed).  I do this because a mere clone-from-backup didn’t seem to set up an MBR properly to mark the disk as a startup disk.
7. Plug the usb enclosure with your old drive into the machine.
8. Back out of the installation to the start installation screen — or wherever you can choose “Disk Utility” again — you will see both the new and old drives.
9. Now, do a “restore from backup.”  Choose the “Untitled partition from the old drive as the source, and the “Untitled” partition from the new drive as the destination.    You can even drag an drop.
10. Click and run — takes about 1.5 hours for 60 gb’s transfer (in my case) or more.
11. At the end, confirm the installation by exiting Disk Utility, and seeing if the install will let you choose the new disk as an installation disk — you should still be able to.  Don’t install though.
12. Disconnect your USB drive, then in the menu choose “Start up Disk” and it should let you choose the new disk.  Proceed with the start up.  You’re done!

The performance improvement was very, very noticeable.  I improved my XBench score from 104 to 131, a 27% performance improvement.

I think this really shows how a higher speed hard drive can really improve performance.  In the future, I am not sure if Mac Users will be able to do this but its certainly a time honored Windows and Unix machine users practice to upgrade their machines.  I am quite happy.

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.