Employee and Business Alignment

In a recent Cutter Consortium post Vince Kellen explores what happens when employees are, and are not, aligned with their roles.

I've personally struggled with roles that weren't feeding my goals and passions. The post got me thinking about the larger picture where coworkers are struggling as well.

Some interesting points:

...I have seen all sorts of misalignments between bag A (personal skills, personal ambition and passion, level of effort) and bag B (current work role, future role I would like, my role in society and in this company overall). My sense is that these misalignments are endemic in all work places and are part of the human condition. I also know and have seen, however, that when a personally aligned team is aligned well in the organization, big things happen. These individuals and these teams tend to share a common attribute: a whole lot of heart. They are capable of giving more — much, much more.

When someone knows well what they are legitimately good at and what they can truly excel at, and when they are deeply passionate about all of this, watch out: anything can happen. These individuals work better and faster, produce better results, and, better still, because of their confidence, tend to work well with others. These people are often the glue that holds the place together. As others around them spin a bit out of control in misalignment or, worse, bust apart like a sliced golf ball, they tend to be a calming influence. These aligned people are intrinsically motivated and, like a gyroscope, stand on their own, more easily absorbing the slings and arrows of outrageous fortunes.

Hiring and Programming

A post at developerart.com about hiring and programming had me engrossed. It's comprehensive and elicits both macro and micro thinking. I really liked this description of why we write software:

Besides, coding is not really the ultimate goal. We're not here to write the breathtaking code. We're not here to explore all of the hidden gems of some technology. We're not here to design a perfect bullet-proof architecture to accommodate for any future requirements in the next 50 (better 70) years. We've gathered together to develop software, to create a product, to solve specific problems and satisfy customers....One has to be able to simultaneously exist in several dimensions. In code when we're programming. In the needs and requirements we're programming for. In the mind of the users whose requirements we're putting in code. And also think of many other social, marketing and organizational aspects. Beyond code there are business processes, certain user experience. Don't forget usability. One has to see the big picture to excel. That special skill is however very difficult to check for when interviewing a candidate but it may happen to be even more important than coding skills or the advanced all-penetrating knowledge of the technology in use.

Quote of the Day

Pay special attention to how a project begins because that's where the design tree is rooted. Right at the beginning is the easiest place to slip into major false assumptions, so learn to develop the habit to scrutinizing your starting point. - Donald C. Gause and Gerald M. Weinberg in Exploring Requirements: Quality Before Design

Don't Call Yourself A Programmer, And Other Career Advice

Good software development career advice from Patrick McKenzie, who blogs about the business aspects of running a software company. Wish I had this 20 years ago!

Some points I like:

Most software is not sold in boxes, available on the Internet, or downloaded from the App Store. Most software is boring one-off applications in corporations, under-girding every imaginable facet of the global economy. It tracks expenses, it optimizes shipping costs, it assists the accounting department in preparing projections, it helps design new widgets, it prices insurance policies, it flags orders for manual review by the fraud department, etc etc. Software solves business problems...despite being soul-crushingly boring and of minimal technical complexity...it only matters that [the software] either saves the company costs or generates additional revenue.

Businesses do things for irrational and political reasons all the time, but in the main they converge on doing things which increase revenue or reduce costs.

The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs. Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.

...describe yourself by what you have accomplished for previously employers vis-a-vis increasing revenues or reducing costs. If you have not had the opportunity to do this yet, describe things which suggest you have the ability to increase revenue or reduce costs, or ideas to do so.

When Will the Project Be Done?

Johanna Rothman provides an interesting perspective on estimating in But I Need to Know When the Project Will Be Done.

Like Johanna, I believe that time is better spent adding value, rather than producing estimates that are consistently wrong. The post leads off with a humorous and all-to-common conversation that highlights the problem with up front estimates:

Have you been able to [provide a perfect estimate] before?

No.

Do you think you can get a perfect estimate this time?

No.

Then why would you spend your time doing an estimate instead of producing something, learning from that and bettering your gross estimate?

Because my manager needs to know when the project will be done!

OO and Creating Changable Systems

Inevitably, a valuable system is forced to change. The system is altered, again and again, to provide additional value. This altering takes the system in directions that were not envisioned when the system was created.

Given that OO development is well suited to dealing with the inevitable change, why are so many organizations not harnessing the power that OO provides for creating these changable systems?

Could it simply be ignorance? A lack of knowledge and training? Underestimation of the paradigm shift needed to truly understand and implement OO systems?

In future posts I'll elaborate on the tenets that make up the basis of my understanding of OO development:

1. Encapsulation
2. Low Coupling
3. High Cohesion
4. Separation of Concerns

The Soul of a New Machine

If you're interested in what it takes to create technology, take a look at The Soul Of a New Machine by Tracy Kidder, a book that chronicles the trials and tribulations of creating the next generation computer. The author provides good rhythm and the right mix of human and technical factors. The suspense builds throughout the book and I was invested in the outcome: Will they finish? Will it be a success?

Even though the book was written in 1981, the rich descriptions of what goes on in a high-tech company are still accurate. Some common themes detailed in the book are time constraints, technical debt, complexity, chaos, attrition and turf wars.

I really liked the areas that focus on estimation and deadlines. Some passages that I recognized:

West and his staff had created the deadline of April and, in the act, had agreed at least to pretend to take it seriously. Many months later, Carl Carman would say that no one upstairs believed they would finish Eagle that soon. Some evenings downstairs, West seemed to say the same thing. "We're gonna finish this sucker by April, Alsing," he'd say. "Yeah, Tom. Sure we are," Alsing would reply. They'd smile at each other.

It's sort of a poker game. Everyone's bluffing, but everone seems to know the rules of the game...

"We went with an imperfect design," said Rasala. "We knew we were pushing it." So his schedules slipped and slipped, and slipped again. "the way to stay on schedule," he said, "is to make another one."

Logging Contrarian

I'm a logging contrarian. Instead of each object declaring and using its own logger, I'd rather have objects that just expose formal notifications to the outside world. The objects shouldn't be concerned about how the notifications are presented or consumed. To me, this is just basic separation of concerns.

Steve Freeman has a couple of great posts (here and here) that provide collaborating information and ideas. I especially like his take on support vs. diagnostic logging and logging design:

The idea of encapsulating support reporting sounds like over-design, but it's worth thinking about for a moment. It means I'm writing code in terms of my intent (helping the support people) rather than the implementation (logging), so it's more expressive. All the support reporting is handled in a few known places, so it's easier to be consistent about how things are reported and to encourage reuse. It can also help me structure and control my reporting in terms of the application domain, rather than in terms of java packages. Finally, the act of writing a test for each report helps me avoid the "I don't know what to do with this exception, so I'll log it and carry on" syndrome, which leads to log-bloat and production failures because I haven't handled obscure error conditions.