Monday Motivation. An Open Letter

Dear consultants and engineers,

Last week was not a good week for me. So this morning I feel like writing you an (open) letter to talk about my expectations and my aspirations for our week together.

Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to to, let us concentrate rather on explaining to human beings what we want a computer to do. – Donald Knuth

Code is our currency. It is what we are paid to do, no matter what level you’re working on it: if you’re one of my architects, you’re thinking at high levels how big components of code work together. If you’re one of my junior consultants, you’re probably banging your head against some legacy API and worrying whether you can get your story done.

Coding is a deeply analytical activity. It requires that we sit (or stand) still for long periods of time to read, think, prototype with a REPL, wait for build servers, read stories, so on and so on. That’s what we do, and you usually do it in isolation. You’re here because you’re good at it and my expectation is that you take pride but be humble.

Now here’s my aspiration for the week (no matter what level you’re at): increase your energy level, shake off impostor syndrome, and get social about your code.

  • Ask people sitting next to you to pair up for a few minutes.
  • If someone asks you a question, sit down with them and crack open the code.
  • If you’re trying to explain status, throw some code up on the screen.
  • Call a code review for a hard problem you’re working on.
  • Show off something you’re proud of.
  • Talk through a new pattern you found in the open source world from your side project (if you have the time to have one, no problem if you don’t).
  • Can’t find a meeting room? Invite some team members to lunch. Print out the code if you have to (remember what printers are?).
  • Working remote? Get on a video call and have lunch together and screen share.

And don’t just share some gist on Slack. I know that’s more effecient, but it’s not effective and it’s not accomplishing what I want. Read on for why.

Warning: you’re probably going to have to boost your energy level to do this — I know — but it’s worth it. After writing or staring at the computer for hours, you might not feel like you’ve got the energy to get up, walk around, interrupt other people, and engage. Most of us barely have the energy to make it through the day, I know. But what’s interesting is that if you spend energy, you actually get more of it. And by investing the energy in your team or your company, they get more too. It all starts with you, and you’ll be well on your way to leadership by these small acts.

By the way, if you feel unsupported by anyone on the team or in the organization, I want to know right away.

Make it a great week folks and let me know how the social thing works out for you.

Everything you will ever do as a leader is based on one audacious assumption. It’s the assumption that you matter. Before you can lead others, you have to lead yourself and believe that you can have a positive impact on others. You have to believe that your words can inspire and your actions can move others. You have to believe that what you do counts for something. If you don’t, you won’t even try. Leadership begins with you.

-The Truth About Leadership

Short projects are hard

Short projects are much harder than long ones. I’m talking about super short development projects, like four weeks plus or minus a few. First, software engineering is almost always harder than everyone thinks, but in a small project everyone assumes that it’s going to be easy. It never is, is it?

Second, the amount of time you have to establish credibility compresses so tightly that it’s easy to completely blow it in just a few days. Trust and credibility usually take time to develop, but if the project only lasts four weeks and you have a bad demo on Tuesday of week two, you may never recover your credibility before the project ends.

Third, nobody takes the time to analyze everything. Realistically, few will invest much more than a few hours to scope out a project that’s only going to last a few weeks, so they build in a lot of assumptions to short cut the process.

Sure, big projects have a lot more on the line, more eyes, and more pressure. But in a long project, there’s time to absorb some of the inherent risk in all software engineering projects and time to build credibility or restore it from a few missteps and the stakeholders usually invest a lot more analysis into it. Short projects are white knuckled with none of these luxuries.

What to do about it

Only use senior engineers who have demonstrated tech leadership abilities. Don’t even try this with a junior engineer who’s still learning — even if it costs a lot more. You’re probably doing short project because you’re hoping to get follow on work, so don’t blow it by trying to turn a profit on this one; make it up on the backside (hopefully).

Raise the risk before you agree to do it. This is hard because clients are likely to be dismissive and you’re struggling to build credibility. They might tell you it’s just going to take a week. But if you remind them that software development is hard, they usually agree to add some buffer. This is software engineering, and one week can turn into eight. Bigly. Mature clients know it.

Ditch the traditional agile processes and two sprint timelines. Be truly agile in your delivery not your processes. Invest more into management and project oversight time than you would on a short project. One or two day sprints if you must follow the process.

