Software++http://softwareplusplus.com
Evolving Beyond The TechnicalWed, 30 Aug 2017 13:46:28 +0000en-UShourly1http://wordpress.org/?v=4.3.12Business: Why Your Software Suckshttp://softwareplusplus.com/2017/08/30/business-why-your-software-sucks/
http://softwareplusplus.com/2017/08/30/business-why-your-software-sucks/#commentsWed, 30 Aug 2017 13:46:28 +0000http://softwareplusplus.com/?p=1328“What do you mean the server went down?” asks the CEO. “It has been happening every week” the lead tech says. “It didn’t do that for the other customers,” laments the CEO. The tech replies “This customer is ten thousand times larger than all the other customers combined. We didn’t build the application to handle ... Read more

“What do you mean the server went down?” asks the CEO. “It has been happening every week” the lead tech says. “It didn’t do that for the other customers,” laments the CEO. The tech replies “This customer is ten thousand times larger than all the other customers combined. We didn’t build the application to handle that volume of data.”

The enraged CEO berates the tech. “Well, why not? What the hell am I paying you guys for??” Unphased, the tech responds: “It would have helped if we had known you would sell to a customer that large, this soon into the project.”

This is an all too common conversation. The business side of a software company is unaware of the limits of their own product. They sell it beyond its operational bounds, and the development organization has to somehow make it work.

But wait a moment. The business side is not technical. How could they possibly be expected to understand the limits of their product, or the feasibility of how or to whom they sell it?

This is where I would normally say something like “the technical side has an obligation to protect the business by helping them understand the limits of the product.”

In a perfect world, the business and technical parts of an organization are aligned, transparent, and supportive of each other. But…the world is far from perfect.

So, for my dear readers on the business side, here are some ways to tell when your software is in trouble, regardless of your relationship with the technical side of your organization.

Bugs, Bugs, Bugs

Repeat after me: “Bug-free software is a myth.” If you don’t believe that, go ask your top tech talent about it.

If a company believes that their software is bug-free, it is likely that they simply aren’t testing it in such a manner that the bugs reveal themselves. There are bugs in every piece of non-trivial software ever produced: aircraft, rockets, ships, cars, web software, you name it.

A properly designed system employs a mixture of technical best practices with organizational best practices to mitigate against negative ramifications of bugs. If the system is not designed properly, you might see behaviors like this:

Every release contains a large number of bugs that have your customers hesitant to take new releases

This means there are problems in your software design, release processes are broken, and your QA process is broken.

When a bug is fixed, it almost always introduces new bugs

Either you have a hero programmer, your team does not understand the code, your system has badly designed relationships between components, or all of the above.

The same bug keeps re-appearing

You have a process problem, or you might have duplicated code in your software.

Your cloud costs are much higher than anticipated

Your teams are using cloud assets inefficiently, or they are not understanding your current or projected customer size and/or system usage.

Bugs in software are a telling indication of the health of the organization that is producing the software. If you perceive that you have out of control amounts or behaviors of bugs, something might be wrong.

Customer Impact

Bugs are one thing, but what if you have issues that directly impact customers? Here are some common challenges:

You have outages in production

There are problems in your software design, problems in your devops, or you are selling to the customers that are beyond what the software can support.

Customer data disappears when you release a new version

Your technical side has a problem with database migrations, the QA process is broken, and the release process may also be broken.

Customers can’t understand the software

You need examine your product team, your UX team, or both. The product does not match the customer business process, or your complexity is simply too high.

To mitigate customer impact, you need to make sure your technical team is aligned to the size and complexity of customer you are selling to. If your customers have trouble using your software, you probably need some business analysis or user-experience design help.

Summary

You don’t need to be Melvin Conway of Conway’s Law fame to understand that the behavior of your software reflects the condition of your organization and the strength of the relationships between them. I invite you to actively ensure that your technical and business sides are operating in alignment, so that you never need to contemplate why your software sucks.

]]>http://softwareplusplus.com/2017/08/30/business-why-your-software-sucks/feed/0How to Deal with Tech Bullshithttp://softwareplusplus.com/2017/08/15/deal-tech-bullshit/
http://softwareplusplus.com/2017/08/15/deal-tech-bullshit/#commentsTue, 15 Aug 2017 14:39:42 +0000http://softwareplusplus.com/?p=1267Spend some time working directly on the front lines of tech startups, and you might notice a fascinating thing about investors, startup founders, and small company executives: they often have no idea how to tell good software from bad, nor competence from incompetence. Buyer beware! It is all too common for a non-technical person to ... Read more

Spend some time working directly on the front lines of tech startups, and you might notice a fascinating thing about investors, startup founders, and small company executives: they often have no idea how to tell good software from bad, nor competence from incompetence. Buyer beware!

It is all too common for a non-technical person to assume that the same web application that served fifty startup customers can also serve a thousand enterprise customers without investing in the evolution of the tech stack. They are not able to question the claims of their WordPress person, who says they can build a highly scalable cloud solution. They cannot easily tell that the Golang-based product they have been funding will be very difficult to staff in their .NET-dominated local tech market.

In defense of non-technical folk everywhere, software development can be complex and difficult to manage. The software industry does itself no favors by adding chaos, confusion, middle management layers full of mountebanks, inconsistent terminology, and lack of standards into the mix.

So how is a business person supposed to know if they are being sold a bill of goods? Here are a few telltale signs.

Sign 1: The Smokescreen

It can be very intimidating to talk to a technical person. It is easy for a technical person to lay down a smokescreen of obtuse terminology that sounds just coherent enough to make sense, even if it is complete nonsense. It may be difficult for the layperson to understand the difference.

This is similar to an auto mechanic that takes advantage of the situation in order to make you think that the work is more complex, more elaborate, more involved, and more expensive than it really is.

One way to deal with this is to ask for a first-principle explanation of the terminology that is being brandied about. Some examples:

Smokescreen: “The database needs indexing.”

Ask: “Help me understand how that is relevant to our release being late.”

Smokescreen: “The code needs to be refactored.”

Ask: “Can you describe what net benefit will be achieved from this refactoring?”

A qualified technical resource should be able to enunciate the ramifications of tech on your world, in your terms.

Sign 2: You Don’t Understand What is Being Built

They say a picture is worth a thousand words. This assertion is very true when it comes to specifying and describing software design, as I have written about here.

There is a well-known international standard for design notation, UML, which was made for the purpose of visually describing software design. Before UML, there were a litany of other design notations: Coad-Yourdon, Rumbaugh, Booch, and so forth. I developed software using a purely visual notation called Software Definition Language (SDL) as far back as the 1990s.

The point is, that many technical people are visual in terms of their communication style. A professional technical person should be able to make his or her point using any and all means at their disposal, necessarily including diagrams. If a technical person cannot draw a diagram to describe their own work, I would be unsure that they have a complete understanding of it at all.

Go ahead. Ask your technical point of contact to explain how they are going to make your product scale in terms of technology. You might not comprehend all of the words, but you should reasonably expect a diagram that will be helpful.

