Today we have a guest editorial from Bill Nicolich as Steve is on vacation.
Many people have worked hard to help explain why software/tech projects go right and wrong. Some of the available material touches on the impact of people's perspectives - i.e. how people look at things. Here, I look closer at one particular perspective: what counts as work. I'm looking at what counts at work in the minds of various people who affect the outcome of projects. I argue that this particular perspective deserves special attention and that those who pay attention to what others think about it can gain insights and advantages.
Another way to say it is we should be thinking about what counts more and what counts less as legitimate work on projects. Of the many perspectives and attitudes, I should explain why I think this one is important. In short, this perspective affects the "incentive ecosystem", which in turn greatly determines the fate of projects. I'll explain more below.
There are already lots of factors that threaten the success of team-based design projects. There's the lack of resources. There are turf wars. There are hidden agendas. Now imagine that key people don't see the value in doing things that are crucial to the success of projects. Add that to the mix, and one can imagine how vital it is that important activities are valued.
The perspective matters because people take the answer of what counts less and what counts more as legitimate work as a guide for what they should shift their focus to and away from. Sometimes that shift of focus can have grave hidden consequences.
Imagine that I create a software job with a set of responsibilities - all of which are needed and important. I tie general incentives to the whole set and hope that each element will be handled well. This is the basic mechanics of most jobs. But somewhere along the way, I start sending signals about the extra importance of one or two responsibilities, and I rarely, if ever, talk about the other responsibilities. Imagine that I frequently send reinforcing signals about the act of writing code but never about planning, documenting, collaborating, deciding, reflecting or learning.
If we apply the general truism that people tend to respond to incentives, then what could we predict will happen over time? Plenty of code will get written and the other activities like planning, documenting, collaborating and so forth will tend to get neglected - potentially to the point of disaster. This can lead to unsustainable levels of technical debt, unmanaged risk to important technical assets and disorganization at several levels - the level of code, project, solution portfolio, technical environment and so on.
How often has it happened that someone walks into a technical environment only to find astonishing disarray everywhere, and then this person wonders, for the love of humanity, how things could have gotten this way under the care of rational human beings given adequate resources? Well, in a way, it's simple. Perspectives aren't complete. Incentives are off kilter. Hit the fast-forward button for a while and there you have it.
It's great when that perspective is complete, but it's easy to get wrong. I hope to further explain how to notice if that perspective is amiss by considering some common scenarios. I'll start with a caveat about noticing things. There's always a context to consider, and it's best to have frank conversations with people. In addition to that, one can notice people's behavioral patterns and listen to clues in what people say. In the scenarios below, I'm looking for clues, which can then be considered in context, and then hopefully would be followed up with frank conversations that give people a chance to explain their views.
Here are two scenarios. In the first scenario, a software developer says "It's crazy that I have all this stuff to do that gets in the way of my real work. Isn't there a business analyst or somebody else that should be doing all this stuff, so I can spend more of my time writing code?"
In the second scenario, a business manager says "People have been talking about this for two months with no end results. Nothing is getting done!"
There's an element of reasonableness to these comments - and it's easy to miss other signals. Both comments deserve some reflection. Both offer clues about the underlying perspective owned by the speaker about what counts as work and what does not.
I'll consider the first scenario: the software developer's comment. I'll focus in on the part about "real work."
To sketch up the mental model at play here, I see two categories of work. There's "real" work and then there's fake/pointless/useless/inappropriate work. In this model, the act of writing code belongs to the first category. All the other stuff belongs to the other category.. These are presumably things like talking to people, collaborating about requirements, documenting stuff, attending meetings, and the like.
To help put it into perspective as to how incomplete this model is, I'll refer to a model laid out by Agile Manifesto signer Alistair Cockburn in his book Agile Software Development. Cockburn views software development as a "cooperative game of invention and communication" with three possible moves: invent, decide and communicate. From perspective, writing code is just one segment of the "invent" move. Emphasizing one move while neglecting the others puts the game in jeopardy.
It's common on software projects for the focus to shift heavily toward code-centric activities like demonstrating that code has been written and deployed. That might seem like a good thing for a while with no detectable drawbacks. However later, big problems can surface and might seem unconnected to anything in particular. For instance, solution quality can suffer. Defect rates can go up. Solutions can miss their intended mark. The environment can decay. People were too busy writing code. They didn't have time to write tests or do things safely. They neglected to communicate key theories to others. They were too busy to clean up messes.
Another unintended but common side effect of this off-kilter emphasis on the act of writing code is that it might become difficult, if not impossible, to change course once the business segments have become accustomed (addicted) to a certain level of code output.
A similar refrain is an attitude like "this refactoring code business is for the birds. I want to be doing real software development, like building new systems." There's a signal here about what counts as legitimate work for this person and what doesn't. From there will follow a predictable pattern of focus and neglect. Code won't get improved. Lots of new code will get written (probably in need of refactoring).
I suppose my message to those working with developers is "ignore these signals at your peril." A way to address these issues is to go have frank discussions. Monitor the perspectives and reinforce a good perspective amongst developers. Don't assume that everyone appreciates the value behind the neglected activities today as much as they once may have. Don't assume that verbalizing it once is sufficient.
Try linking typically neglected activities to their value proposition in the same statement. For instance:
"Our effort to collaborate about architecture helps make sure important options are considered."
"Our time spent attending meetings helps ensure that priorities get decided."
"Talking to stakeholders and expert users will help the team understand the actual requirements."
"Commenting code helps create sign posts for others to follow."
Now to the second scenario: the business manager's comment about "nothing is getting done." It's easy to grasp the overall message, which is that "not enough" is getting done. It may seem like splitting hairs on the outset, but it's worth pushing back on the notion that "nothing" is getting done, because it reveals the underlying perspective about what counts and what doesn't. Again, if code output is all that counts, then the "incentive ecosystem" gets altered.
Strictly speaking, the comment acknowledges that something is getting done, but somehow those activities don't seem to count. There are meetings that have been held. Decisions were likely made. Ideas likely became socialized. Shared understandings were likely achieved. Designs were likely considered and started. If message goes out that these things don't count , how could that be good?
One can relay the message that not enough is getting done, but it should be done carefully. Thinking of its effect on an "incentive ecosystem" will help people realize that care should be taken when crafting and relaying messages.
I don't think it's uncommon for influential people like bosses and key stakeholders to be unaware of very key responsibilities and activities of technical jobs. They can operate with a perspective on what counts as work that is incomplete or flat wrong if success is the goal. If the perspective is off kilter, an influencer can easily neglect to incentivize key success factors to the detriment of people's careers, the technical environment and the project at hand. They can do this without even knowing it.
That said, I also don't think it's uncommon for technical workers to hold a less-than-complete model of what well-functioning technical jobs entail for a variety of reasons. Sometimes it's inexperience. Other times, it's a tendency to focus only on strengths like solving puzzles and to discount weakness in areas like communication. Still other times, this view comes over time from listening and becoming entrained by the wrong set of signals, mixed with not learning the whole picture. A software developer or other technical job holder can remain blind to a broader and healthier picture of what the job is consists of.
There's room to learn and grow on all sides. No parties involved can afford to take this key perspective for granted. It won't fix itself on its own.
With all that in mind, I hope I can encourage people to go have frank conversations, listen and pay attention to what counts as work in the minds of people affecting software/tech projects - so that this perspective can become an asset rather than a liability. A good perspective of what counts as work can go a long way toward fixing what's wrong and achieving success.
FREE eBook – "45 Database Performance Tips for Developers"
Improve your database performance with 45 tips from SQL Server MVPs and industry experts. Get the eBook here.
Tribal Awards 2013
Simple-Talk and SQLServerCentral are hosting awards to recognize excellence in the technical community. The nominations are open for each of the 11 categories (nominations will close December 17). Check out the awards and nominate your favorites.
12 must-have SQL Server tools
The award-winning SQL Developer Bundle contains 12 tools for faster, simpler SQL Server development. Download a free trial.
The Subscriber is the server where all the changes that are published by replication get delivered to. Every publication needs to have at least one subscriber, but a publication can have many subscribers. This level assumes that you have followed the first three levels and that you have a publication set up, to which you can subscribe. More »
SQL Server 2012 AlwaysOn provides flexible design choices for selecting an appropriate high availability and disaster recovery solution for your application. This article looks at the common design patterns. More »
I learn new things all the time. This was one that actually stunned me. Huge props to Gail Shaw for... More »
Question of the Day
Today's Question (by Steve Jones):
If I wanted to get help with indexing recommendations, which of these command line tools would I run?
Think you know the answer? Click here, and find out if you are right.
We keep track of your score to give you bragging rights against your peers.
This question is worth
1 point in this category: Indexing.
We'd love to give you credit for your own question and answer.
To submit a QOTD, simply log in to the
SQL Server Hardware will provide the fundamental knowledge and resources you need to make intelligent decisions about choice, and optimal installation and configuration, of SQL Server hardware, operating system and the SQL Server RDBMS.
Pick up your copy of this great book from MVP Glenn Berry at Amazon today.
Yesterday's Question of the Day
(by Steve Jones):
Which of these operators requires the input data to be sorted?
Answer: Stream Aggregate
Of these operators, the Stream Aggregate operator requires the data to be sorted. The others do not.
If the input data is not sorted, a SORT operator is included in the execution plan.
Query Help- Unpivot
- Hello every one
I need to develop one logic to use in my script
CREATE TABLE #Temp
SQL syntax error
- Hi All,
Please I need help with this. I am having an error when I try to run a report that...
Backup & Restore
- I am trying to restore SQL 2012 backup on SQL 2008 R2 & it troughs an error.
Error: No backupset selected to...
Finding the MIN and MAX date - How do I approach this?
- I have a table with the following data:
EMPID EffectiveDate PrimaryRater
12345 10/10/2001 A12345
12345 07/12/2013 A12345
12345 08/18/2002 A12345
12345 07/17/1966 A12345
12345 01/01/1966 B12345
What I want to do is...
- I have 2 tables. Each one has the following columns: SSN, PKT and FICE_NBR.
I need to be able to retrieve...
I have a requirement where I have replace two different strings with another string.
i.e. if there is 'Brigade Army or...
This newsletter was sent to you because you signed up at SQLServerCentral.com.
Feel free to forward this to any colleagues that you think might be interested.
If you have received this email from a colleague, you can register to receive it here.