What can I do to help us succeed?

Have you ever been working on some difficult issue and have someone come up and say "What can I do to help us succeed?"

I am not going to talk about the "peace and love" version of this story where everyone magically finds synergy because caring people have joined together.

"What can I do to help us succeed?" Some of the possible responses are :

1. "Us, where did this 'Us' come from?"
2. "Nothing, shut up and quit bugging me!"
3. "You caused this mess I am fixing, get out of my face!"
4. "You could find a new job!"
5. "Do you know of any companies hiring?"
6. "You could learn to mind your own business."
7. "Instead of talking about how we might work around here, why don't you just let me work like I know how!"

Sometimes the above responses may be the correct response. However it might not be wise to say these things out loud.

When someone is under stress trying to get something done that is urgent a well intending person might interrupt with the question "what can I do to help us succeed". This well intending person needs to realize that a response like one of those listed above may be accurate and the best thing to do to help is to stop asking or looking for ways to inject themselves into the solution and allow the situation to run its course.

Does that make sense?

People CHOOSE Process

To me it is not people versus process or even process versus people. People choose the process they will follow and choose how closely they will follow it.

The choice of process should be based on issues, problems, and concerns that need to be confronted. This is a basic thought of all of the Maverick papers I wrote years ago.

[Label: 1]
As the choices are implemented, the implementers (the people), watch to see if the issues are being corrected. If so, they continue forward, if not they re-evaluate and re-implement.

These implementers are the founders and early adopters.

From this point there are many paths that can be taken, one path of evolution is that there are those that come after the founders and early adopters and these people are the ignorant believers.

These ignorant believers become dogmatic and assume they are the guardians and defenders of this newly founded ministry. This is an opportunity to roust those that have held the power, those with which many feel were the cause of some problem. Any failure of the previous regime will be used as a reason to oust them and adopt the new methodology with it's new set of leaders.

Once the new authorities have taken charge they must institute a means of policing actions and judging conformity. Here is were Process versus People begin.

Now the rules have been established and the means of judging conformity in place the next thing is to rank people according to their compliance. Decisions are made on actions to be taken if someone poorly complies. These are known as the consequences.

Now the authorities have the power to fire, with-hold rewards, reward, and promote.

There are those that come in even later. They do not understand why the process is the way it is. They do not understand why the people who are in charge where chosen to be in charge or how they got to be in charge. Others of these new-comers seem to fit in and thrive, while some fit in and perform with mediocrity.

If an employee refuses to follow the process then the machinery that has become the process will act upon that employee.

Most likely there will exist some employees who seem to have an almost magical ability to fight the process but never seem to reap the consequences. I have seen this many times. Usually two or three people can project the reasons why they do not conform in such a manner that they are not punished.

At some point a group of individuals will sit down and analyze the current situation and list a set of problems, issues, and concerns. They will use their experiences to devise a plan to address the issues and they will create an opportunity to put those plans into play.
[GoTo: Label: 1]

If you are not the creator of a new process then you should study the processes that are in practice. As you study them you should try to "fit" the process to the ways you choose to do things and they ways you imagine things should be done. Then you should try to work somewhere that uses that process. This will allow you to fit in, to understand, and most importantly to imagine the next step in the evolution of that process. This notion of the gathering of people based on some common ground has often been attacked. It has been said that this idea limits diversity. That is a statement that has not been proven true. Once you gain experience and seek understanding in the underlying goals of a process and the problems, issues, and concerns being addressed then you can build on a solid foundation.

If you choose to be a mediocre participant then be prepared for the process to "grind you up and spit you out". If you choose to halfheartedly do your job, put in your eight hours, do as little as you can to avoid work and to avoid consequence you will eventually find yourself facing situations of poor performance rankings and you may not even know why and did not even see it coming. If you assume that your co-workers are not studying and experimenting on their own time you are mistaken. There are those that seek to gain knowledge and experience on their on time and dime.

As you study on your own do not become another breed of the dog-matic (get it, dog breed). Do not bring the latest thing you have read about into the work place and shout, "We should do this now!" First experiment with it, use it, and understand the problems, issues, and concerns it addresses. Then do a gentle analysis of your work and see if these problems, concerns, and issues exist. THEN see if the current process has methods to address these issues. Often there exists a way to address the issue and no-one is doing it. If there is no current way of addressing the issue then look at the current system and figure out how to create an interface to use to plug this new method into place. Do not be a bull in a glass/china shop.

Some say that people are never the problem. My level of enlightenment is not sufficient to see things that way. Maybe some day I will see it that way, or maybe not. Maybe I am ahead of them already. The problem is there is no way to know for sure!

At this time I believe this: People make the choices, and people enforce the consequences. (I am not talking about people choosing to break physical laws but people choosing to break impositions.) People choose their response to the consequences. People choose how to judge and they do so inconsistently and imperfectly and therefore the results vary.

