Process

This is how I work in my career.  Some of these are counter-intuitive and require explanation.

1. Shipping code wins.
2. On schedules: Picking an arbitrary deadline is often more efficient than carefully planning things out.  I’ve spend 20 years decrying this, but if you add up the time you spend planning, negotiating schedules, then executing, it’s less pain if you just work-to-deadline and throw features overboard in the process.
3. On teams: A disciplined team of professionals cultivating mutual trust will outperform a team of talented jerks.  There are exceptions, but only if you’re writing the Linux kernel or something requiring 10x insights daily.
4. On technology selection: Always pick the technology 1 step behind the bleeding edge, because it’s mature and documented For example, when everyone was going to Rails, use Spring MVC.  This will reduce your technical risk profile in every single case. 
5. Treat everyone as though they might be your boss someday.
6. Code only exists if it’s checked-in to version control.
7. If your team mostly cares about efficiency, run.  Now.  You don’t care about customers and growing.
8. The truly insufferable don’t last long.
9. Managers are much smarter than you think they are.
10. Project managers can help, if you let them.
11. You are not your code.  
12. You don’t own your code; your employer does.

There are many more, but that’s off the top of my head.  Mostly what I’ve learned in 20 years is “the people who came before us weren’t idiots.”

I’ll never forget M.

M was my mentor, and we didn’t always get along.  I chose him as a mentor because we didn’t get along.  I needed someone who had different perspectives than I did.

Anyway, one of our early meetings, I talked about people at work I admired.  I expressed that I admired a guy we’ll call Brad.

Brad was a guy I’d worked with many times.  He was part of senior leadership, and he still found time to write code, on the evenings and weekends if necessary.  At the time, his architecture team was embroiled in doing the scut work of rolling-out “Agile Development” to a hardware-development organization.  (Another really long post for another day….)

Herein, I shall commit heresy.

I’m going to suggest that “Software Strategy” is useless:  Enabling success involves the very large, and the very small, leaving “Strategy” in the useless middle.

Who am I to say this?  I’ve been in software for 18 years, and I’ve been in a leadership role for the last 8.  I’ve spent innumerable hours in “Strategy” meetings.  I’ve had just about enough of that and I’d like to suggest a better way.

Let’s imagine you’re a Program/Product Manager, SDM, or Lead Engineer/Architect.  You’re starting a program to develop tech thingie ‘X’.  You’ve read all the books.  You’ve looked into Agile, from the brevity of the Agile Manifesto, to the what-are-you-selling nonsense that is the Scaled Agile Framework.

In all that, you come to the same decision that people have had since Amenhotep designed the first pyramid:  How do you organize yourself?  That is, how do you set-up your group of people to accomplish the task?

Postulate:

No matter the brilliance of a given development team, it’s always more efficient to Analyze/Groom/Think about requirements before you’re in the meeting where you commit to delivering those requirements.  

I’ve been developing software with groups of fairly brilliant people for some time.  The above is my genuine experience.

Corollary:

When a group of people encounter a set of requirements and expect to scope and commit to them in realtime while reading the document, it wastes everyone’s time.

A few quick thoughts on a subject I’ve seen at least 10 times in my career:

“Okay, when are you done enough for me to test this thing?”

Let’s parse that a bit, because the ensuing arguments are one of definition

• “Okay,” Acknowledging that stuff is just great or else I wouldn’t be talking.
• “when” I’m going to ask you for a date.
• “are you done” Done as is: Things won’t change between the time I hit submit on the bug and I go to the bug review meeting and look like an imbecile.
• “enough” I’m not a total douche.  I’d like to test this, not make you look like a fool by filing 15,000 bugs.
• “for me” Hi, I’m a professional software tester.  Yes, we do exist.
• “to test” I was born to test and break things.  I can make your code cry.  You need me.
• “this thing?” At the end of the day, your work of art is a piece of business value and I’ll not insult both of us by implying otherwise.