Build credibility with the client by demoing as often as possible but at least a few times per week. Daily if you can. Nothing to demo? Demo code. Lots of demos gives you the ability to course correct and build credibility quickly when the inevitable issue comes up.

Offset some of the risk by increasing stakeholder involvement. Stakeholders might be tempted to be dismissive of of their need to be involved in a short-term project. Make them show up to demos or suspend your work if they claim they’re too busy.

What to do if you get off track

Communicate, but do it at a detailed, code level. Remember, even when you’re off track, you’re still trying to use every minute to build credibility and trust with the client — and you need them to support you for more time.

What do you think? How do manage short projects? Did I miss anything? Leave me a comment or hit me up on Twitter @michaelrice.

Managing software engineers is straightforward, leading consultants is not

Wikipedia defines herding cats as an “idiom denoting a futile attempt to control or organize a class of entities which are uncontrollable or chaotic.” That’s about right when applied to software engineers.

Despite cat herding, managing is (relatively) straightforward

If you ask a team of three software engineers to write some Javascript to say “hello, world” after a user clicks a browser button, you’ll get at least six solutions. The first will copy and paste some crap from the internet and promptly return to Hacker News. The second will agonize over the naming of her function and put some exotic js dependency in the project. The third proposes three different — half completed — options, one based on Elixir/Elm, with an abstracted object model for transporting messages like “hello, world” across the wire and complete with a specialized Jenkins plugins to Dockerize the whole thing and deploy it to Kubernetes.

For all the high minded conversations about agile, sometimes I honestly think it came when the folks in Snowbird finally said in exasperation, “Guys,* can’t we just agree to build one, small, useful thing… and then go from there?!?!” And agile was born.

With agile now mainstream and mature, it’s a relatively straightforward task to keep track of software engineers, to fix blocks when they come up, improve effectiveness, happiness, and etc. — at least relative to what it was like back in the 90s and early 2000s. It’s a lot of work, but it’s pretty well-known.

I’m down to two major problems these days: inexperienced engineers and inexperienced senior managers. There are still far too many software engineers who don’t embrace the agile mindset. They claim to know the ceremonies and come with years of “agile” on their resume, but they learned bad examples or are resistant to the mentality. In either case, my job isn’t about managing, it’s coaching and evangelizing, which is fun when it works.

The second problem is a harder to solve. To grossly overgeneralize, I find many senior managers are warming (or just resigned, possibly) to the idea of delivering incremental value on the West Coast where technology is so dominant. On the East Coast, the big, traditional firms still have a way to go — and that makes the manager’s job tough.

Now, let’s increase the difficulty level; let’s talk about leading traveling consultants

I’m not a software engineering manager working in one environment with a fixed number of engineers day after day. There’s a lot of great stuff written about that role and even conferences now. Instead, I manage consultants who might show up on a client site for just a few hours. There’s almost nothing written about how to be successful doing this.

In both roles, the job is to optimize the value the software engineers produce. Roughly, there are three parts: make sure the project management process it working, help the individual contributors be effective,  and setting expectations up and down.

How managing consultants is different

That’s about where similarities end. First, the pressures feel higher. Unlike an existing, in house development team, bringing in consultants hits budgets in a different way, appearing expensive, so the demand for value goes up. It doesn’t help that clients don’t always need to develop long-term relationships with you, so they sometimes feel free to squeeze.

Second, I work with many different consultants, many of whom I’ve never met and don’t deeply know their temperaments or capabilities, which is something I would care about if I were managing a high stakes internal project. Third, I run too many projects to be onsite enough to coach or manage all the little, but important, things that engineers need to do all day to be effective, let alone the deep details of their project backlogs or the code. My direct reports are only occasionally on projects I manage.

Ways to deal with it

I’ve noticed that people in my role seem to react to it in two (overgeneralized) ways. One reaction is to switch into an administrator type role. This is a natural reaction when you’ve got a lot of engagements with diverse technologies all at once. The second is to stay tightly involved in one technology and/or one industry, which is something I saw a lot at Accenture.

Instead, I’m trying to figure out how a consulting manager can produce highly effective results no matter what technology and across many, diverse projects simultaneously — in other words, how to scale.