(This was originally posted to the Extreme Programming Users Group)

Runtime Adaptation

Runtime Adaptation is the ability for an object to increase and grow into another type of object at runtime.

In most Object Oriented languages an object is "born" with a set of abilities. Typically this is done through inheritance or interfaces.

class JackOfAllTrades : IPerson, IHandyMan, IPlumber, IBrainSurgeon, IAutoMechanic
{
}

JackOfAllTrades can be used in any method where an IPerson, IHandyMan, IPlumber, IBrainSurgeon, or IAutoMechanic is needed.

At runtime JackOfAllTrades can not become IDentist. JackOfAllTrades can not learn to be a dentist and cannot act in the role of a dentist.

Runtime Adaptation allows JackOfAllTrades to become a full fledged dentist at runtime and retain this ability carrying forward. JackOfAllTrades does not have to use another object that implements IDentist and then have that object do work in his behalf.

Just as JackOfAllTrades wants to increase in ability JackOfAllTrades may want to loose abilities as well and give up plumbing.

The acquisition of new abilities could be considered "Behavior as a Service" and I could vend the IDentist capabilities to your JackOfAllTrades.

Just a small glimpse of the sandbox in which my mind plays.

Design by Use to the rescue... AGAIN

Just a quick note. Yesterday I was bogged down in a serious piece of code re-work. It was the changing of part of a framework. Since it is a framework, everything built on it is affected by change.

I was changing from an Event based model to what I term a "usage" based model. Remembering the advice of Stroustrup that resource acquisition is allocation I used this knowledge to begin to make the changes. I became stuck very quickly. Stuck in the overwhelming amount of code and all of the many classes that had overridden these framework interfaces.

Once again I remembered, Design by Use. When I did this the paralysis ended and the solution began flowing. I started at the level from which the new model/framework would be called and I wrote the code as if the new framework already existed. Often the old code was harvested into the new methods where appropriate. Everything flowed and it was more like writing new code with no dependencies than re-working code. Why? Because that is what it became, new code!

All of you must try Design by Use! It has really made a difference for me. When ever you are stuck try it out!

Solutions and Opinions

Applying my knowledge of Computer Science and recalling experiences from years of application I find myself contemplating "solutions" and "opinions".

When I am writing code, when I am actually typing in the code, I am working towards a solution to a problem.

These problems are constrained to be solved in the environment in which they exist. For instance the code has to be in C#, it has to work in Windows Forms, etc. There are other constraints such as memory usage, and performance. And still there are constraints in how the code will present itself to the user through the User Interface. The User Interface is constrained by accepted and common interactions defined by the domain of the product. What I mean is a Word Processor has a certain set of UI expectations and constraints placed on it by the user community just because it is a word processor.

Solving problems as a developer is a difficult task. The breadth and depth of knowledge and experience must be large and ever increasing. I have seen many people never gain enough knowledge and experience necessary to continue to advance as a software developer. Some of these people were aware of their situation and made appropriate career choices. Others were oblivious to their position and found themselves locked into dead end tasks or even fired.

Currently I find myself re-working some code. The code came into existence because of a short coming in the design. The code was the results of considering what would be the simplest thing to do while fitting into the current design. As with all code once it is wrote it becomes part of the environment in which any new code will exist and has influence over how the new code will be implemented.

Honestly my head seems to hurt at the thought of re-working the code so that current needs for improved resource usage can be realized.

The burden of the solution rests upon me. The idea of sharing the problem with others and getting their opinion on how to develop the solution is interesting and maybe even therapeutic but ultimately shallow. In all of my years of experience I have never seen anything more than a superficial "pre-flight" check from having others review a design that is based upon a large set of code that the reviewers have no real knowledge of the inner workings, couplings, code-arounds, and all the other things that make up that piece of working code. If the code had a boundary with some other system then it would be beneficial to talk to the owners of the other systems. This current problem is completely encapsulated in "my" code.

As I sit here focused on the problem at hand a tinge of jealousy seems to rise up. Jealousy of what you ask? Jealousy of those around me working on things where opinion is sufficient and no further effort is required.

The solution I have to invent has to meet those many constraints I mentioned before. It will be domonstrable that I have met the requirements through running the profilers and passing the programmer's tests. I literaly sit at this desk for hours without end and yes it is hard.