The above is the way a real QA professional sees that question.  I think.  Because, I’m not a QA professional, and God HELP YOU if I were.  I maintain my decade-plus assertion that great testers are born, not made.

Just wanted to pause and write about that super-exciting topic: Code reviews.

Let’s begin with defining what code review is, and establishing the case for making it part of your development process.  We’ll also take a trip down memory lane and acknowledge doing code reviews was really hard for years, and now it’s laughably easy.

What is Code Review?

Simply, code review is when someone else looks at your code to critique for defects.  

So, I’ve had a few rants thoughts on process in the past.

I’d like to revisit those with my Big Boy pants on.  For one thing, during my current job search process, my experience in Agile in the past 4 years always comes up, so I thought I’d parrot here what I generally say in the interviews, on why you’d choose one versus another.

If you’ll allow me, I’m going to argue that both are valuable, and both should be in your organization.

I’ve been a software developer throughout the “Agile Revolution.”  My first team lead, back in 2001 said these words to me and I’ve always taken them to heart:

I think the world’s pretty done with us [Software Developers].  I feel like we’ve got about 5 years to get our act together or that’s it.

Apropos, that same year a highly influential group of practitioners signed the Agile Manifesto.   Amid waves of Dot-Com-Bubble-Bursting, offshoring, and right-sizing, they kept it simple:  Here’s what works; apply liberally.

From this article:

Mayer also favored a system of quarterly performance reviews, or Q.P.R.s, that required every Yahoo employee, on every team, be ranked from 1 to 5. The system was meant to encourage hard work and weed out underperformers, but it soon produced the exact opposite. Because only so many 4s and 5s could be allotted, talented people no longer wanted to work together; strategic goals were sacrificed, as employees did not want to change projects and leave themselves open to a lower score.

Ah, the Spotify Engineering Culture.

We’ve all heard the gloss:  Small, independent Squads organized into buzzwordy terms like “Tribes,” and “Guilds.” These terms hearken to days past in humanity, days of community and craftsmanship.

Here’s what I take from the above:  None of that fricking matters.  What really matters is a throwaway blurb at the very end of the video, starting at 12m 30s.  Transcribed here:

We’ve learned trust is more important than control.  Why would we hire someone we don’t trust?  Agile at scale requires trust at scale, which means NO POLITICS.  It also means no fear.  Fear doesn’t just kill trust; it kills innovation.  Because, if failure gets punished, people will be afraid to try new things.

Saturday, I took my daughters to the kids day/open house down at our local PBS station.  Getting past the claustrophobia of jamming hundreds of kids, strollers, and overwrought parents into the narrow hallways and anechoic studios, it was great kidly fun–lots of booths, sing-alongs, and face painting.  On our way out, we noticed a smart-looking medium duty truck painted like a firetruck, pulling a trailer packed to the gills with equipment.  Inside were two “simulator” booths where two robust gentlemen were showing how they train police officers and firemen to drive their vehicles in all sorts of conditions and situations.

You’ve gotta love social scientists.

In the ongoing quest to squeeze every ounce of productivity from the burnout-destined drone age 20-to-40, they’re studying ways to measure collective intelligence.

Quotable quote:

Right now, the optimal size is probably somewhere between five and 10, but with the right collaboration tools, you could imagine having a group that kept getting more intelligent, up to 50, 100, or even 500 or 5,000 people. 

::sigh::

Okay, be proud: You’ve got your name on the company, and you’re the centerpiece of this spiffy article.  What you’re trying to do, though, it surmount human biology:  We can keep 7 +/- 2 ( that is, anywhere from 5 to 9) things in our active memory at any one time.  Whenever you go above that number, we forget.  Managing over that many relationships day-to-day simply creates overhead.

Methodology Doesn’t Matter; People Do

I’ve been in industry for 15 years, as unbelievable as that seems.  I just want to shake people when all they can talk about is Process this and Methodology that and Tool this other.