I think it comes down to the fact that, at scale, the most you can do is a rough kind of high level, tracking-style management. To be effective, you have no choice but to scale up by  focusing on your own leadership skills. You can’t manage consultants to where the team needs to go like you can when you’re in house.

More on this to come when I find the time…

Kotlin: Let’s Kill the Dreaded Java Null Pointer Exception

I’ve been spending some time with Kotlin this weekend. While I’m still getting to know Kotlin myself, it seems like a language that’s worth your time as an enterprise developer, particularly if you’ve got a legacy enterprise Java code base that you can’t realistically migrate en masse. Helpfully, Kotlin can run side by side with that legacy code and buy you modern language features incrementally (more on this later).

nullpointerexceptionKotlin has many benefits — from cleaner, more succinct enterprise code to modern, functional capabilities (especially with funKTionale). In this post, I want to drill in on a mundane issue, an issue near and dear to many enterprise Java developers: solving the dreaded null pointer exception problem, a problem also known as the “billion dollar mistake.”

First of all, Kotlin takes an oblique approach to the null pointer problem: it simply doesn’t allow accidental null pointers. For example, you can’t do the following because you’ll get a compile error (try it yourself):

If you must have a variable that might be null, you need to demarcate it as optional with the following (clean, IMO) syntax:

Notice the question mark? As you might have guessed, it denotes a variable that could be null, which is similar to (but so much more succinct than) Optional in Java 8+ (or similar Guava features).

Given that syntax, the Kotlin compiler is able to provide you substantial null safety. In the following example, it is always going to be safe to ask for the length of the string in name because the variable name can never be null — ever.

However in the next example, if you try to compile code that checks the length of the name string in example 2 without checking for null first, you’ll get an error.

Let’s look at a somewhat more elaborate example:

In this example, we have two classes where the Address of a Person could be null. We also have some instances of people, one of which can never be null and one that can. Again you can see the compiler won’t let you directly access a nullable variable null without handling the possibility of the null (with the “?” syntax above).

The Kotlin compiler is smart about null safety in other ways too:

As you can see, in the first example, the compiler detects when you access the address field within a null check, which is a pattern familiar to Java developers (maybe painfully familiar?), and lets you proceed.

The second example is a little more interesting and succinct. It shows how you can use the Kotlin elvis operator to safely access a variable that could be null. The first part will print the postal code if it’s non-null and the second, optional, operator (?:) will respond with a different string when address is null — no if statements required!

Also interesting to note in the examples are the string templates, which we will discuss in another post.

Hello, world with Kotlin and Maven

Kotlin seems like an interesting language for Java enterprise developers who want to introduce a new simpler language with modern functional features but who can’t realistically leave their legacy Java code behind. Also, Kotlin is super easy to read, learn, and code — IMO, anyway.

Since a lot of Java developers are used to Maven and the project object model (“POM”), I thought this post might be somewhat useful for you. First, we need is a simple Maven POM:

Next, create a file named hello.kt in src/main/kotlin. Write some Kotlin code and run it in your IDE:

JetBrains has a nice, succinct Maven guide for Kotlin with current version numbers. Also, this code is available on my Github account here: https://github.com/mrice/kotlin-maven-hello-world

kotlin_icon

Software Stranded Me in New England for Four Days

Craftsmanship in software matters to our lives more and more every day. I am reminded of that now that I am stuck in New England for four days because of a glitch with Southwest Air’s backend systems.

The only thing we seem to know about the root cause right now is that there was an issue with a “router,” but who knows what kind? Maybe a network router or maybe it was an API router. Maybe the hardware burned up, but more likely it was some kind of failure deep in the software stack of the device. Worse, for some reason the fail over systems failed too. Southwest reportedly had to “reboot everything” to get the whole system up and running again.

How ironic it was that I was reading about SOLID principles (an important aspect of craftsmanship) in functional programming in the Providence airport as all hell was breaking loose around me. Little by little my phone kept buzzing, letting me know I was getting increasingly delayed and then finally cancelled. The system failure was so bad that they can’t get me on a return flight until four days later.