Sign 3: You Feel Alone

Your business probably has some unique complexities, some of which are drivers for the solution you are trying to build. Any technical help should be at least somewhat interested in understanding your business domain, understanding your customers, and understanding how you view the product or service that you are trying to build.

If your technical help is doing none of that, and you feel like you are alone on an island, you probably have the wrong help in some way or another. The relationship between business and tech is like any other relationship. There is going to be friction. However, if both sides try to understand each other, and take the energy or initiative to support each other, the relationship is that much better off.

Sign 4: The Goal Seems Misunderstood

Imagine you are building a house, and you are interviewing contractors. The first contractor arrives with a big cigar, a box of nails, and a hammer. “When can we start?” he says. The second contractor sits down with you and reviews the blueprints for the house to make sure that both of you understand exactly what is about to be done. I hope you choose the second contractor.

Similarly, nothing says “amateur night” more than a technical person that stampedes off to the keyboard to write code before they are clear on the goal. A professional technical person will try to re-state the objectives to you before any actual work is done. There should be an open and meaningful dialog about what success looks like, and what failure could mean to both sides. Often this involves early prototypes of the work, so that you can modify the direction sooner rather than later.

Summary

I’ve noticed that when non-technical people have a feeling that a technical project is not going well, there are usually some good indications that they are right. Pay attention to that feeling and get engaged with your technical team. If the signs are there, you can understand and act on them.

]]>http://softwareplusplus.com/2017/08/15/deal-tech-bullshit/feed/0Development Culture. Do You Speak It?http://softwareplusplus.com/2017/01/10/development-culture-do-you-speak-it/
http://softwareplusplus.com/2017/01/10/development-culture-do-you-speak-it/#commentsWed, 11 Jan 2017 03:54:20 +0000http://softwareplusplus.com/?p=1115What has a hundred legs, sits in your office, occupies fifty computer screens, clicks on keyboards and trackpads all day, and gets nothing accomplished? Answer: Your development team. Wait, the CEO says. What is going on here? We hired a bunch of developers. We bought a very long party table and two very long benches. ... Read more

What has a hundred legs, sits in your office, occupies fifty computer screens, clicks on keyboards and trackpads all day, and gets nothing accomplished?

Answer: Your development team.

Wait, the CEO says. What is going on here? We hired a bunch of developers. We bought a very long party table and two very long benches. We put everyone together in a warehouse with a tin roof and a giant Steve Jobs motivational poster. We supply soda and pizza five days a week (and beer on Thursdays.) We made every Friday into Hawaiian shirt day. Why aren’t they producing great software?

Why, indeed. You see, dear reader, software is not necessarily linear in nature. It is an abstract, complex, creative endeavor. If one equates software development to shoveling rocks into wheelbarrows, the results will be bitterly disappointing.

Let us explore this together.

A Tale of Two Teams

Consider two development teams working within two small companies.

The Blue Team

The Blue Team is led by a director having no development background. He does not spend much time thinking about best practices, but believes that competent developers should either produce 100% bug-free software, or be fired.

Blue Team is composed of the original technical co-founder and a band of developers brought on after the initial product version was built. The technical co-founder still plays the “hero programmer” role, and does not openly share his substantial domain expertise with his new colleagues – after all, if the information was difficult to obtain, then everyone should have to go through a hard indoctrination, right?

The Blue Team developers have learned to be very risk-averse because they don’t understand the software under development as well as the co-founder does, and they certainly don’t want to be accused of breaking the software through their own ignorance. Iterations are chaotic partly due to the lack of disciplined processes, and partly due to tribal knowledge that is lacking from developer to developer. When deadlines loom, the approach preferred by the director is to work harder and longer. When bugs arise, they end up at the feet of the original authors because nobody else knows what was done, or how it was done.

The Red Team

The Red Team is led by a director with a background in technology. This director is an expert at balancing engineering discipline with the realities of business prioritization.

Red Team developers pride themselves on being students of the art and craft of software. The team purposely uses modern tooling and takes accountability for their releases using a pragmatic test and deployment strategy. They choose tech stacks and languages based on technical, business and environmental conditions rather than religious dogma. They manage iterations with discipline and maturity.

The team keenly and openly shares code, ideas, and solutions with each other. Designs are challenged within the team in a supporting, professional, and positive manner. This cross-pollination of knowledge also means that when something breaks, the team can cover for each other. Every second Friday afternoon, the team takes time to improve their own skills by researching and exploring novel projects using the latest tech. These behaviors are openly espoused and promoted by the director, and some of the new ideas from developers even make it into the core product.

And Now, a Quiz

These teams represent two extreme examples, but they are based on very real scenarios. Time for a simple quiz.

Which of these teams will produce a better product?

Which team will produce software more quickly?

Which team can scale faster in terms of people and technology?

Which team has the lowest turnover?

If you answered “the Red Team” for most of these questions, you are probably correct. The Blue Team might actually produce an initial version of software more rapidly, but it would likely be sub-optimal over the longer term. This is Conway’s Law in effect.

There is a term for the difference between these two teams. That term is “development culture.”

What is Development Culture?

Yes, dear reader, development culture is a real thing with pronounced effects on the way knowledge work gets done. Here is my own definition:

Development culture is the way a development team works, and how they produce results.

This definition is purposely broad.

Development culture is about how developers build products; how developers relate to each other, their team, the surrounding business, the physical environment, the processes and tools, and the product itself. On an interpersonal level, it is about communication, teamwork, unit integrity, and how obstacles are handled, ranging from high level strategy to low-level tactics.

In my own travels, there has been no single universal standard for “good” or “bad” development culture. It is specific to the organization and the individuals involved. If a developer is working in a Red Team, it may not matter if the company supplies free meals, a laundry service, or beer parties – the developer is probably having great fun doing the work, surrounded by a vibrant team. Similarly, on a Blue Team, the free meals might have to be plentiful and delicious to keep a developer from leaving.

Is Your Development Culture Healthy?

You don’t always need a doctor to tell you that you are sick. Similarly, there are telltale signs that indicate whether your development culture is healthy without knowing all of the details at the ground level.

Diagnosis: Healthy

Revisiting our Red Team, their product and their practices would likely show the following:

The product works for their customers, with relatively few bugs.

Speed of building and releasing new functionality remains consistent or improves over time, even after initial product creation.

There are very few bugs caused by deployments and change management issues, likely due to automation and disciplined development practices.

Bugs are fixed rapidly and rarely cause more regression, due to the use of technical testing as an integral part of the development process.

After each release, there are fewer and less severe bugs relative to an organization with an unhealthy culture, and these bugs are fixed rapidly.

Low turnover of development staff.

Diagnosis: Unhealthy

How about the Blue Team?

The product is unreliable, and customers are likely complaining about it.

Bugs seem to take forever to fix, and when they are fixed, other things become broken in the process.

Releases are often delayed because of high bug counts, and customers do not trust that releases will be bug-free. This erodes confidence in the product.

High volume of support calls when new features or bug fixes are released.

High developer turnover relative to an organization with a healthy culture.