It.

Doesn’t.

Matter.

Okay, it does matter, but only when you have the people end of things sorted out first.  Assuming an equally talented group, those with a better system will (generally) perform better over time.  However, no methodology in the world is going to make disengaged, sloppy employees perform well.  (It’s tempting to draw a parallel to the Auto Industry, but I’ll spare you.)

I’m part of an initiative developing curriculum and training resources for developers.  Here’s what I have so far on fundamentals and skills for a developer.

Fundamentals

Design and Structure

• Design / Domain Modeling

• Object Orientation / Design Patterns

Development and Delivery

• IDE mastery: IntelliJ, Eclipse, etc.

• Code Reviews / Pull Requests

• Testing: Unit testing, test coverage

• Effective Debugging / Using a symbolic debugger

* Working on an Agile Development team

Way back in 2004, I wrote a short review of Tate’s Bitter Java

Basically, when this book appeared, Java was ~8 years old, and was at the peak of its hype cycle.   Embraced by both the enterprise software world (okay, IBM) and the nascent open source community, Java was the golden hammer, fit for any problem.

Except, it wasn’t.

People who could program, but who weren’t familiar with domain requirements began writing Enterprise Software, and they began making a mess of it.  My own company had to write-off about $7.4 million on a “failed software project” back in 2003.  Suddenly, the C-levels stopped saying “Maybe we should rewrite our stuff in Java.”  Historians term such retrenchment the Thermidorian Reaction, predictable after every revolution.  For us in the industry, it was the heart of the doldrums between the Y2K largesse and the onslaught of Web 2.0.

So, I broke down and took one of the online courses offered at my work on Project Management basics.  I kept hearing domain language from managers, former project managers, and true project managers from our other (non-software) function.  I wanted some info on their thoughts and methodology.

So, during that, I had a light-bulb moment:  Agile software has no project managers.

Seriously.  Back-up and read that sentence.  They don’t exist, and if that gives you the heebie-jeebies, keep reading.  If you have agile and project managers, then you’re doing it wrong, at least as nearly as I can tell.

Have an test requiring me to fast at 3pm today, so no eating for me.  CRANKY!

It occurred to me today to add-up all the time I’ve spent in the last 2 years trying to define processes.  Then I realized if I did, I’d probably become violently ill or just violent. 

My last attempt.  Seems like it should be this simple:

• Have a list of crap for people to do.  Whoever populates that list is THE BOSS, whether his/her title says so or not.  If bad stuff gets on that list and causes you to fail, that person accepts responsibility.
• Make sure someone [competent] covers each item.  In the world of fairy farts and gooseberries, he’ll choose from that list altruistically.  In the real world, someone takes a bite out of the crap sandwich and gets assigned work.
• When people don’t get their crap done, they feel consequences. If they can’t ever get their crap done satisfactorily, you fire them.
• When people do get their crap done, regularly, you promote them.  When they stop getting their crap done, you demote them and promote someone else.  (Take THAT, Peter Principle.)

I think with  the above 4 points, I’ve violated every single methodology in practice today.

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

Engineers are hired to create business value, not to program things:  Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs.  Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things.  (That can, but does not necessarily, entail actually doing them.)  The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs.  Producing beautiful software is not a goal.  Solving complex technical problems is not a goal.  Writing bug-free code is not a goal.  Using sexy programming languages is not a goal.  Add revenue.  Reduce costs.  Those are your only goals.

Definition: Dutch Disease

After reading Alan Greenspan’s book last year, one concept that’s remained with me is Dutch Disease, which I (over-)simplify to mean: When you have one huge cash cow industry/revenue stream, then all your other industries suffer.

Combine that with this article on tech crunch.

I see a similarity there, in that tech companies that were formerly innovative latch onto a current upper-bound revenue source (Let’s say MS Office) and short-change other opportunities, or (worse yet) view them in terms of the current technology.