Only a few years ago Southwest was able to issue paper boarding tickets and recover with old fashioned manual systems. These days, the software is so deeply intertwined that the failure was more massive (almost 1,200 flights cancelled). There was no way to recover.

Getting it right in software is more important than ever. Craftsmanship is one way to do it.

Leading Your Team to Craftsmanship — by Example! (No. 9)

Hey Software Crafter,

Hope you had a good Fourth of July!

Today I was starting some new consultants at my biggest client. These are junior consultants dropped into roles where they have to both excel technically and also exert quite a bit of influence with the client’s engineering team. As if that isn’t hard enough, they have to do this with absolutely no authority; it’s all non-positional leadership they have to demonstrate. I’m here to help them, but such can be the life of a junior consultant.

And their experience made me think about you. I suspect you are either discovering craftsmanship and/or you want to bring more professionalism to your team. Unfortunately, you don’t have the formal authority to mandate the change (both in practices and attitudes) you’d like to see.

Still, getting your team to follow you to a better place is a classic “leadership without authority” opportunity, just like the one my consultants are contemplating in their hotel rooms tonight. Here’s the opportunity: if you can get good at this, you can make amazing things happen with both your code base and your career far, far beyond your individual contributions.

But I’ll warn you, as I warned my consultants this morning, it’s not easy. Indeed, it’s the kind of choice that can lead to frustration, disaffection, and withdrawal if you go about it the wrong way.

For example, what if you read Clean Code over the holiday weekend (you did too, right??), you couldn’t wait for Tuesday to come, you can’t wait to refactor, and you got fueled up on Philz on the way in this morning. You burst into the office and announce on Slack, “Hey folks!! I’m renaming all our variables!!!” I already know the response you’re going to get — I’ve seen it.

It’s easy to get transported to a new mental place by an influential book like Clean Code, but most of your coworkers are probably still in the same mental place they were in last Friday afternoon (or even a little foggier than you left them after the Fourth of July weekend). They aren’t there with you and your over-caffeinated, evangelized self. Most coders are a little skeptical of evangelists. Which stings a bit and could leave you cynically thinking all the puppies and unicorns must be on the other side of some other rainbow with some other team.

So here’s an idea to try before brushing up your resume: lead by example. In The Software Craftsman, Sandro Mancuso says, “When it comes to driving technical changes, especially if the change is about attitude and practices like TDD, nothing will help you more than the ability to lead by example.” He’s right. I’ve seen it. I learned TDD by chance years ago when one of my peers just grabbed a couple of us out of a hallway and said something like, “hey I want to show you how I do TDD.” While I didn’t start doing it consistently right away, as others starting doing more of it, we all started doing more, and I saw the value.

If he hadn’t done that one act of leading by example, I wouldn’t be writing this email today.

(By the way, this post originally appeared as a letter to the LA Software Craftsmanship community. Consider joining us in LA or Phoenix.)

Want to be a Leader? Remember This: Insight < Outsight

“Most of the good things that ever happened to me – both professionally and personally – happened after I finally took myself out of my comfort zone,” I found myself saying more than once in Silicon Valley last week. Sounds inspirational, but I’m a lousy Tony Robbins imitation.

I lack Tony Robbin’s fire but the getting-out-of-your-comfort-zone-to-grow is one of the few principles I know to be absolutely true. We can discuss other things, but this is not open to debate. If you stay in your comfort zone, your world and your opportunities will shrink. Period. Full stop. End of discussion.

So let’s talk about comfort zones. My world, my social network is limited to software engineers and front-line engineering managers; so if you’re reading this post you’re almost certainly smart. You’re smart, and you’re surviving or thriving in the tech business. Your comfort zone is being as smart as you can be.

Smart people usually think before they act. This is the trait that got us where we are, so we think a lot. A L-O-T. Then we act a little. Then shoegaze, navel gaze, talk to some other engineers, think some more, then act a little more. Then reflect on the experience. This is where we’re comfortable. But it’s not an evil pattern. Many of my most effective, thoughtful, and conscientious consultants do this today too. In fact, I believe that thoughtfulness is absolutely key to developing high quality code and reliable systems. And it’s comfortable for us.