Difficulty hiring new developers.

Moving from Unhealthy to Healthy

Unfortunately, in my experience, unhealthy development cultures are by far the most common. I consider unhealthy cultures to be the automatic result of neglectful behavior. A healthy development culture takes work, intentional design, empathy, and – possibly the most difficult thing – the release of a certain amount of control. Hiring smart people often requires you to get out of the way in order for their best work to happen.

If your organization is like most, you probably have a combination of characteristics from the Red Team and the Blue Team. Here are some ways to reduce or eliminate those Blue Team tendencies:

Solicit honest feedback from the team, without coloring it with your own bias. Take the feedback to heart and plan to take action. HR-sourced employee surveys typically do a lousy job of eliciting development feedback. You might need to hear feedback directly – especially when it is difficult to hear.

Examine your product objectively. Listen to feedback from customers. Look at your support call volume, your release bug patterns, and so forth. How is the product perceived externally? How is it perceived internally? Product health will indicate the health of the development team.

Together with your development team, review through your current technical debt load (and yes, you have a current technical debt load!) Try to understand how and why things got to be the way they are.

Hire outside experts to work with your organization. Experts that have achieved similar goals can help you assess your current reality and plan a path toward your goals.

A Last Word

I have worked with highly engaged teams producing software in corporate environments that most would consider bland and depressing. On the other hand, I have worked with teams that are disillusioned and unproductive despite having all the accoutrements of a modern startup.

Development culture has many influencing factors, but its effects on developer engagement and productivity cannot be overstated. If you are a tech leader, I encourage you to engage with your teams and weave conscious intention into your own culture. While difficult, it will be well worth the effort.

]]>http://softwareplusplus.com/2017/01/10/development-culture-do-you-speak-it/feed/0Agile, Tribal Knowledge, and the Trail of Documentationhttp://softwareplusplus.com/2016/12/16/agile-tribal-knowledge-trail-documentation/
http://softwareplusplus.com/2016/12/16/agile-tribal-knowledge-trail-documentation/#commentsSat, 17 Dec 2016 01:49:35 +0000http://softwareplusplus.com/?p=1141When I encounter a software company that claims to be “agile,” I often also hear something like this: “We’re an agile shop. We don’t do documentation because we don’t need to. Documentation goes obsolete quickly.” Right. Whenever I hear such things, there is a part of my brain called the bullshitathalamus that quickly utters some ... Read more

When I encounter a software company that claims to be “agile,” I often also hear something like this: “We’re an agile shop. We don’t do documentation because we don’t need to. Documentation goes obsolete quickly.”

Right.

Whenever I hear such things, there is a part of my brain called the bullshitathalamus that quickly utters some uncharitable terminology such as “Weak. Lame. Lazy.”

Thankfully, I am disciplined enough that my mouth does not usually spew forth in the same manner. Instead, what comes out is more like this: “I respectfully disagree. Meaningful documentation is worth its weight in gold, and it need not be difficult to create and maintain.”

Agile: Dooming Us to Repeat History

While I enjoy the iterative nature of agile approaches to software development, one side effect seems to have been an erosion of disciplined practices. I have personally entered many an agile fray, only to find that the waters of tribal knowledge are cold and deep.

I can understand why. In the absence of turnover, a technical team will gradually learn all it needs to know as iterations progress toward a working (or not working, as the case may be) product. They make good decisions, bad decisions, and bump into enough walls to get a product out the door. They will be just expert enough to complete the tasks, and no more.

Without capturing some of those all-important “lessons learned,” they are simply lessons not learned, and the team’s collective skill is only as good as its own organizational memory.

Ah, but we have user stories, the agile folks say. User stories are completely unsatisfactory for capturing project history. They are usually written in the moment, relevant for a sprint or two, and then they are thrown into a bucket in a tracking tool, never to be seen again. In addition, user stories are usually written by the business or by business analysts – they aren’t used for describing the technical aspects of a software system. I’ve written more than my share of user stories. When I look back over several hundred – or thousand – user stories, I shudder to think of how any poor soul could consume them after the fact.

The Tribal Knowledge Effect

Although it is rarely discussed, and barely even recognized by non-technical business folk in the software industry, tribal knowledge can be very expensive. Imagine hiring five high-powered software developers to take over a hundred thousand line-of-code product after a mass layoff. The business person thinks “Well, they should just pick it up and be productive. After all, they are world-class, and this software stuff is just ones and zeros.” Ones and zeros indeed. Billions are spent to put those ones and zeros in the right order. It can be a very challenging and yet poorly-understood dilemma.

In reality, those five people could be little more than expensive boat-anchors unless there is some serious reverse engineering happening, or unless there is a very standardized framework involved. There are other related penalties such as frustration and product instability – possibly serious defects – while the new staff gain the expertise that is required.

The reality is that building software is complicated and difficult. In my experience, a design decision is made every couple hundred lines of code. That’s an awful lot of historical design decisions over the life of a product. Without the vision of the previous generation of engineers, the knowledge of past decisions, and the trade-offs made for the business direction, the entire ecosystem of software becomes either greenfield or a minefield depending on its maturity level.

Writing is Important

Early on in my software life, I heard someone say “design without documentation is not design.” I heard the words, but I did not know what they meant at the time. As my skills evolved, I noticed a strange thing whenever I would put pen to paper:

The act of writing down my ideas causes a change in my understanding of those same ideas.

When I draw design-ish diagrams, or describe what I am doing in writing, my brain is processing the topic. It is rotating the concepts in different ways as it looks for methods of description. Over and over again, I have found that the simple act of either writing, drawing, or describing technical systems actually improves my understanding, and in some cases, my own decision making.

The usual statement that documentation is worthless simply because it is quickly outdated seems to ignore this point. Not everyone is a great writer, myself included. There are plenty of ways to write, draw, and record that need not be limited by ones writing talent.

As an aside, I have made the same observation about writing tests before, during, or immediately after coding. The code under test will be more decoupled, likely easier to read and understand, and will have a much cleaner interface. I think this is part of the reason I like the evolving microservice trend: the scope of a decoupled service is small enough to where one can truly master it, describe it, understand it, evolve it, and so forth. It is a very fulfilling feeling when that happens.

My Documentation Practices

After all this, you might think that I favor reams of remedial documentation, just for its own sake. But I tend to take a pragmatic view of the topic. One does not need to be a TOGAF expert just to get the point across. Here are the key pieces of my own personal Counter-Tribal Knowledge (CTK) policy.

A Concept Document

A concept document is a concise, no-fluff document that discusses the business purpose of the software, and breaks that purpose down into the major system components, business objects, and relationships between them. When I write a concept document, I try to adhere to commonly understood terminology any avoid injecting any confusing nomenclature (sometimes that means eschewing UML notation as I have mentioned in other posts) or arbitrary redefinition of business terms.

I will often have my work reviewed by someone else, because I will doubtless think it is completely clear on the first revision, yet it is seldom so. I know, Dear Reader, this is difficult to imagine.

