What Are Managers Good For Anyway (The Role of Leadership in Software Development)

Tags

agile, leadership, Software Craftsmanship

As an on-again-off-again software development manager, I have asked this question of myself on more than one occasion..what *are* managers good for anyway?

It’s a great question – and the answer is not entirely intuitive.

Software development managers, and the expectations about their duties have been modeled after earlier times, and different types of work. The measure of the success of a manager is often directly tied to the software within the purview of the team that is managed. Which, even, from the title of the role seems like a patently obvious way to do things. After all – software and manager are both in there – so it seems like the thing one manages should be the thing one is measured by.

But take a second look even at the title – software development manager – what is it that is being managed? Software? No – software development. And while software isn’t a bad proxy to measure to find the potency of our software development, it can often be a misleading one.

The reason for this is due to the nature of software. Recognized and memorialized by the Scrum framework, the duty of organizing and defining the nature of the software to be developed is vested in a member of the development team known as the Product Owner. This role is envisioned as a partner with the other members of the team and not one that controls the specific actions of the team. One that collaborates to find the proper priority of software features to be developed, but leaves specific action to be defined by the team itself.

The “what” question is separated from the “how” question. And both are meant to be collaborations on a team consisting of both types of roles.

Where is management? Where is leadership? The traditionalist that takes their cues from car factories and construction sites might say that someone, somewhere has abdicated their responsibility. We should fire whomever it was, and find someone that can do their job. And by the way – this Agile stuff only works in textbooks.

They’d, of course, be wrong.

If we’re looking closely – there’s a huge need for leadership in this situation. It’s just not with the first-order concerns of the specific software output. It’s with the second-order concerns of the system that the software is being built by. The software development manager – should be managing the development of software – setting up the systems and practices, hiring the right kind of people, and ensuring the cleanest code. Then, they’ll be managing software development, and then the software will practically write itself.

—

But let’s put this magic aside for a sec, and take a quick step back.

Let’s parse out management and leadership here for a second. Because the difference starts to make a difference.

When we talk about management, we talk about ticking HR checkboxes. For starters, in most organizations, we can’t very well have everyone reporting to the CEO. Training, timesheets, whatever regulatory things that need to be “managed” – that’s the job of the manager. With this comes a certain degree of leverage. This isn’t bad, but it is interesting as we will see in a little bit.

Leadership is about change. If an individual’s or an organization’s inertia will carry them through to whatever thing it is that they want to accomplish, leadership is unnecessary. It’s very similar to physics – acceleration is defined as changing velocity, which is a two-part vector that includes both direction and speed. If either of those change, you’ve accelerated – and more importantly, a force has acted upon you. Leadership is that force – whether applied by someone else, or by yourself – if your velocity – your speed or direction or both – if they change, leadership has been applied to your situation.

I won’t cover the various ways that this force can be applied, or the tools used to generate it. But it is sufficient to say that the organizational leverage that a manager might wield is one of the most obvious though least powerful methods.

So management for a leader is a tool to the end of changing momentum.

—

Software is an interesting beast, if I hadn’t been clear enough about it earlier. And it is so for several reasons.

Firstly, if left alone there is a natural drag that will decelerate its delivery until it stops entirely. That’s right – if nothing is done to push back against this natural force, an organization that starts to deliver software, given a certain amount of time, will be unable to continue.

Secondly, the problem solving capability of the software team is embodied in the knowledge of the individual team members and in the communication networks within the team. Unless the team is very weak or severely restricted, no single individual would be able to hold enough information to make a better, quicker decision than the team itself.

Following from this second situation, it’s important to recognize that direct manipulation of the team – ordering a specific action – will lead to a reorganization of the team’s collective understanding. It will also create a sense of dependence on the one giving the order — since blindly following a directive is easier, quicker to execute, and necessitates a lower level of responsibility for the results – all of which are pleasant in the short-term.

—

So hopefully the hole that the software leader can and should fill is becoming obvious. But to pull all of this together…

Our challenge is basically, as a software development manager, what do we do when output isn’t reaching potential.

The answer is that we have two options – the path most taken would be to exercise direct manipulation of the team. That is – we might give specific commands about how to deliver…break out the carrot and the stick, threaten, entice – go directly for the output and work back to specific actions that can get that for you.

This is problematic because it makes the system worse, as we said above, it necessitates a reorganization of the team to accommodate the adhoc input (which will be less optimal than it was prior to the command) and it creates dependency. Both of these make “software development” – the thing we are managing – the system that delivers the software, worse. Which means, next time you will be delivering less well.