So, I am a bit jealous today of the buzz I hear going on around me where people are making decisions based on opinions and where people can declare "It must be done like this" on one day and then the next day say "It now must be done differently" and those that actually have to "do the doing" are different people. Do they feel more important? Do they feel more job satisfaction? Do they feel less pressure? Do they have the burden of constantly improving? Do they have the burden of constantly replacing the core tools of their trade with new and shiny tools that are completely incompatible with the old tools and basically no better (i.e. Fortan -> Pascal -> Modula 2 -> Ada -> C -> C++ -> Java -> C#). I am absolutely sure I could have created the current product that I am working on using Structured Analysis and C and it would be just as good as the one we have now that uses Object Oriented Design and C#.

So, I sit here, improving the resource utilitization of the product and I wonder what difference does it all make. Someone else in the product could be making a choice right now that uses all of the RAM I am trying to save. Somewhere someone is making yet another GUI toolkit to which I will have to eventually port the current system.

Oh yeah, I remember my motivation. A pay check. Yep that must be it. Because it surely is not all of the opinions I hear every day and change with the current weather.

Always "Releasable"

Recently I was trying to describe code that is always releasable.

One simple criteria is if someone came to a developer and said "We are going to doing a build this afternoon and release it to the public" the developer would not say "Well you need to wait because I need to go back in and change _____".

Can code be inter-iteration releasable? That is, right in the middle of the iteration can a build be made to release? It can be. I have found because of troublesome code merging issues caused by source control I often check in things that are not complete or done. These things compile and even pass their tests but the task is not finished. I check in often because I have had significant "fights" with source control not recognizing "new items" because the project file was modified by another developer, etc. If the "sand box" or "shelf set" were better I would not be inclined to check in to the main line of the code until the task was complete.

So, code can be always releasable if only completed tasks are checked-in. Incomplete tasks are safely backed up and stored in a sand box or shelf set or jump drive or something.

Software Quality: Customer Facing -vs- Developer Facing

There are, at least, two different types of quality to software. Customer facing and Developer facing.

Customer facing quality is defined by the customer and has to do with any aspect that the customer finds important. If there is some aspect of a software product that the customer dislikes for any reason the customer can deem the product to be low quality. For instance, if the software takes too long to load at startup the customer may complain about the quality of the software. If a button in a GUI interface is not where the user expects it then the customer may complain about the quality of the software. In these two examples often the user will say, "Did anyone test this before it went out the door." This line of questioning also leads many to think that enough testing will find all quality issues.

Developer facing quality is defined by the developer when making judgments about the code or the systems upon which the code is developed. Code quality is often discussed in terms of such things as no duplication, no go-to's, no global variables, etc. Code quality also encompasses such things as which database was used, which OS is the target, etc. Yet another aspect of code quality has to do with the architecture, design, and metaphors used to compose the software.

Let me be clear, the customer does not care about the code quality. (Now if you are developing software libraries, tool kits, frameworks, etc., and provide the code to your customers then this is obviously different.) To the customer it is all product quality. If a customer finds problems with their software and the customer actually has the opportunity to talk to the developer of the software and the software developer says, "Well the problem is we have way too much duplication in the code and there is this static class filled with values that get changed all over the place, yadda yadda yadda" all the customer hears are EXCUSES.

Does this mean that the developer's concerns and efforts to have a level of quality in the code are ultimately worthless? Well, if you think that then I suggest you are trying to convince yourself of something other than reality, whether you are denying the fact that you don't really have enough money or skill to be in the business or some other reason you want to blame development. Developer's have compelling reasons to address code quality issues.

Does the customer care if the software was developed by the greatest programmers? The first answer is "NO", they do not care. One reason is they don't care because they do not understand how software is made and how the making of the software is tied to the customer facing quality.

Should developers try to get customers to care about code level quality? No because I feel it is not possible to communicate such things.

So, if I am correct that customers do not care about code quality and it is difficult to imagine that the majority of customers could be enlightened. So then, what is the purpose of this posting?

There are at least two types of quality spoken of when talking about software. Often one person is talking about customer facing quality and the other is talking about developer facing quality. It causes endless discussion which get no where!

In my opinion these items are realities of software:

1. The customer cares about product quality.
2. The customer DOES NOT care about code quality.
3. The customer believes product quality is the results of testing.
4. A product can have minimum "product quality" issues and be filled with "code quality" issues.
5. A product with poor code quality will not be able to keep up with competing products in an agressive market space.
   
6. A product with poor code quality will not be able to attract or retain the talented software developers needed to move the product forward
7. A product with great code quality may receive a low quality product rating by the customers.
   
8. The customer will leave a product that lags behind the competition.
9. The customer will spend their money how they see fit.
10. A company with more money can produce more low quality code and be able to afford the incurred costs in order to push a company with less capital out of the sector.
11. A company with more money can address customer facing quality issues through the use of customer service activities such as phone support, books, tutorials, managed users groups, etc., thus the company's wealth is sufficient to afford the costs of issues with product quality.

This list could go on and on.

In the developer community can we at least be clear when we are talking about customer facing quality versus developer facing quality? Call it out when it is not clear which type of quality is being discussed or maybe it is yet another facet of quality still.

Is it obvious that this is a complex system with many inputs and feedbacks. Cash is king, up to a point. Product quality is king, up to a point. Code quality is king, up to a point.