Such a document contains consumable block diagrams of the software’s static structure, its deployment architecture, its dependencies, and so forth. Where interfaces between components are critical to success, sequence diagrams are added to help the reader understand what is significant, what is not, and how the interactions were intended to work. A good concept document is an enormous help in ramping up on a new project.

Tests As Documentation

Since I was reared in the military and avionics software world where “proper requirements management” is a Really Big Deal, I have always reached for a close coupling between requirements and system-level tests. When properly done, a solid suite of tests represents the truest description of system behavior outside of the code itself.

I have witnessed first-hand the challenges of requirements management in the commercial world, so I have become a much larger fan of integrating testing directly to the implementation on as many levels as practical, in a noninvasive manner. Modern CI tools and automation support are a terrific help in this regard.

Where documentation management is challenging, automated tests can come to the rescue, because they are the only technically-coupled description of proper behavior. Want to know if your API returns standard status values? Look at your tests. At the very least, existing tests are the first line of defense against regression.

Code for the Reader, Not Yourself

You knew that I would mention code at some point, right? Low-level implementation practices can help reduce tribal knowledge and also hedge against regression, provided some simple conventions are followed. By “conventions,” I mean things like this:

Important classes, interfaces, or algorithms can be augmented with concise, direct comments.

Small README markdown files can be placed alongside the code to explain the reasoning behind certain packages, directories, or components.

Self-describing classes, methods, and functions go a long way to helping someone understand the intentions around the implementation details.

Comments can be placed on database columns. Although I rarely see teams do this, the practice takes very little incremental work, yet it is extremely useful in producing a data dictionary later in the project.

Decoupling of services along domain boundaries will influence the way a new technical staff member views the overall design. This can be a positive or negative, depending on the maturity of the design.

Leaving the World a Better Place

I’ve always left some kind of knowledge trail at every company I have been involved with. Sometimes it is for my own selfish use, because my memory can be short at times. But it means that I leave the organization in a slightly better place than when I started.

As a result of practicing these things, I almost always have some content in place that a new person can use to aid their own knowledge; I rarely have to document a bunch of items at the last minute before my departure from a team. I greatly appreciate it when someone else has shown the same attention on projects that I inherit.

There is no silver bullet to replace professional diligence. Management of knowledge takes creativity and hard work. I have found the results to be well worth the effort.

]]>http://softwareplusplus.com/2016/12/16/agile-tribal-knowledge-trail-documentation/feed/0Can’t Get Technical Talent? Mind the Interviews!http://softwareplusplus.com/2016/11/28/cant-get-tech-talent-mind-the-interviews/
http://softwareplusplus.com/2016/11/28/cant-get-tech-talent-mind-the-interviews/#commentsTue, 29 Nov 2016 03:40:14 +0000http://softwareplusplus.com/?p=1081Imagine this scenario: your company paid a recruiting firm to find candidates for new technical roles in support of your expanding product portfolio. Technical talent is rolling in, your team is interviewing them, but nobody is accepting your offers. You are starting to wonder how this is happening. “We’re a world-class company, with world-class talent ... Read more

Imagine this scenario: your company paid a recruiting firm to find candidates for new technical roles in support of your expanding product portfolio. Technical talent is rolling in, your team is interviewing them, but nobody is accepting your offers. You are starting to wonder how this is happening. “We’re a world-class company, with world-class talent and super interesting problems to solve. Why is nobody accepting our offers?”

A big mistake that companies make when hiring technical resources is in thinking that the interview itself is disconnected from the organization, the culture, the management structure, the current employee pool, and social perceptions. All of these things are interconnected, and top candidates are thinking about all of them. You should too.

In this post, I will focus on some key points in the interview process. Once someone walks into your offices for an interview, the party is just starting and both sides should be prepared to make it a win-win. Here are some ways to do just that.

Be a Good Host

When you bring a technical person in for an interview, don’t walk them straight into the windowless interview room of death. Show them around! If you have an open floor plan, let them soak it in. If you have a cubicle environment, walk them through. This person needs to see, feel, touch, hear the environment in which they would work. If it is a high-energy facility, they may enjoy it. If it is drab, gray, and seems to be where souls go to die – they might actually like that instead. Some people will enjoy your environment and others will not. It’s better that your candidate understands what lies ahead.

I shouldn’t have to mention housekeeping, but it is often ignored in technical interviewing. When the interview starts, make sure the first interviewer ensures that the candidate has water to drink, knows the location of the restroom, and so forth. Forcing someone to sit through through multi-hour panel interviews without a break or without anything to drink is inconsiderate and may cost you a great engineer. The candidate will notice!

Conduct a Self-Assessment

All too often, the normal entry criteria for a technical staff member to conduct an interview with a candidate is: “Have you done technical interviews before? Great. You’re up.” On interview day, the candidate might be passed around like a hot potato, because the interviewers rightfully have other work to do.

I’ve been there and done that, but this is Doing It Wrong. As a candidate, I have been in interviews where the interviewers themselves had no idea how long the interview was; one in which the interviewer was falling asleep; in another, the interviewer gave zero time for me to ask questions; in others, it seemed that the only thing the company found interesting about me was my ability to extend a ridiculously impractical interface to perform an academic exercise that I would have Googled in 5 seconds. Not impressed.

Whoa. Let’s think about that. The interview process is the first deep exchange a candidate has with an organization. At a minimum, the hiring manager should be aware of precisely what is happening in interviews. It all starts with transparency. Here are some ways to get direct insight into the practice on the ground:

Put a camera in the room to observe the interviewers. This might be a bit Orwellian for many.

Have your most charismatic and engaged interviewer assume a temporary additional responsibility of assessing the other interviewers as well as participating in the process. This person would follow up directly with the hiring manager or other accountable folk afterwards.

Bring in an outside consultant who specializes in tech interview effectiveness, and have them audit the process as a neutral third party.

Once you step back and observe the real process in action, you will almost always find some room for improvement. Did your interviewers seem organized? Were they able to communicate the organization’s direction? Was the interview tense, or friendly? There are many subtle nuances that are only revealed through direct observation.

Educate Your Interviewers

You should not assume that your staff know how to interview people simply because they have done it somewhere else. Some interviewers love to sit down and talk. Others do not like to interview at all. Some like structure, some prefer free-flowing discussion. Would you want to have your most potent tech evangelist in the interview? What if that person also enjoys steamrolling other opinions and initiating conflict? Would you want to involve your quietest introvert, who produces great software but does not like to field questions? If you make a point to sell candidates on your engineering culture, would you want a recently-added staff member fielding detailed candidate questions on whether your culture is effective?

Ideally, your interviewers would have a planned and coordinated plan that is tailored to the hiring goals of the organization. An alert candidate can detect unprepared interviewers and misaligned goals.

These are simple elements, but when they are not present, they can add up to a negative first impression. It might be the only direct impression the candidate has; the others might come from Glassdoor. Depending on how your company engages with outside social sources, the interview process may have the added obligation to counter outside perception. Are you prepared for that?

Follow Up Quickly…