The second option is to work on the system itself to make it better.

What is the system? It is all the things that go in to creating software, from hiring the team, to the workflow the team uses to create the software to the delivery methodologies the team has for putting software into production. It includes paring and mobbing, TDD and the taste your team members have to create modular, well-crafted software that’s a snap to understand and change. And probably more that I’ve forgotten to mention.

So – you focus on the system and the next time around your output is better. The only challenge is having the character to not stress out and react incorrectly and too quickly to the pain of disappointed expectations (whether or not they were in any way realistic).

Fantastic – so that’s a win. But it sounds like a one time thing. That’s not exactly a full-time job for a software development manager.

Right – except the whole thing was predicated on the challenge that “the output didn’t meet the potential”. Which, as much as this may hurt to hear, will in fact always be the case. Further, as we said above, software development is funny because it rots – the system itself that is. It becomes slower over time. So even to maintain the momentum we have currently, requires a “force”, requires leadership to overcome.

So – even something as boring as maintaining the status quo in software requires leadership. Certainly to make headway and to become a truly great example of software delivery won’t happen under anything less than heroic exertions by a gallant generation of brilliant software leaders and the brave souls that follow them.

Let’s be them!

Happy coding!

Kyle

Why Patterns Suck

Tags

design, emergent design, software, Software Craftsmanship

I was at a jazz jam session a few years back. I didn’t know it then – but I was learning a valuable lesson about design patterns.

Music, in its similarity to software, has a class of design patterns called scales (think Sound of Music – “doe re mi fa so..”).  Scales help musicians to have an intuitive understanding of the harmonic relationships between different pitches.  These relationships have mathematical connections that lead to a lot of simplification and a lot of carrying lessons learned in one context to another context.  There is a lot of value in deeply thinking about these relationships, and getting them “under your fingers” – getting an intuitive feeling for them by playing them.

The jazz solo is an interesting thing – it’s a time for a musician to attempt to convey feeling to the listeners, following as few rules as possible.  Though there are a lot of underlying laws to how to create certain feels….most musicians, in order to be able to express feeling in real-time, work hard to have an intuitive grasp of these laws.  Thinking through the specific details of the performance while performing would be impractical, and it would destroy the original inspiration.  Hence, musicians have located patterns (such as scales) – that allow them to work on that grasp when not performing.

After stepping down from my solo (which was undoubtedly life-changing for the audience) … another soloist took the stage.  He played scales.  For the whole solo.

A fellow listener leaned over and whispered in my ear about the ineffectiveness of the approach….in more colorful language.

Scales…..like design patterns in any domain are for developing intuitive understanding of the space.  They are NOT to be included for their own sake, thoughtlessly in the actual creation.

I’ve seen this a couple of times, at grand-scale, in software.  In the early 2000’s – I can’t remember how many singletons I saw cropping up all over the place (yeah, I may have been responsible for a few of those)…many, many times very unnecessarily.

These days there are a number of patterns that get picked up and used wholesale (with little thought) – MVC, Monad, Lambda, Onion, etc..  This is not how great software is written.  Like music – the domain has to be well-understood, and then the thing created from that understanding.  Picking up the design patterns, whether they’re scales or singletons, and instead of using them in private to gain understanding, we pass them off as creation, we are using them in exactly the most wrong (and harmful) way.

It will make our software worse – decreasing our understanding, and increasing the complexity of our software by creating code that doesn’t match the problem.

 

 

Oxygen

Tags

Software Craftsmanship

“I would sooner destroy a stained glass window than an artist like yourself. However, since I can’t have you follow me either…” – The Dread Pirate Roberts (shh – actually it’s Wesley)

—

Wesley proceeds to bonk Inigo over the head (saber-whips him?) rather than killing him. It’s fortunate for Inigo that Wesley had such an appreciation for his art and the calibre of craftsman that he was fighting against. A lesser man may have gone ahead and destroyed the stained glass window.

In software – it’s not (at least in my experience) so dramatic – we don’t find ourselves in life or death situations based on the level of our craft. But an understanding and recognition of the level of our craft is an important and powerful thing. It’s almost like oxygen to our sense of contentedness with the world, to our self-worth, to the level of fun we’re having crafting software.

This is important for two reasons. Reason number one is that – the craftspeople that we work with share this need – and as we grow and progress in the craft, we are able to provide it for more and more people. The embedded thing here though is that we are only able to provide this oxygen to people whose level of craft we understand and can truly appreciate – folks that are at or below our level. And we should take every opportunity to do this – because it’s good to do this for our fellow human, and because it increases by untold amounts the effectiveness of those around us.