rsz_10953_500Here’s the problem for your career, however: you can’t think your way into leadership. Only stretching to do leadership work will turn you into a leader, which obliterates your comfort zone. For a software engineer who wants to be a manager or lead architect it might mean speaking up even when you don’t have all the facts, setting up code reviews and embracing the difficulties of those conversations, demoing a prototype despite the ambiguity and political issues, reaching out to authority figures, and/or a million other uncomfortable possibilities.

Put simply, you have to take a position that takes you outside your comfort zone. Notice how the loudmouths on the team tend to progress faster than the quieter, more thoughtful folks (up to a point)? Painful (and it is very uncomfortable, bordering on painful sometimes) as it is, humans only truly evolve from the outside in, not the inside out.

It’s this very “outsight” as INSEAD professor Herminia Ibarra calls it, the outside-in, that makes the difference. It molds leaders. So take yourself out of your comfort zone. For more on this, read Ibarra’s book, Act Like a Leader, Think Like a Leader.

Act first. Think later.

How-to: An Embedded jBPM hello, world example

Ok, I admit it. BPM is not the hottest of hot trends right at the moment. But it still has a place. For example, BPM is rock solid at collaboratively modeling business processes with diagrams and orchestrating enterprise services — especially microservices. In fact, BPM might let you keep your microservices finely grained, as they should be, and avoid too many composite microservices.

But what if you don’t want to implement an entire BPM server and suite? Instead, you want to flip it around (as I argued for in mode 3 of my draft whitepaper on the same subject). You want to expose a service that embeds the workflow execution engine. If this is what you’re thinking about doing, then I think this is the hello, world example you’ve been Googling for.

Model your hello, world “business process”

I did this TDD, but let’s start our discussion with a super simple business process model. The workflow it describes accepts some initial parameters and then calculates a new string saying “Hello ____.” That is, the example sets a process variable as input — in BPM-speak — and then reads a different process variable to use as output.

bpm-diagram

Above you see my BPMN 2.0 diagram really is simple: it’s comprised of a start event, an end event, and a script task reading the input process variable string (“name”) and setting a new process variable (“welcomeText”) to be consumed later.

First, I defined an input process variable as a data element in the properties window of the overall BPM2 process.

bpm-diagram-properties

One thing I should mention is that the tooling didn’t let me actually specify the string datatype for the incoming type. I had to manually edit the XML file (which is on my Github repo below), but I think it’s just that I’m a little new to the tooling — not that it’s impossible.

Next, I defined the following script task, which reads the process variable named “name.”

script-task

 

I saved the file as say_hello.bpmn in my Maven project’s resources directory.

Now embed the jBPM execution engine

Remember, I don’t want to deploy the BPMN file into a standalone server. I want to flip it around and embed the server. We can do that with just a few lines of Java code. Before we get too far into this, the JBoss documentation says that my approach is “not recommended for real application development but more for try outs.” Instead, they recommend using the RuntimeEngine to give you finer-grained control over your execution. For now, I’ll leave it to you to explore the distinction.

Under this scenario, we just need to create an object that has access to the BPM execution engine and then create a session from that engine. Specifically, the first step is to set up our KieBase, which has the execution engine inside it, and feed it the BPM workflow (documented above). Then we get a reference to a KieSession. KieBase is a relatively heavyweight operation but creating new sessions is pretty lightweight.

Next we’re going to set our process variables on the session and start the workflow (while holding a reference to the ProcessInstance).

Notice the typecast in there? It’s from the kie-based ProcessInstance to the jBPM process instance from the org.jbpm package, which is useful in later steps.

Finally, we extract the “output” of the BPM process by getting access to the workflow’s process variables after the workflow completes as follows:

I don’t like all the typecasts, but this is my first cut. It works, and it’s pretty fast. Comments? All the code is on Github here.

warningAn important caution about this approach: One initial comment you may have is that running a process in this way will cause a lot of problems if you’re trying to run a long-running process or take advantage of the full suite of options in BPMN. I know, I know. But I’m imagining a microservices-like use case that’s pretty limited. By this I mean you’re going to run mostly quick, short orchestrations (likely of other microservices) and you don’t need to incorporate human interaction in the process nor do you need to even store the state of the process as it runs. In short, you’re getting a very limited suite of BPM services, but that’s ok for this use case.