It has been my experience that follow-up is frequently non-existent or ignored. This is most unfortunate, because following up quickly and directly is a great way to learn something important about your own organization, and to make someone feel that yours is an upstanding company regardless of the interview outcome. Be honest, polite, but be timely. Waiting two weeks to give feedback? The candidate might have already moved on, and may have forgotten the name of your company. Perhaps in that two week period, they’ve already posted their experience online.

…And Directly

If you extend an offer and it is declined by the candidate, you should try to find out why, in as direct a manner as possible. Direct feedback is important.

As an example, say your business has some analytics problems that require machine learning skills in-house. You interview three machine learning specialists (who normally have either advanced math, physics, or stats skills, or very niche tech skills, or all of the above.) All the candidates turn down your offers. Your recruiting partner gives you watered-down feedback about the underlying reasons, but when you call the candidates directly, you hear that none of these highly skilled specialists want to sit in the noisy, boisterous, open floor plan that you thought was a stroke of genius for your millennial UX designers. Now, will you create a dedicated area where the machine learning team can sit and ponder those difficult problems in relative quiet? Unless you asked for feedback, you might never know the root cause, or how to address it.

When you talk to candidates that have gone through the interview process, ask about the high points and low points from their perspective. Ask about the candidate’s experiences and feelings about the interactions with your company. Listen to what is said, and what is not said. These things are probably already being discussed between the candidate and his or her own colleagues, so it stands to reason that there is some value to be gleaned from the insight. It might be surprising, inspiring, or perhaps frightening – but in all cases, it is new information to use.

Look in the Mirror

The elephant in the room is the health of your development organization. In an interview situation, the candidate is trying to get a sense of what is really like to work in your structure, with your people, and under your leadership. Despite your own biases and assumptions, it’s about what the candidate can perceive in the process. If your development culture is orthogonal to the skills you are trying to hire, you have a problem. A candidate that does his or her homework might be able to discern this during the interview process. You certainly would not hire candidates that don’t do their homework, right?

I’ll talk about development culture in a future post, but if there are serious problems in the organization, the interview process could be signalling it for the world to see.

And Finally…

I encourage you to take an objective look at how technical candidates might perceive and interact with your company. Their perspective could reveal fertile ground for improvement.

]]>http://softwareplusplus.com/2016/11/28/cant-get-tech-talent-mind-the-interviews/feed/0Passion, Startups, and Softwarehttp://softwareplusplus.com/2016/04/13/passion-startups-and-software/
http://softwareplusplus.com/2016/04/13/passion-startups-and-software/#commentsWed, 13 Apr 2016 14:46:42 +0000http://softwareplusplus.com/?p=1034There once was a wonderful dog that my grandmother had many years ago. His name was The Fox due to his arguably fox-like appearance. The Fox loved to go for car rides with my uncles and I. When we returned to the back alley behind my grandmother’s house, it was something of a ritual to ... Read more

There once was a wonderful dog that my grandmother had many years ago. His name was The Fox due to his arguably fox-like appearance. The Fox loved to go for car rides with my uncles and I. When we returned to the back alley behind my grandmother’s house, it was something of a ritual to let Foxy out of the car so that he could run the rest of the way. Anticipating the opening of the car door, The Fox would launch like a rocket, his legs all but completely invisible under him. He would tear along that alley with such intensity and speed that it would make Usain Bolt proud. He would effortlessly beat the car back to the house, then wait expectantly for us to catch up. Watching The Fox run was an exhilarating experience by itself; in those moments, it seemed like he had thrown off his earthly shackles and did what he was born to do.

For the past few months, I have been fully and completely immersed in a local startup company called IrisPR. So far, the experience has been a tremendous opportunity to learn some new lessons and build something interesting.

This startup experience has been very similar to the run of The Fox. It is both refreshing and exhausting; inspiring and scary; a glorious channel for letting my passion for building things run free.

Being something of an introspective person, I wondered about this. I am considered by my peers to be someone that typically puts a lot of energy into their work. That said, it had been a long time since I felt great being so deeply immersed in it. The last time I remember feeling these things about building software was between the year 2000 and 2002. Yes, that is quite a few years back, possibly an entire career span for some.

Having this realization, this leads into some key questions: what specifically is it about a startup that helps me engage in this manner? Why don’t typical corporate software gigs tend to do that?

Much has been written about these things, and but it still seems like a nebulous topic in the tech world.

In thinking deeply about it, I believe I finally identified some answers, at least for myself.

Identification with a Goal

I have built software in companies that had tremendously unclear goals. Upon reflection, these companies all had a similar trait on the technology side: they had weak technical leadership that clouded the high-level corporate vision and made it more difficult to translate goals into something meaningful at an execution level. This weak technical leadership was nearly always in one of two forms, sometimes both:

an “accidental CTO” – meaning a CTO that holds the title, but is not a technology person and has no true understanding of it or those who practice it.

layers of similarly non-technical middle management.

These two items, even with the best of intentions on each individual, often obfuscate the meaning and contribution of tech to the business objectives.

In IrisPR, the team is small enough and the goal is clear enough that everyone gets it. There is plenty of naturally intense conversation around the details, but there is no confusion around the mission. When I can clearly understand the goal, I feel like I can bring more sharp focus to my work. That focus brings the tremendous thrill of perceiving the value of my work.

Of course, it also helps if the goal is something interesting, big, or challenging. Changing the world is a far more appealing objective than making someone rich.

Team Integrity

There is no shortage of personality in the technical realm. My dear readers have probably worked with A players and B players, or perhaps even transitioned from one to the other under certain conditions. There are drama queens that like to hold the business hostage to their technical prowess. There are one-trick ponies that hang their hat on one specific technology, even if it does not fit the problem they are solving. Not everyone can or will contribute the same way, and in the same amounts. There is nothing inherently wrong with these things, but I find that my own engagement can be more challenging to sustain when there is a lot of drama, or when there is no sense of community in the team.

The IrisPR team is a small, smart, motivated, supportive group. There is a feeling of responsibility for each other that is openly encouraged, whereas artificial drama is not. Open discussion is the name of the game, and elephants in the room are addressed directly. Everyone is in it to see it succeed. For me, this sense of teamwork is a theme that I find highly motivating. I don’t want to let my teammates down, whether that means fixing bugs for the customer support person, or automating some dreary task that is unnecessarily consuming someone’s time. My team between 2000 and 2002 had this same feeling.

Decision Making

Another big factor that ignites me in a software role is the feeling that I have a voice in the decision making of the company.

I’ve been in plenty of organizations that would ask for information or decision support from technical players, only to see it summarily dismissed for a variety of reasons. When this happens frequently enough, the technical players will tend to think that their input has no value, and eventually they will disconnect in order to protect themselves against this feeling of worthlessness.

At a small startup, this would be a dangerous situation. Both sides must realize that they need a deep commitment to each other, and to the overall goals in order to make things work. This is similar to a personal relationship from the standpoint that each side must enunciate their position with the company goals in mind. They must respect and honor the views of the other, and find a way forward together – or part ways, as the case may be.