The second reason is because many times we will find ourselves going without oxygen. We need to recognize this – because if we are not careful, it can have massive negative effects on every part of our being – even including our physical health.

What can we do about this..

First – be aware that it is a thing. And be ready to remedy it when it happens. Second – know what some of the remedies are.

They include…

1) Holding your breath – we can for a time go without oxygen without permanent effects – know your limits, but be prepared to hold your breath.

2) Surrounding yourself with craftspeople that are at or ahead of your level. They are the only ones that will recognize your craft – and thus the only ones that can provide the much needed oxygen. This is a hard one though – it may mean leaving comfort for an ultimately better situation in a number of different ways; choosing a different team, engaging people that you don’t have a natural affinity for, or leaving an organization.

The Sardine Revolution – Unit Testing And The New Software Development

Tags

agile, Continuous Delivery, Modularity, OOD, OOP, Software Craftsmanship, TDD, Test First, Unit Test

“Every revolution was first a thought in one man’s mind”
Ralph Waldo Emerson

A number of years ago I remember going to youth group with a friend of mine and playing this super-fun game called “Sardines”.  The rules were basically:  one person hides – then everyone searches and whoever finds the hider hides alongside them until everyone (except for one person) is hiding at which time the lonely soul that is still searching is declared the “loser”.

The reason I bring it up – is because this game reminds me a lot of something that is happening in the software world.  A subtle revolution has been taking place – and almost everyone who finds out about it quietly joins in and hides alongside the rest of the group that is “in-the-know”.

Now not everyone so quietly sits down and joins the can of sardines – every once in a while, like the kid who just couldn’t bear his friends becoming the loser, someone speaks out and gives away the group’s hiding place.

One of the most recent and best articulations of this revolution is from Steve Freeman and Nat Pryce – their expression is so compelling that even if they just stopped with the title of their 2010 book they would have pushed our industry forward several big steps – “Growing Object-Oriented Software, Guided by Tests“.

Ok – let’s stop and absorb that.

There has been a lot of talk about Test Driven Development and Writing Tests First – and these are both good and important ideas.  But they are more like things we feel like we need to bolt on to our technique as an optional upgrade.  In reality – the entirety of our engineering technique needs to be based on using testing as a guide.

But Why?

Guiding your development with testing buys two major advantages – confidence as you make changes to code as well as enhanced modularity and conceptual integrity.

Modularity is a very important ingredient in having an effective agile process.  Monolithic software breaks agile processes as it leads to difficult planning and engineers stepping on each others’ toes during development – having an effective agile process through enhanced modularity means faster (and more fun) delivery.

Modularity is also very important in releasing as frequently as possible (see Continuous Delivery – by Humble and Farley).  An optimized delivery pipeline means getting software in front of users quickly and frequently – which means more *actually useful* feedback.  This means more value to customers faster.

Ok!  How do I join in the fun?

There are several major things that you can do:

1) Read!  Start with the Freeman and Pryce book listed above – then hit Google.  There is a lot of material available about the specifics of writing unit tests.

2) Find a Mentor!  Unit Testing is an art – if you can find a mentor who knows about it and practices it regularly you will put yourself on the fast track.

3) Don’t disengage your brain!  Always question every practice – to make sure that you are understanding it for yourself.  When it comes to “doing unit tests right” – do not take the word of your mentor, a website, or even your own mother – think for yourself.

4) Keep following this blog!  We will follow up shortly with a very in-the-code and specific expose into the writing of a unit test.

But how do I sell this?

We programmers don’t like to be the Traveling Salesman – because we know it’s a difficult problem to start with (NP-Hard actually).  But the pragmatists among us realize that our colleagues, our boss and probably others get grumpy if they think we are spending time on things that aren’t bringing value to the organization.

Fortunately that is not the case in our situation – code that is guided by good testing practices is easier to read as well as easier and less risky to change.  Selling this to people who haven’t been directly involved in this practice should be as easy as a short (though non-trivial) proof of concept effort.

The one thing to remember if you do need to convince others within your organization – as with any tool or technique there will be a learning curve for every individual that hasn’t had experience with it before.  This should not be viewed as a problem with a tool – but just a natural part of growing the skill level of the team.  Every organization expects its members to be continually enhancing their own abilities while balancing the demands of accomplishing short-term objectives.

Next Steps

All you have to do is get started. Be creative of course – if you’re new to testing and you don’t want to try it at work until you are more comfortable with it maybe practice a little after-hours or on your breaks first.

Making this shift – to guiding your development with testing – will make your software even more incredible.