What About Money And Those Other Things?

Many startups that try to build a technical team tend to fixate on the only levers that they perceive as being under their control. The usual candidates are money, benefits, equity, and so forth. Some companies like to supply free breakfast, convenient transportation, and the list goes on.

The way I see it, the benefits such as health care are required to come to the party at all. Salary has to cover my bills and allow me to live a life, perhaps to retire one day when I stop enjoying this work so much. Yes, more money is better, but that is not where the passion comes from. Free breakfast, foosball, or beer in the fridge? Nice, but I really don’t care much about those things. I’m here to build stuff.

Passion, Manifested

When the elements I described above come together in the right way, I find it much easier to get fired up about solving problems. When I am in this mode, I engage with my mind, my heart, and my soul. My creativity level is much higher, and it can appear at the strangest times. Sometimes I dream of solutions to problems, other times a solution will occur to me while doing mundane household tasks, doing some athletic endeavor, or playing music. There is a level of drive and intensity that is more pronounced. During these times, I think back to The Fox and hope that I am doing it with the sheer joy that he did.

]]>http://softwareplusplus.com/2016/04/13/passion-startups-and-software/feed/0Managing Your Managerhttp://softwareplusplus.com/2015/12/31/managing-your-manager/
http://softwareplusplus.com/2015/12/31/managing-your-manager/#commentsThu, 31 Dec 2015 19:13:15 +0000http://softwareplusplus.com/?p=969Ok, this is my last post of 2015. For those keeping track: yes, I fell off the wagon in November and most of December. Something about taking a new position that requires a rather high level of output and time-on-task. But I digress. I’ve written previously about the perils of focusing on technical skills at ... Read more

Ok, this is my last post of 2015. For those keeping track: yes, I fell off the wagon in November and most of December. Something about taking a new position that requires a rather high level of output and time-on-task. But I digress.

I’ve written previously about the perils of focusing on technical skills at the expense of other skills. This topic is one of those “other skills” that can make a tremendous difference in the evolution of your career. In my view, there are times when this particular skill can be more important than your technical chops.

I invite you to ponder this question:

Are you aligned with your manager?

Do you actually know how your manager sees your contributions? Does he or she know what you do in a day? Do you know what your manager’s pain points are? How do you know if you are really adding value to your organization? Should you be more transparent than you currently are? Should you pay attention to activities that you aren’t even aware exist?

In the context of a small startup in which you physically sit close enough to your boss that you can hear his or her Pandora station, these questions might seem unimportant and the answers might seem obvious. But if you are in a larger company, your manager might have fifty other people to oversee. Perhaps your manager isn’t even in the same country. In extreme cases, you may never meet your manager in person. This might be hard to imagine, until you experience it.

In reality, it is very easy to fall out of sync with your organization’s management, while being totally unaware that it is happening.

What is Managing My Manager?

Managing your manager does not mean you become your manager’s boss for a day. It involves spending some time and energy understanding things from your manager’s viewpoint, then adjusting your own behavior to ensure that you both have a productive working relationship.

The ability to manage one’s manager is a very important skill in any company. It becomes especially crucial in companies where your direct manager can make or break your career trajectory.

Done right, managing your manager makes working life a bit easier on both of you. The side benefit is that you will start to understand that there is a different way to interpret and measure the value of your work. This in turn can open doors that you were previously unaware of.

How To Start Managing Your Manager

In my experience, one of the best ways to align your own day-to-day habits with your boss is to ask how he or she would like to work together.

It’s that simple. Just ask.

For example, when I start a new role at a company (assuming I didn’t already ask during the interview process), I will ask my new manager something like this:

“I’m coming here from other companies, each with their own ways of doing work, so I would like to understand how we should work together, from your perspective.”

Normally the reaction to this question is something like “wow, nobody has ever asked me that before.”

Once that novelty passes, this question usually leads into a conversation that covers some very important elements from the manager’s point of view. Things such as the manager’s pain points, and whether my work can have an impact on those pain points. I will probably learn about the manager’s need for transparency – including how often, and in what form, project status is gathered. I might also learn about how the manager relates to the rest of the organization’s power structure. In the best cases, I leave the conversation with a better understanding of what it means to be “successful” in the context of the organization in which I work.

If you have not guessed it, this information is gold! And it can be yours for the asking! Let’s look at some examples where your alignment with your manager can be very useful.

Out-Micro-ing the Microboss

A common example is the case of the infamous micro-manager. You know, the one that stands in your cubicle at 4:30PM every day asking you for a status, even though you had a standup at 9:00AM that same day, and there is another one tomorrow.

If you had the previous discussion with your manager, you might already know that this manager needs to report status to his manager at the end of the day. So, if you agree with him that you will send a status report by 4:25PM, then he may have no reason to visit you in your cubicle. Just fulfill your end of the bargain, so that he can fulfill his.

Like magic, you have just taken a step into the world of managing your manager.

Solve Organizational Problems for Fun and Profit

As another example, say your development team has a friction-filled relationship with your dev-ops team, resulting in political fireworks from your manager’s standpoint.

If you are aware of this dilemma, you could actually take the initiative to build a helpful personal network over in the dev-ops team, or perhaps automate away some technical issues that might be increasing the hard feelings between the teams. This sort of work will reflect positively on you, and quite possibly your manager as well. Another benefit: this is a free way to grow your own organizational network!

Become Great at Selling….Your Ideas

There is a quote allegedly from Teddy Roosevelt: “Complaining about a problem without posing a solution is called whining.” Problems and challenges come with the territory in management life. It is often a breath of fresh air when someone comes in with a problem coupled with some well-reasoned suggestions for addressing it.

Understanding how your manager views problems and solutions can help you craft better ways to convince him or her to let you take a shot at solving them. This skill comes in awfully handy when you want to pitch your own ideas. When I initiate a conversation like this, I normally like to have two alternate solutions ready for discussion, or better yet, a working demo of a potential solution. This shows initiative and makes it easy to convince a manager that I should be involved in implementing the solution.

Summary

By now, I hope you are getting the idea that understanding your manager’s viewpoint can add a new dimension to what you thought was the value of your own contribution. I have personally used the approaches above in a variety of situations that otherwise would have resulted in very negative outcomes.

There are some understandably cynical beasts in the software world that view this sort of skill in a less than favorable light, so I will clarify here. I’m not trying to make a case that you become the manager’s pet, babysit their children, or kiss the posterior of each and every manager in your career. I am suggesting that one should make efforts to understand how one’s own value is measured from management’s perspective, and use that understanding to discover new opportunities to improve and develop of one’s own skills. It does not mean a compromise in principles.

There is the added incentive that the most cynical of these aforementioned beasts have probably been sitting in the same cubicle at the same company, or in the same position, for a very long time. Think about what happens if you don’t adopt some of these skills. You assume that whatever you happen to be working on will meet with your manager’s approval in that once-a-year performance review. You assume that the manager will ask you when he or she needs a status. You will wait to be handed work to do. While there is nothing inherently wrong with this, it is not a philosophy that lends itself to steering the ship of one’s own destiny.

Think about these things the next time you feel that wholesome, well-intentioned eagerness to stampede off to the keyboard and throw down your next piece of legacy code. Perhaps there are more ways for you to inject value into your organization.

]]>http://softwareplusplus.com/2015/12/31/managing-your-manager/feed/0Mindfulness For Zombieshttp://softwareplusplus.com/2015/10/31/mindfulness-for-zombies/
http://softwareplusplus.com/2015/10/31/mindfulness-for-zombies/#commentsSun, 01 Nov 2015 00:00:52 +0000http://softwareplusplus.com/?p=926Trick or treat! Almost everyone has seen zombie movies or shows. Almost without exception, the zombies are portrayed as unthinking beasts, satisfying their primitive instincts by preying on the living. Fun on Halloween, but rather apocalyptic and scary otherwise, right? Another way to think about zombies, is that they are incapable of higher thought. They ... Read more

Almost everyone has seen zombie movies or shows. Almost without exception, the zombies are portrayed as unthinking beasts, satisfying their primitive instincts by preying on the living. Fun on Halloween, but rather apocalyptic and scary otherwise, right?

Another way to think about zombies, is that they are incapable of higher thought. They are one-trick ponies, feeding and moving from one victim to the next. Completely on auto-pilot. Conscious, but probably only in basic parts of the brain, like the cerebellum and the hypothalamus. If we were to burrow into the zombie brain, we might hear the single repetitive thought “Eat…..eat…..eat….”

I find it fascinating that for all our modern living and our advanced technology, we still struggle with living life on auto-pilot, just like zombies. Ironically, most people aren’t even aware that they are doing it. Ever had a day where you arrive at work, but you don’t remember anything about the trip? You were on auto-pilot, just like a zombie.

The Zombie Thought Stream

I’m talking about our unwitting association with the mostly-repetitive conscious and unconscious diarrhea that constantly swarms around in our brains. You might recognize some of these:

something nasty our parents said to us 25 years ago

“What do I need to do today?”

“How am I going to handle these a******* this afternoon?”

a song, playing over…and….over….

some insecurity that we are aware of and are afraid of revealing

some regretful thing I did last week

All of these things are simply repetitive mental noise. Some people refer to it as the “thought stream” which I always thought was an apt description for it.

This stream of mental noise is so common that most of us just accept it as The Way Things Are. This is reflected in the powerless speech that people often apply to their own mental processes: “It’s the way I am,” or “I can’t control it.” For example, I commonly hear people who are looking for relationships say “I’m looking for someone that makes me happy.” It is as though they are totally unaware that happiness must first start within. This assertion would be foreign to them, because they are simply processing their own thoughts in their own world, unable to see beyond it.

The unfortunate part is that when you are so tightly wrapped up in this vortex of nonstop mental noise, it owns you. You become its puppet. You act the way your mental tapes act, the way you historically trained yourself to act. Eckhart Tolle once talked about this as the antithesis of the mind as a tool: the mind is using you, rather than the other way around. I found it to be a powerful analogy.

I can completely identify with dilemma, because I lived precisely the same way for the first thirty-five or so years of my life. Then something triggered a change, and I had to learn a different way to live, or die trying.

For myself, this meant noticing how I related to my surroundings. I did plenty of self-discovery. I worked on creating and adhering to personal boundaries. I learned how to forgive myself for not being perfect(!) I cleaned up some bad habits. I dug deeply into a personal meditation practice. It was a painful and difficult transition from my former zombie state. It’s a constant work-in-progress, since I still have some pockets of zombie-ness. But I would never want to go back to full-time zombie.

As a side effect, I now notice zombies in all walks of life (no, not the flesh-eating kind…) Sometimes I can help them realize when they are in a zombie-like state, and sometimes I cannot. Sometimes they remind me when I am in a zombie-like state. I also see it in my colleagues around the office. This is spectacularly interesting in people that work in knowledge activities like software or information technology, because the roles are so abstract, and such value is placed on high-functioning mental capacity. However, even for all that mental horsepower, the problem remains.

A Mindfulness Exercise For Your Inner Zombie

One reason that I enjoy introducing people to meditation is to observe how (or if) they arrive at the realization that it is actually possible to separate consciousness from their thought stream. One of the exercises that I enjoy is a counting exercise involving the use of a pitch counter. You know, one of the old mechanical “clickable” counters. It looks like this:

The exercise is as follows. You sit by yourself in a quiet place and try to listen for your own mental processing. With each thought you can recognize, click the counter. One click per thought, please.

A bit of protocol here. During the exercise, you are not to judge your thoughts. You are not to punish yourself for missing thoughts, nor for the content of your thoughts, nor to analyze yourself. Just sit there and click. One click per thought. This is part of the reason I like a mechanical device for the exercise. It is very tactile.

This exercise can be very tough, particularly for analytical people such as engineers. There seems to be a tendency to regard such an exercise as something that should have a project plan attached in order to be considered valid. This analyzing is something to be compartmentalized away for now.

The goal of the exercise is to simply build the recognition that you can, in fact, watch for your own thoughts. The goal is definitely not to check out your score on the counter. That said, in my experience, everyone who does this exercise seems to find entertainment in looking at their count. With some practice, you can become very adept at recognizing when you have thoughts. For those of you who are into meditation, you probably know where this eventually leads. However, I will not cover that here. Back on point.

“So” you might ask, “what does this exercise have to do with anything anyway?”

Think of it this way. When you are clicking this mechanical device upon each conscious thought, consider that the part of your mind that is recognizing your thoughts is actually separate from your thought stream itself. Otherwise, you would be getting constantly distracted and you would not be clicking very much, if at all! In effect, the idea is for you to become the observer of your own thoughts.

That’s a really, really big deal. I don’t think Zombies have this ability.

At this point, you might start to realize two key things: a) your thought stream exists, and b) you are capable of a consciousness that exists outside that thought stream.

Wow! Ponder that last one.

Yes, it is ironic that I ask you to ponder that, in your mental thought stream. But just consider it. What exactly is that “other consciousness” that was clicking the counter that whole time, if that was not part of your thought stream? Does this mean you don’t actually have to exist in your thought stream at all times? I invite you to consider this deeply.

For me, that second realization was, pardon the pun, mind-blowing. It was a small opening in the doorway to a non-zombie existence.

]]>http://softwareplusplus.com/2015/10/31/mindfulness-for-zombies/feed/0Timing, The Bane of My Existencehttp://softwareplusplus.com/2015/10/30/timing-the-bane-of-my-existence/
http://softwareplusplus.com/2015/10/30/timing-the-bane-of-my-existence/#commentsFri, 30 Oct 2015 17:00:51 +0000http://softwareplusplus.com/?p=917Ever heard the phrase “timing is everything?” Well, for me, timing is often an ironic way to expose bugs, illustrate worst-case scenarios, and just generally turn everything into a test of my own resolve. C’est la vie, I guess. Case in point: as soon as Steve Vai posted the link for his interview with my ... Read more

Well, for me, timing is often an ironic way to expose bugs, illustrate worst-case scenarios, and just generally turn everything into a test of my own resolve. C’est la vie, I guess.

Case in point: as soon as Steve Vai posted the link for his interview with my friend Anthony from Make Weird Music, my former hosting service took a horrible nose-dive. So, I am currently running a two-month old backup on Bluehost with some help from their WordPress support guys (thanks, Bluehost!).

Update: as of 10/30/2015, I think I have recovered everything at this point, so if you notice anything missing, leave a comment or send me a note.

The guitar pictured above is a custom from an Arizona builder called Mudd guitars. I was dumb enough to play this work of art on stage instead of just framing it, like it probably deserved

]]>http://softwareplusplus.com/2015/10/30/timing-the-bane-of-my-existence/feed/2Vertical and Horizontal Iterationshttp://softwareplusplus.com/2015/10/15/vertical-and-horizontal-iterations/
http://softwareplusplus.com/2015/10/15/vertical-and-horizontal-iterations/#commentsFri, 16 Oct 2015 03:36:15 +0000http://softwareplusplus.com/?p=846How many times have you heard something like this? “We’re an Agile organization. We have two-week sprints!” I’ve heard it so many times, I don’t even react to the claim. It is usually a case where the proof of the pudding is in the eating. Truthfully, I really like the intentions behind the Agile movement. ... Read more

How many times have you heard something like this? “We’re an Agile organization. We have two-week sprints!”

I’ve heard it so many times, I don’t even react to the claim. It is usually a case where the proof of the pudding is in the eating.

Truthfully, I really like the intentions behind the Agile movement. Whenever I am faced with projects that are in real trouble, I implement Agile-esque tactics without thinking about it within the context of any particular method or framework: I remove all unnecessary overhead, streamline all technical communication and closely involve stakeholders, co-locate teams into a “war” room, focus on delivery of proven incremental value, and so forth.

Arguably the most significant point of the Agile manifesto was, in my opinion, the idea to build software in small, functional, incremental pieces. When compared to old-school waterfall-ish approaches where one is presented with an enormous scope captured as requirements that nobody fully understands, or a massively engineered architecture that is thrust upon a development team, it seems clear that the incremental approach is a more realistic way to solve problems.

With that said, I’ve worked in enough so-called Agile shops to have noticed a common challenge that frequently seems to present itself.

This challenge has to do with understanding what ‘iterative’ really means, and what functionality actually makes sense to deliver in an iterative manner.

Vertical Iterations

Let’s imagine a simple example. Say a business wants to build a stereotypical software product that processes orders, tracks inventory, and handles shipping (I will refer to these as “functional areas”.) When a product owner and a business analyst get together to lay out the project dimensions, they might decide to build inventory management first, followed by order processing, then shipping. This seems to make sense, simply because there is a relatively clear conceptual boundary that even a layperson could draw around each functional area. Literally, it could be thought of in terms of the diagram below:

These conceptual boundaries, in turn, directly promote a rightfully attractive idea about how to plan the actual work. It would seem clear that three parallel teams would work in this case. So, our product owner and business analyst decide to staff some software teams, sketch out a backlog, and get started. I think of this method as a “vertical” approach, because the functional areas are implemented to their highest form in independent and vertical “slices”. The iterations cover “vertical” functionality in chunks, which I mentally imagine like so:

This is a very common approach, and it is frequently viewed as optimal by software management and those in the planning domain. After all, look at the parallelization being achieved! It’s like a free lunch! Fred Brooks, eat your heart out! As an added measure, it is increasingly common that the teams are located in a different geographical areas, purely for cost-saving purposes.

On the surface, this all sounds well and good.

However, reality on the ground can be very different. There is often no holistic architecture from which to work. The implementation teams often don’t communicate effectively. Concepts that should be common across functional areas are often poorly understood at an overall level. Contracts between functionality that should be carefully reviewed and managed are instead produced at the last minute and left to evolve with little oversight and little to no change management. All this results in preventable bugs that ripple across functional bounds, thus impacting the stability of the entire system.

Certainly these three functional areas could be built as something like compositions of microservices, avoiding challenges related to shared domain models and other monolithic infrastructure. If each team implements sensible oversight policies, and are self-aware enough to coordinate with each other early and often, such a development model can certainly be successful.

In any case, the involved development teams will usually end up specializing in each of the functional areas. This is what I commonly refer to as “development silos,” and it is a common enough situation to have its own informal law. A silo-like ecosystem can be extremely risky to a business. A technical person could not move from working on the inventory system to working on the shipping system without a steep learning curve. Suppose a competitor hires away most of the engineers and analysts on the order processing team. Now the company has nobody left who understands either the original design, or the problem space in general. Ouch.

There is another way to approach the same scenario.

Horizontal Iterations

Given the same set of functional areas, a technical person might point out that there may be a common domain model that underlies all three functional areas: the order processing domain would have to either integrate with, or at least share part of a model with the inventory domain, which in turn must have a common (or derivable) definition of what makes a ship-able entity for use by the shipping system.

This point of view is more horizontal, rather than vertical: we imagine building the system horizontally – meaning, across the domains – rather than building each domain in relative isolation. Within a single team, build the absolute minimum functionality to process an order, then build the minimum necessary to calculate the order processing system’s impact on inventory, followed by a rudimentary shipping system. I think of such an approach in terms of cross-cutting iterations, successively moving to higher levels of abstraction as system functionality becomes more elaborate and functionally mature. I picture it like this:

From the diagram, each iteration is essentially augmenting the bare-MVP functionality of the previous iteration. Perhaps it takes a few initial iterations to really get the functionality moving; perhaps the system does not demo very well in early iterations. Yet as the functionality evolves, something very interesting is happening: the implementation team is learning holistically! The team learns that an order processed means a possible change in inventory; they understand that out-of-stock should possibly prevent ordering. The team is also learning the key concepts and limitations of the business domain. In other words, the team is building a broad understanding of the problem space, and the dependencies of the system functions. It also means the team members have more portable skills and are better prepared to understand system-wide ramifications of their own decisions.

I believe this natural evolution of teams deepening their understanding of their solution domain while building the solution, is a very important benefit of an iterative model. This aspect seems to be often overlooked.

In fairness, the horizontal approach is not a silver bullet and is certainly not without its challenges. I sometimes find that the horizontal approach seems difficult for deadline-driven or Type A personalities, possibly because they feel more confident in their projected outcome when a particular function is complete to a “sale-able” degree. I’ve done plenty of damage control on projects where the leadership was uncomfortable (to the point of passionate objection) with a horizontal approach, simply because they tend to dangerously equate the ability to demonstrate the software with the actual software product itself. Hybrid models can be explored, for example, involving horizontal iterations within slices, and rotations of development expertise between the domains.

Planning the actual content of iterations in a sensible way can be a deceptively difficult problem. Whether a given approach is “right” or “wrong” is sometimes only clear in hindsight. While every organization differs in their ability to choose and execute such models, I usually find the common denominator in the selection of a model that the business alignment and development culture can both support.