tag:blogger.com,1999:blog-83900640199815826282024-02-18T21:19:09.178-08:00Maverick Software DevelopmentGeoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.comBlogger39125tag:blogger.com,1999:blog-8390064019981582628.post-8410762034575370082012-05-11T13:59:00.001-07:002012-05-11T13:59:00.580-07:00Maverick Software Development Model(April 1, 2004)<br />
<br />
<span style="font-weight: bold;">Abstract</span><br />
<br />
The
Maverick Development Model is concerned with identifying the best
practices for a given situation. A model development process is one that
produces the correct development process for the current situation and
constraints.<br />
<br />
A model of development differs from
development methodologies (such as Waterfall, Spiral, or Agile) in that
the goal or desired outcome is the driving force, ever present, and
never forgotten. Methodologies are approaches to achieving goals, but to
often the reason for the steps of the methodology have been forgotten
and no one knows the reason things are done except that the method
requires it.<br />
<br />
There are many good practices that have
been accepted over the years and some of them will be presented as well
as personal insights and philosophies concerning the software
development process and the roles that make it up.<br />
<br />
It
is time for software developers to become computer scientists. The
computer scientist is a role that encompasses all of the
responsibilities necessary to complete the tasks of software
development.<br />
<br />
It is time for managers to become leaders
and to forgo the methods of management that do not improve the
development process. The process exists to help the workers and not the
other way around were the workers are there to satisfy the process. The
tail should not wag the dog.<br />
<br />
<span style="font-weight: bold;">Introduction</span><br />
<br />
Since
1987 I have been participating in software development. I have watched
the struggle between the programmers and product marketing, where the
later sets the features and the delivery date and then complain about
the quality, missed dates, or missing features. This struggle still
exists and remains basically unchanged to this day.<br />
<br />
I
have witnessed the introduction of management to the software
development process. This management consisted of processes with the
idea of making the software development predictable, traceable,
controllable, and manageable.<br />
<br />
Several times over my
career my various employers have trained me to perform formal reviews
and in all of the roles of a review session. At each company, after the
training and within a few short weeks, the review process ceased and the
programmers went back to their old ways.<br />
<br />
I have
witnessed the acceptance and use of waterfall methodologies and their
many variants. I have watched management follow the methodology with
only the rigor that a true manager can attain. The requirements were
gathered by product marketing and from that a design was made. This
design became a hard and fast contract. However the design seemed to be
used more as a defense exhibit (CYA) because every product date was
always missed and development dragged on with no apparent end.<br />
<br />
I
have watched the release dates for the product set by the next
occurrence of COMDEX and not by anything that actually pertains to the
development of quality software. I have personally asked for
requirements to be updated while in the development stage of the life
cycle only to have management say that the waterfall method did not
allow you to go back and change anything. I was flabbergasted! "The
method doesn't allow" is a statement that just doesn't make sense. A
method is not alive and does not make choices or demands. Management
didn't allow the change because they didn't understand the goals the
method was trying to reach. Management didn't allow the change because
they can't change the process because they didn't understand the
development process in the first place. As hard as I tried to indicate
that changes were needed it was like talking to the wall. Where are we
today? I feel we have made some evolutionary improvements that place us
at a point to achieve revolutionary improvements. The idea is to
recognize goals and create custom processes to achieve those goals for
the current situation. One shoe does not fit all.<br />
<br />
While
working for the Department of Energy I struggled with the lack of
contact the developers had with the customer. As a developer I felt
completely out of touch. I had a written description of what they
wanted. The description captured the letter of the law, but I had no
feel for the spirit of the law. In 1992 I presented this analogy to my
colleagues.<br />
<br />
"Once there was a famous painter who was
retained by the head of a European State. His time was so valuable that
there was an assistant assigned to the artist. This assistant was to go
out and find work for the artist and to gather the description of the
desired painting. The assistant met with a wealthy merchant and
convinced the merchant to commission a painting of his son. The
assistant promised the painting finished in three weeks and returned to
the artist. The assistant described the merchant's son to the artist and
the artist painted a young boy in a silken blue suit holding in his
hand a hat with beautiful plumage. The assistant took the painting to
the merchant who agreed that the painting was exceptional but in reality
it did not look anything like his son and that he wanted his son
painted with is brother standing in a lane by a tree outside of their
home. Needless to say the artist never delivered exactly what the
merchant wanted. Each version became closer to the desired outcome but
never just right."<br />
<br />
My argument was that computer
programming is only one small piece of the training received at the
University. I hoped that we could be more than just a programmer; I
hoped we could be a computer scientist. I wanted to apply what I had
learned in requirements gathering, systems analysis, effort estimation,
and design as well as write the code. However, my skills in writing code
were expensive to acquire and my employer deemed my time too precious
to be spent doing non-programming tasks that could be delegated to less
expensive employees.<br />
<br />
Also I have dealt with another
extreme where managers that thought the developers where "prima donnas"
that did not work hard, that waited until the project was well beyond
the point of no return and then asked for raises and stock options and
held the company hostage. Also the managers thought the engineers padded
their dates so they could take it easy. There where managers that said
they were sick of the attitudes of the developers and that if they were
not happy then they should just leave because they are easy to replace.<br />
<br />
If
it wasn't enough to have managers without any real understanding of how
to develop software I have watched developers dup management into
believing heroics are required to develop software. Duped into believing
that there is only a few that can develop the product and the rest of
the developers are to take supportive roles. I have watched these clever
developers build empires to protect themselves and become the very
prima donnas that management complained about.<br />
<br />
I have
seen excellent developers black balled by these empire builders because
the empire builders realized that this person was skilled enough to
replace them. I have watched these empire builders wait for a power
vacuum to occur and rush in and fill the gap. I have seen them target
other developer's features that are late and secretly criticize the
developer. Then, while the developer's reputation is in doubt, the hero
works many late hours and rewrites the feature and presents it to
management who in turn praises their effort and commitment to the
company. The other developer is then regulated to a subservient position
and is basically layoff fodder for the next round.<br />
<br />
I
have watched managers closely and found that very few managers excel at
their task. Why? Leadership was the original goal, and management
somehow was adopted. If a manager does not write code then what does he
bring to the development effort? I have noticed that most managers
consider their job to be reporting state in meetings. Therefore, they
are only working when they are generating reports that capture the state
of development and when they are in meetings presenting their reports.
Managers are rewarded on their reporting skills and thus the amount of
reporting grows beyond their ability to control. Then they assign the
developers to help by making intermediate reports that will be used as
sections in their master reports. Soon developers are spending one or
two hours a day generating reports of the current state of the
development effort. That state of the project has changed before the
report is finished and the report captures only a ghostly
representation.<br />
<br />
In 1997 a friend gave me a copy of
"Maverick: The success story behind the world's most unusual workplace.
Ricardo Semler. Warner Books. 1993." I never read books on other
people's success stories because I always figured that the revenue from
their book was their success story. I reluctantly began to read the book
and soon found a kindred spirit in Mr. Semler. Everything he said made
sense to me, even though his business was in manufacturing. I could see
benefits for software development. Eagerly I summarized his book and
presented it to management. They laughed at the idea of publicly known
salaries. When designing a new workspace for development I suggested
that they give the developers a budget and let them pick their desk and
chair. They responded that the furniture was an asset of the company and
that the developers would pick a hodge podge arrangement that would
look terrible. Wow, it was almost word for word from Semler's book when
they were trying to select uniforms for their workers. I name my
development model after his book, the Maverick Development Model. Mr.
Semler has never met me, and the name does not mean to suggest he has
supported this effort or endorses it in any way. It is my way of giving
credit to one that has inspired and reinforced my ideas.<br />
<br />
After
being formally mocked for presenting the Maverick concept I went about
my work trying to inject those ideas into the environment whenever the
possibility presented itself. Needless to say, I was more often labeled
radical, a loose cannon, and someone that had no idea of how real
business works. After several years of frustration I decided it is
easier to be quite and draw my paycheck. I lost all love for the
software development process and kept my head low to avoid the
laser-targeting sights of the layoff assassins.<br />
<br />
Since I
was unhappy with anything to do with the process I focused solely on
object-oriented development and how to model systems in a way that the
code was easy to maintain and be bug free. Before agile methodologies
required unit test I had a personal policy of testing each piece of my
code before introducing it in the system. My rationale was, if you don't
have any confidence in you own code then how can you determine where a
bug lies when you integrate your code with someone else's? I felt each
piece of code had to be solid so that you can build upon it. You had to
have confidence in some piece of the system; otherwise you will never
know if you fixed a bug in the right place. For example, if the compiler
is suspect, the third party libraries are suspect, the code from the
rest of the team is suspect, and your code does not have some proven
level of quality, then when the system fails where do you look for the
problem? I have heard "compiler bug" cried probably a hundred times. In
all of those, I have seen it to be the case only twice. Why do I share
this? Because the evolutionary path that has led us to Agile process and
Test Driven Development has be trodden by many of us.<br />
<br />
This
rationale of building on a solid foundation came from a few years of
porting code. I have seen the memory manager rewritten too many times.
You remember the guys that said, "You can't use alloc, it is
inefficient. I read somewhere that you have to write your own to get any
kind of performance from dynamic memory allocation." Always the reason
was to improve performance. This piece of code then became a roadblock
in the porting effort. Also, the code required the complete attention of
a developer. I would say, "We are not in the operating system services
business. We shouldn't be rewriting what the OS should provide. If the
OS is not working, then develop to a better platform and quit supporting
this garbage." They dismissed my comments as to hard-line. But I
learned that we did not have a solid foundation because of all of the
in-house developed services. The core service of memory management was
now always a suspect. Many bugs were found in the memory manager. When
something didn't work, were did you look for the problem? You had to go
to the lowest layers and verify that the memory manager was not the
source of the problem. Ironically the memory manager became the bane of
the main platform as well. The system was taken to Intel to profile the
product and suggest improvements. They pointed out that one of the
trouble spots was the proprietary memory manager. It did not perform as
well as the standard memory manager provided by the current version of
the OS on the current hardware. The reason was that the OS people
continued to develop and improve their services and to optimize their
services for new hardware. The proprietary version, once debugged, was
left "as is" and in a few short years become obsolete for the advances
in hardware and operating systems. I relate this story because it is
necessary to recognize the facets and subtle interplay in software
development that the development process must recognize and support. If
the memory manager would have had regression tests then it would not
have been a suspect with every bug. If the developers would have
delivered on the core business instead of optimizations of OS
functionality they would have been better off in the long run. Agile has
concisely described this as building the functionality that delivers
value first, do it with the simpliest implemenation that meets the
requirements, and use a test first design technique.<br />
<br />
Since
those times of which I described there have been some events that have
occurred and set the stage for Maverick Development. One is the
development of Java. The other is the acceptance of what is now termed
Agile Methods.<br />
<br />
Java has helped by reinforcing my idea
that you shouldn't develop services that the OS should provide. This may
be termed "don't reinvent the wheel" but it is much more than that. It
is about letting others have their core business and trusting that they
might be just as smart as you. It is amazing that the developers that
were so concerned about performance and writing their own memory manager
would ever accept Java.<br />
<br />
Java was slow compared to
anything we had seen for years. So, why did the same engineers that
wrote their own memory manager embrace Java? Because, it was time to
rewrite the system again or they wouldn't have a job! They had to sell
management on another version of the product. They dropped the old
buzzwords of web services, n-tier, peer-to-peer, and all the others.
Regardless of the reasons the acceptance of Java has opened the door for
me to try again to change the way software is developed. I have been
quite for too many years. I love software development and it is time to
present ideas and hopefully start meaningful discussions that lead to a
revolutionary change in software development.<br />
<br />
Agile
methods have really helped in motivating me to gather my ideas and write
this document. Honestly I am really shocked that agile methods have
been accepted. The agile methods are addressing the same issues I have
been concerned with for years. One of which is that of "the process
doesn't allow us to go back and change the requirements." Finally in the
name of agility you can go back and fix things that are wrong and work
in a reasonable manner. But alas, as soon as you specify your ideas as a
methodology, and there is some missing step for a specific situation,
some manager that only knows the letter of the law will still say, "you
can't do that, the process/methodology doesn't allow it." I have been
doing research on XP for large teams and XP with Integration Testing. I
have found many statements like, "XP doesn't do that" or "XP only does
unit testing and Integration testing has to be added in a Waterfall
fashion." Why do these managers "lock" XP down? I feel they lock it down
because they do not understand the real problems and the appropriate
solutions.<br />
<br />
It reminds me of a 300 level fine arts class
I had in college. Being a CS major and having artistic skills are not
common and the application of logic to art is probably not something the
Art Department was accustomed to. I remember learning of the masters,
the great artists that had created a new style and had altered a norm
and had become famous for their unique perspective and talent. Then in
art class the instructor teaches you how to hold the brush in your hand,
how to make the strokes, how to portray depth, how to do each and
everything and then grade you on your conformance. If I painted just
like Picasso then I would never be famous. I would be another painter
that painted like Picasso. I had been taught what made a great artist
and then told not to do the very things that made them great. I had been
exposed to the model but taught to follow the method.<br />
<br />
Why
do I go into these past experiences? They form the foundation of my
reasoning. I have always said, "It takes a village to make a village
idiot." Without the foundation of understanding then methods are
followed for the wrong reasons. I heard this story once.<br />
<br />
A
woman was cooking a ham. Her daughter-in-law notices that she cuts the
ends off of the ham before baking it. She asks why. "Because it makes it
taste better." Does it really make it taste better? After some
investigation it was learned that the reason why she cut the ends off of
the ham is because her mother did the same. The reason her mother did
it was because she had seen it done by her mother. The reason the
grandmother did it was because her baking pan was too small to hold the
ham unless she cut off the ends.<br />
<br />
Why do software
development methodologies have the steps that they do? In the beginning
the reason for the method was known. The key is that reason must not be
lost and must be understood.<br />
<br />
As computer scientists,
instead of just developers, we have been trained to act in all the roles
of software development. If your software process falls short in some
area, we can fix it. We can have emergent processes if managers will get
out of the way and if developers can wake up and become computer
scientists and if we will work towards a goal and take whichever road
gets us there. Life may be a journey and the road taken important, but
software development is a destination. We have to lay down the pride, we
have to give up the heroics, and work as a team. I guess this means we
have to understand what work is. We have to understand why methods exist
and what goals they are trying to achieve. We have to wake up and be
thinking individuals that question everything and that do not want fame
for anything.<br />
<br />
Maverick Development is about goals and
understanding. It is about accomplishing the goal the best way possible
at that time. It is about changing anything and everything including the
way you work, the way you think, and the way you interact with others.
It is about removing dead end jobs. It is about real rewards. It is
about trust and selflessness.<br />
<br />
<span style="font-weight: bold;">Work</span><br />
<br />
Work
is something that we all know when we are doing it and we also know
when we are not. However, to give a firm explanation of one's work is
difficult. Work is physically described as a force applied through a
distance. In creative processes there is no physical object to be moved.
That is why effort is used to describe creative work. Distance is also a
non-physical attribute of creative work. Progress is used to describe
this aspect. So, with effort and progress we work.<br />
<br />
In a
methodology, work is anything that progresses from the current step to
the next. In a model, work is anything that finishes some attribute or
artifact of the goal. Thus said, work on a method is very different than
work performed on a model.<br />
<br />
Traditionally one of the
tasks of management is to measure work. The measurement of work is an
intrusive inspection that interferes with the work that is being
measured. The benefits of measurement should out way the costs of
acquiring the measurement. If measurement activities are not worth the
effort to perform then why continue to measure in the same way? Think
and change it. Make it worth the effort. I often wonder at what point
thinking was disallowed. It sure seems like it has been disallowed.<br />
<br />
Developers
are smart and once they learn the rules of a game they try to win. When
developers are monitored and their performance measured, they learn to
perform by what is measured. If lines of code are measured, you will get
lines of code. If number of bugs found is the measurement, they will
find bugs. The problem is we have forgotten why methods measure these
things. Management wanted to measure quality and then they created a
process. Somewhere down the road we ran amuck.<br />
<br />
The
measurement process uses terms like defect discovery rate and whether or
not it is decreasing. It was anticipated that if the defect discovery
rate is decreasing then the quality of the product was increasing. There
are a lot of assumptions here, especially that all bugs are created
equal. If one thousand bugs where found and eliminated and the product
ships with just one bug and that bug manifests itself you have a
problem, especially if that one bug happens to loose and corrupt data.<br />
<br />
Even
algile processes are not perfect. Agile and iterative processes have
the expectation of seeing the additions of new code into the product to
be rather constant over the iteration. Instead we see that the last
three days of the iteration the number of new or modified files in the
system increase dramatically. Why? It could mean many things. Managers
readily accept conclusions from journals and well-known experts instead
learning the current reason behind the problem for themselves. Without
the understanding of reasons the ability to correctly apply the lessons
of these experts rarely happens. Simply said, "You can't rely on books,
papers, and publications to solve your problems. You have to get in
there and figure things out for your specific situation and this
requires understanding of the process and how work gets done."<br />
<br />
In
reality the check-in rate could be the symptom of any number of
problems. Maybe the iteration is to long or the build process is too
painful. Maybe integration is too painful. It could be that the Use
Cases where unclear and too much time was needed to design the code.
Maybe it was dependencies on other modules such that coupling became a
bottleneck. This list could go on and on. Most likely the reason is not
simple, but is complex and there are many reasons that differ from each
team and each person. There is no simple fix and there might not be a
complex fix. It might be the fact that this is the way it is.<br />
<br />
My
point is that it takes more than methods and management to understand
the development process and to identify when progress is being made and
when work has been done.<br />
<br />
In Maverick Development work
is defined to be any task that moves things forward to the ultimate
goal. Most processes do not measure time spent helping other team
members. Traditionally if help has been given to a team member it is not
unusual to label the person that needed help as a weak link. Being
labeled a weak link is like putting strawberry jam in your pockets
because in the next layoff you are toast. So, people will not ask for
help. Is that what management wanted? I doubt it. This is what they get
and often they cannot recognize the environment they have created. In
Maverick Development helping another developer get work done is work.
Helping the team move forward is work. It does not affect the person's
task list in a negative way. If the person does not finish their tasks
for the iteration yet they worked hard on unforeseen tasks then the
person is still successful and considered a great worker.<br />
<br />
When
helping others is not rewarded you will see symptoms of it. You will
hear developers say things like, "I didn't get anything done today
because of interruptions" or the person that needs help will passively
say "I hate to bother you right now for some help but I am stuck" or
they will only ask for help through non-intrusive manners such as
e-mail.<br />
<br />
Work together and be concerned for others
success. If managers are counting and measuring, then developers will
only work on what is being counted. If there is no metric on how many
others you helped to be successful today, then no one will help others.
Maverick Development demands less measurement OR it demands management
to truly measure work, which would be a very difficult task that most
managers are not up to. Maverick development raises the bar on
management.<br />
<br />
<span style="font-weight: bold;"><br />Computer Scientist</span><br />
<br />
The
developer has to be more than just a code writer. The bar is raised on
the developer. For lack of a better term I say the developer must become
a computer scientist. I chose the term computer scientist because
during my formal education as a computer science student I learned all
the aspects of developing software. I learned about programming
languages, algorithms, requirements gathering, quality assurance, effort
estimation, software cost, motivating programmers, ...<br />
<br />
The
computer scientist is a leader in the area of software development. The
computer scientist understands that heroic efforts can destroy teams
and skew business perspectives into believing heroics are necessary. The
computer scientist understands when to use multiple inheritance. A
computer scientist understands runtime behavior as compared to static
behavior. A computer scientist understands the costs of coupling and
poor cohesion. The computer scientist understands activities that
improve productivity and activities that slow things down.<br />
<br />
<span style="font-weight: bold;">Management</span><br />
<br />
First
I need to define the type of manager to which I will refer.
Historically developers have been promoted to team lead, then manager,
then director, and on up the ladder. I have also noted there are two
paths to manager. The other path comes from the business side of the
company instead of the technical side. In the organizations I have
experienced often the manager has a technical role. The manager reviews
and approves designs and architectures. Also the manager choses the
development methodology, the amount of reporting, the format for
meetings and documents, coding styles, and other things that directly
relate to the development process. In addition to these responsibilities
these managers also perform reviews, do budgets, and report status. The
manager often uses the position to inject their desire in one situation
and delegate when they have no opinion. This inconsistent use of
position is not helpful.<br />
<br />
Management has to come to its
own in the Maverick Development Model. What does this mean? They have to
have clear understanding of all of the aspects of development. First
they have to understand each individual. Why, because they are managing
people, they are not managing skill sets and resources. Everyone
communicates in different ways. Everyone expresses concern in different
ways. Everyone is motivated in their own way. I would imagine that a
good manager , like a good poker player, can read a person as well as
listen to a person.<br />
<br />
Managers have to understand why
different methods and practices are available and know which practice to
apply to a situation. Managers are too often like the ship's captain
that knows nothing about sailing. As long as the wind blows the ship
along the right course everything is fine. However, as soon as there is a
problem that requires knowing how to control a ship the so-called
captain is in trouble.<br />
<br />
The skill set of a manager has
to be greater than the average developer on the team. A manager in
Maverick Development must become a leader. A leader is much more than a
manager.<br />
<br />
Patton was a military leader. He did not care
if politicians were pleased with him. He did not care if people did not
like him. The Vietnam conflict was managed. It was not lead. The
difference is clear. The "feeling" about the situation is almost
tangible. Vietnam was managed and the methods were political and had
nothing to do with winning a war or fighting for values. The managers of
the Vietnam War talked in statistics. How many shots fired. How many
casualties. How many sorties. How much money had been spent and are we
within our budget.<br />
<br />
From Mr. Semler's book I paraphrase and quote a section concerning management.<br />
<br />
<span style="font-style: italic;">"...Fernando
was convinced that the Hobart plant lacked organization, ambition, and
the necessary controls. He would arrive at 7:30 a.m., to find himself
alone in the office until about 9:00 a.m. At 5:30 p.m. people would
leave for home and Fernando would stay until 9, 10, and sometimes 11
p.m. This didn't please him and everyone knew it.<br /><br />Many others
worked long hours too, and their families were beginning to complain.
They were convinced that the hours were temporary, until the company had
digested its acquisitions. 'It took us almost a decade to learn that
our stress was internally generated, the result of an immature
organization and infantile goals.'<br /><br />Fernando was firing people and changing things constantly.<br /><br />'At
the Hobart plant, and all over the new Semco, we could track with great
precision virtually every aspect of our business, from sales quotes
to.welding machines. We could generate all sorts of reports almost
instantly with dazzling charts and graphs.. (I)t took us a while to
realize that all those numbers weren't doing us much good. We thought we
were more organized, more professional, more disciplined, more
efficient. So,.how come our deliveries were constantly late.'<br /><br />Work hard or get fired was the new motto. Everyone was being pushed forward instead of being self-propelled.<br /><br />'During
this time I often thought of a business parable. Three stone cutters
were asked about their jobs. The first said he was paid to cut stones.
The second replied that he used special techniques to shape stones in an
exceptional way, and proceeded to demonstrate his skills. The third
stone cutter just smiled and said: "I build cathedrals.'"</span><br />
<br />
<span style="font-weight: bold;">Leadership</span><br />
<br />
Maverick
Development is based on leadership. Leadership is something above
management. All leaders have management skills. The converse is not
true. The bar has to be raised on managers. They have to be leaders.<br />
<br />
Agile
methodologies depend upon emergent processes. Managers cannot control
this type of process because of its very nature. Maverick Development
goes where ever is necessary to get the work done. When an unexpected
situation arises we do not plod along the same path just because the
directions say to go that way. Instead, in Maverick, we say, "Hmm, an
unforeseen problem. What should we do? Go on? Go back? Go around? ... "<br />
<br />
Leadership cannot be taught. Quoting Dr. Huge Nibley,<br />
<br />
<span style="font-style: italic;">"At
the present time, Captain Grace Hoper, that grand old lady of the Navy,
is calling our attention to the contrasting and conflicting natures of
management and leadership. No one, she says, ever managed men into
battle, and she wants more emphasis on teaching leadership. But
leadership can no more be taught than creativity or how to be a genius.
The Generalstab tried desperately for a hundred years to train up a
generation of leaders for the German army, but it never worked, because
the men who delighted their superiors (the managers) got the high
commands, while the men who delighted the lower ranks (the leaders) got
reprimands. Leaders are movers and shakers, original, inventive,
unpredictable, imaginative, full of surprises that discomfit the enemy
in war and the main office in peace. Managers, on the other hand, are
safe, conservative, predictable, conforming organizational men and team
players, dedicated to the establishment.<br /><br />The leader, for example,
has a passion for equality. We think of great generals from David and
Alexander on down, sharing their beans or maza with their men, calling
them by their first names, marching along with them in the heat,
sleeping on the ground and being first over the wall. A famous ode by a
long-suffering Greek soldier named Archilochus, reminds us that the men
in the ranks are not fooled for an instant by the executive type who
thinks he is a leader.<br /><br />For the manager, on the other hand, the
idea of equality is repugnant and indeed counterproductive. Where
promotion, perks, privilege and power are the name of the game, awe and
reverence for rank is everything and becomes the inspiration and
motivation of all good men. Where would management be without the
inflexible paper processing, dress standards, attention to proper
social, political and religious affiliation, vigilant watch over habits
and attitudes, etc., that gratify the stockholders and satisfy security?
... Managers do not promote individuals whose competence might threaten
their own position, and so as the power of management spreads ever
wider, the quality deteriorates, if that is possible. In short, while
management shuns equality, if feeds on mediocrity... For the qualities
of leadership are the same in all fields, the leader being simply the
one who sets the highest example; and to do that and open the way to
greater light and knowledge, the leader must break the mold. " A ship in
port is safe," says Captain Hopper, speaking of management, 'but that
is not what ships were built for," she adds, calling for leadership...
True leaders are inspiring because they are inspired, caught up in a
higher purpose, devoid of personal ambition, idealistic and
incorruptible... So vast is the discrepancy between management and
leadership that only a blind man would get them backwards... "</span><br />
<br />
It
is a common known practice when hiring and retaining software engineers
to retain what is referred to as the 10x performers. Maverick
Development requires the same from its Leadership. Managers that are
leaders will be 10x performers.<br />
<br />
Trust is the key and here is what Mr. Semler had to say,<br />
<br />
<span style="font-style: italic;">"We
simply do not believe our employees have an interest in coming in late,
leaving early, and doing as little as possible for as much money as
their union can wheedle out of us. After all, these are the same people
that raise children, join the PTA, elect mayors, governors, senators,
and presidents. They are adults. At Semco, we treat them like adults. We
trust them. We don't make our employees ask permission to go to the
bathroom, nor have security guards search them as they leave for the
day. We get out of their way and let them do their jobs."</span><br />
<br />
<span style="font-weight: bold;"><br />Performance Reviews</span><br />
<br />
Maverick
Development changes the traditional performance review process. The
goal is to truly review the performance of the team and the individual.
Each person's performance is reviewed by each member of the team and
this includes the team leader. There is no protection because of
hierarchy, title, or rank.<br />
<br />
For more information read Maverick Reviews.<br />
<br />
<span style="font-weight: bold;">Compensation</span><br />
<br />
In
Maverick Development, compensation is public knowledge within the
company. Mr. Semler points out executives with high salaries should be
proud of their salary and confident that they are worth it. If they are
not confident they are worth their salary then they will be inclined to
hide it.<br />
<br />
For more information on compensation please read the section entitled "Compensation" in Maverick Hiring.<br />
<br />
<span style="font-weight: bold;">Meetings</span><br />
<br />
In
Maverick Development all meetings are to have an agenda that is known
before hand by all attendees. The agenda should be concise and if the
meeting is to be one of discovery then state that fact.<br />
<br />
I
have attended to many meetings where some important and complex idea is
briefly presented and management unexpectedly asks for opinions and if
there aren't any they will move to the next topic. This unfair tactic
does not produce the proposed desire of gathering more information.
Prior to the presentation, management has taken as much time as they saw
fit to discuss the matter and formulate their solution. Then they come
to a meeting and blind side the entire team with a topic that is usually
nontrivial. Do they really expect valid input? It is like they are
saying, "Okay you have five minutes, be creative starting now!" Or is it
a paternalistic approach and they are satisfied with the stupid looks
and blank stares? This approach does not meet any goal and is not part
of Maverick Development. Present a decision as just that, a decision.
Present a proposal as that and give people time to prepare for
suggestions.<br />
<br />
In Maverick Development there is never a
lunch meeting. Lunch meetings are rarely necessary. Downtime is
essential, and if you want to have a lively mind for the afternoon then
you may want to take a break at lunch. Do you ever feel that lunch
meetings are used to squeeze and extra hour out of the day? How often
have you attended a lunch meeting and then afterward you still take a
lunch break? Any manager that calls a lunch meeting is to be gibbeted in
an iron cage outside of the conference room for all to see just like
what happened to Captain Kid.<br />
<br />
The 15-minute standup
from XP is sufficient to relay the current state of development. Details
are not necessary. If there is a problem, then the details will be
addressed by all those who can provide a solution to the problem. If
things are on track, no one cares to hear about each item and how "on
track" it is. State is the key, not details.<br />
<br />
It seems
that some managers only produce two things that are their work products.
One is meetings, the other documentation. Maybe three things, the third
being carbon dioxide. The documentation becomes the information
presented in the meetings. These items include endless spreadsheets and
huge step-by-step procedures on how the process is to be maintained.
(Remember in the abstract the comment of the tail wagging the dog!) When
a manager is in a meeting he is working. A developer is considered to
be working when he is writing code. If a developer is in a meeting he is
not working. If a developer is filling out some status report for
management, he is not working. When they are doing these tasks, they are
doing management's work.<br />
<br />
The goal for a status meeting
should be to determine the state of the project. Not to pour over
minute details. The XPM methodology states:<br />
<br />
<span style="font-style: italic;">"...meetings
with the Product Manager and the Steering persons should be context not
content. Have the success expectations changed? Is there any change to
the scope/objectives? Have there been any changes in the
stakeholders/related projects? Are the benefits and cost assumptions
still relevant? Are benefits-realization plans still relevant? Has
quality been changed? Are there changes to project risk or risk
management issues? In other words, is the project still FOCUSED on the
right business outcomes?"</span><br />
<br />
This is a method of
achieving the goal of reporting the state of the project. Since Maverick
Development is goal oriented, and any method that achieves the goal is
fine, then this or any other way to discover the state is within the
Maverick model.<br />
<br />
If there is not a goal, and there is not an agenda, then there is no meeting.<br />
<br />
In
Maverick Development meetings that deal with details instead of status
are called by those who can do something with those details. Developers
call meetings on details to discuss problems in detail with peers and
individuals that can create a solution, not with people that conduct
meetings. When managers attend these meetings they try to do the tricks
of their trade such as injecting comments to stimulate thought and
regulating the conversation to facilitate communication. Stimulate,
regulate, and facilitate, and managers hate developers that can't
produce tangibles. Go figure.<br />
<br />
Managers interrogate to
find the details of the state of the process. Leaders investigate and
recognize on their own. Interrogation is intrusive. It takes to much
time. It removes people from their real work.<br />
<br />
<span style="font-weight: bold;">Documentation</span><br />
<br />
One
reason documentation exists is because someone was trying to meet the
goal of communication. Documents are created so that things do not have
to be said over and over. Documents state things that are fixed, wrote
down, and locked in state, thus the term statement.<br />
<br />
When
documentation does not meet the goal of communication then the document
should not exist. If the document is not read then it clearly has not
communicated anything and it should not exist. How many of you have ever
put some comment in your weekly report to see if anyone was actually
reading them? I have and many times I have not received any response
from my manager. Clearly that report was not necessary. When my manager
is busy doing what he really thinks is important he is not reading fifty
status reports. Since in Maverick Development reviews are not done
solely from the top down it cannot be said that status reports are
required for the review process.<br />
<br />
One approach that achieves the goal of conveying weekly status is just these three statements: on target, concerned, in trouble.<br />
<br />
If
the state is anything but on target, managers will then ask the obvious
question, "Are you taking the appropriate action to rectify the
situation?" How many times have managers pointed out the obvious?<br />
<br />
In
Maverick development there is one place to report status. There is not a
team dashboard, and a textual weekly report, and a management
spreadsheet. There is only one of these items, or some other single
reporting method. If someone wants to generate a new report including
other items, then they are responsible for the format and media
difficulties, they cannot make this an assignment to others. The tail
can't be allowed to wag the dog.<br />
<br />
For more information on documentation please read Maverick Documenation.<br />
<br />
<span style="font-weight: bold;">Release Dates</span><br />
<br />
Release dates in Maverick Development are based on real goals and supported by development.<br />
<br />
In
Maverick Development there is no "release date by trade show". How many
times have you had a release date for a product set by product
marketing to be for the next trade show? Where is the basis on that
choice? They will tell you that if you miss that date we will miss our
window of opportunity. The ability to market and display a product at a
trade show is advantageous. However it is not sufficient to require the
release of a product based on date alone. If the original time
estimation for the set of features places the release date beyond the
trade show then the feature set must be changed to correspond with the
shorter development time.<br />
<br />
Release dates are based on
budget, features, quality, and timing. Product management will always
try to set the date for release, the number of features in the release
and the quality for that release. Well, everyone knows they can only
choose two of the three. The third is always a variable.<br />
<br />
Maverick
development says that there are only two choices that are variable and
that third, quality, is fixed. You can pick the features or the release
date, but not both. Quality is always set at high. That never changes.
No one will accept low quality. If you relax quality then you have
opened the door for your competition to take your market share by merely
reproducing the same functionality with improved quality. You have to
have high quality so that the purchase decision is based on such things
as features and solutions.<br />
<br />
In Maverick development a
goal can be set to reach a certain point in the production by a certain
date. Since Maverick is based on real work, and doing work right, then
it really doesn't matter if the date is not met. Work has really
occurred and real progress was made. Goals are essential for a target.
If the goal is to far out there, it is hard to hit. Should we get down
on ourselves if we miss it? No. Why not? Because Maverick Development
produces real work every day. In reality software is done when it is
done. The scope can be reduced and thus you can be done sooner. Maverick
Development supports these simple facts. Motivating development to work
hard every day is the responsibility of the leaders of the development
team.<br />
<br />
<span style="font-weight: bold;">Conclusion</span><br />
<br />
Since
Maverick Development is goal driven, the goals for the development
process are essential. If a goal for development is to respond quickly
to changing requirements then an agile development methodology could
meet this goal. If you were trying to get awarded a government contract
then a process based on SW-CMM could be the means to the end. Now, one
would say, Maverick development is really nothing. It doesn't tell me
how to do anything. The point is, you should be a computer scientist and
you should already know how to do something or have the ability to
learn how to do something for your current situation.<br />
<br />
Maverick
development opens the door for leadership and for understanding why
methods exist and the real issues the method addresses. I am currently
working on a Maverick Development Methodology for Agile Development.
Maverick Development Model means there is a goal to be reached. If the
method is not the right one you are not stuck. If you are not
progressing, or if there is something missing, or whatever the problem
is, Maverick says you must do something about it. You must apply your
skills as a computer scientist. You must apply your leadership
capabilities. Maverick Development Model addresses the issue of people
that live by the letter of the law and not the spirit. It is out of the
box thinking, but it shows that you have to have skills, knowledge, and
understanding to survive out of the box.<br />
<br />
Maverick
Development demands that people are worth their salt. Reviews are going
to happen and you had better be ready. Managers are not protected and
leadership is the goal. Managers cannot promote mediocrity in Maverick
Development. Managers cannot protect themselves from the movers and
shakers. They cannot create empires. They cannot reward those whom
please them and remove those whom do not.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-69552055113234452622012-05-11T13:56:00.002-07:002012-05-11T13:56:13.993-07:00Unit Tests<h1>
Unit Tests</h1>
by Geoffrey Slinker<br />
v1.2 March 24, 2006<br />v1.1 March 5, 2005<br />v1.2 April 15, 2005<br />
<table id="Table1">
<tbody>
<tr align="left">
<td><br /></td></tr>
<tr>
<td><br /></td></tr>
</tbody></table>
<h2>
Abstract</h2>
How do you view unit tests? Is a unit test is simply a test to verify the
code? But what is the purpose of having unit tests? Maybe unit testing is a
design method. Maybe a unit test is a programmer test. Maybe unit testing is a
diagnostic method. Maybe unit tests are a deliverable in a phase of development.
The varied purposes and uses of unit tests lead to confusion during
discussion.<br />
<h2>
Testing Definitions</h2>
<span style="color: black; font-family: Geneva;">Definitions are taken from :
<a href="http://www.faqs.org/faqs/software-eng/testing-faq/section-14.html">http://www.faqs.org/faqs/software-eng/testing-faq/section-14.html</a>.
Emphasis added.</span><br />
<span style="color: black; font-family: Geneva;">The definitions of
integration tests are after Leung and White.</span><br />
<div class="MsoNormal">
<span>Note that the definitions of unit, component,
integration, and integration testing are recursive:</span></div>
<div class="MsoNormal">
<span><strong>Unit</strong>. The smallest compilable
component. A unit typically is the work of one programmer (At least in
principle). As defined, it does not include any called sub-components (for
procedural languages) or communicating components in general.</span></div>
<div class="MsoNormal">
<span><strong>Unit Testing</strong>: <u>in unit testing
called components (or communicating components) are replaced with stubs,
simulators, or trusted components. Calling components are replaced with drivers
or trusted super-components. The unit is tested in isolation.</u></span></div>
<div class="MsoNormal">
<span>Component: <strong>a unit is a component</strong>. The
integration of one or more components is a component.</span></div>
<div class="MsoNormal">
<span>Note: The reason for "one or more" as contrasted to
"Two or more" is to allow for components that call themselves
recursively.</span></div>
<div class="MsoNormal">
<span>Component testing: the same as unit testing except that
all stubs and simulators are replaced with the real thing.</span></div>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">Two
components (actually one or more) are said to be integrated when:</span></div>
<ol>
<li>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">They have
been compiled, linked, and loaded together.</span></div>
</li>
<li>
<div class="MsoNormal">
<span>They have successfully passed the integration tests
at the interface between them.</span></div>
</li>
</ol>
<div class="MsoNormal">
<span>Thus, components A and B are integrated to create a
new, larger, component (A,B). Note that this does not conflict with the idea
of incremental integration -- it just means that A is a big component and B, the
component added, is a small one.</span></div>
<div class="MsoNormal">
<span>Integration testing: carrying out integration
tests.</span></div>
<div class="MsoNormal">
<span>Integration tests (After Leung and White) for
procedural languages.</span></div>
<div class="MsoNormal">
<span>This is easily generalized for OO languages by using
the equivalent constructs for message passing. In the following, the word
"call" is to be understood in the most general sense of a data flow and is not
restricted to just formal subroutine calls and returns -- for example, passage
of data through global data structures and/or the use of pointers.</span></div>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">Let A and B
be two components in which A calls B.</span></div>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">Let Ta be the
component level tests of A</span></div>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">Let Tb be the
component level tests of B</span></div>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">Tab: The
tests in A's suite that cause A to call B.</span></div>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">Tbsa: The
tests in B's suite for which it is possible to sensitize A </span><span style="color: black; font-family: Geneva;">-- the inputs are to A, not
B.</span></div>
<div class="MsoNormal">
<span style="color: black; font-family: Geneva;">Tbsa + Tab ==
the integration test suite (+ = union).</span></div>
<div class="MsoNormal">
<span>Note: Sensitize is a technical term. It means inputs
that will cause a routine to go down a specified path. The inputs are to A.
Not every input to A will cause A to traverse a path in which B is called. Tbsa
is the set of tests which do cause A to follow a path in which B is called. The
outcome of the test of B may or may not be affected.</span></div>
<div class="MsoNormal">
<span>There have been variations on these definitions, but
the key point is that it is pretty darn formal and there's a goodly hunk of
testing theory, especially as concerns integration testing, OO testing,
and regression testing, based on them.</span></div>
<div class="MsoNormal">
<span>As to the difference between integration testing and
system testing. System testing specifically goes after behaviors and bugs that
are properties of the entire system as distinct from properties attributable to
components (unless, of course, the component in question is the entire system).
Examples of system testing issues: resource loss bugs, throughput bugs,
performance, security, recovery, transaction synchronization bugs (often
misnamed "timing bugs").</span></div>
<h2 class="MsoNormal">
<span style="color: black; font-family: Geneva;"></span>What
are your Goals of Unit Testing</h2>
The obvious goal of unit testing is to deliver fewer bugs. But what type of
bugs? Unit bugs? Maybe integration bugs? Possibly design bugs? Maybe it is not a
bug hunt at all, maybe you want to use unit tests to show valid uses of a unit
or maybe you are using unit tests to drive the desing process.<br />
But maybe you have a non-obvious goal for your unit tests. If you do, then
you must specify the goal when you discus unit testing or there will be
confusion.<br />
It is obvious that unit tests can uncover unit bugs. But can unit tests
uncover integration bugs? If a unit test is ran in complete isolation it doesn't
seem possible. Suppose in the system someone changes a method by removing a
parameter. All of your unit tests will fail to compile. (Unit tests can fail at
least two ways, 1. Compilation failure. 2. Runtime assertion) This is an
opportunity to bring the people involved with the integration point to discuss
the changes and their ramifications.<br />
<h2>
Are You Ready for Full Unit Testing</h2>
Let's repeat the definition of unit tests from above.<br />
<span><strong>Unit Testing</strong>: <u>in unit testing called components (or
communicating components) are replaced with stubs, simulators, or trusted
components. Calling components are replaced with drivers or trusted
super-components. The unit is tested in isolation.</u></span><br />
<span>The development of stubs, simulators, trusted components, drivers, and
super-components is not free. If unit testing is introduced midstream in a
development process it can literally reroute the stream. Developers might lose
the velocity they currently have on some feature and thus disrupt the flow.
Introduction of unit tests midstream must be justified and accepted. To
understand how difficult this may be take all of your current development
projects and go to the Planning Committee and tell them that all of the
predetermined dates are now invalid and the dates will need to be shifted "X"
months into the future. Maybe you should have someone under you deliver the news
to the Planning Committee! It's always nice to give a more junior person
presentation experience!</span><br />
<span>Test data generation is an expense that many people do not realize goes
with unit testing. Imagine all of the units in your software system. These units
"live" at different layers. Because of these layers the data it takes to drive a
high level unit is not the same as the data that it takes to drive a low level
unit. In the system high level data flows through the system to the lower levels
and during its trip it is mutated, manipulated, extended, and constrained along
the path. All of these "versions" have to be statically captured at each level
in order to "feed" the unit tests.</span><br />
<span>Test data that comes from or goes into a data base store present their
own difficulties. Setting up the database with test data and then tearing down
the database after the tests have completed are consuming tasks. If your unit of
code writes to a database then it will not have the functionality to delete from
the database. So, the tearing down of the database has to be done externally to
the tests.</span><br />
<h2>
<span>Can You Afford Not to Unit Test</span></h2>
<span>Since unit testing is expensive then some might say it is not worth it
to do. That statement is too general and not prudent. One should say, "Unit
testing is expensive, but it is less expensive than ...". This means you have
clear goals and expectations of unit testing. For example, suppose that it took
you six weeks to finish changes that were needed because of bugs found when the
Quality Assurance team tried to use your code. Suppose that these bugs were some
of the simple types such as boundary conditions, invalid preconditions, and
invalid post conditions. Six weeks might not seem that expensive but let's
examine this further. During these six weeks QA was unable to continue testing
beyond your code. After they get your code the finally get into another set of
bugs that were "below" you. That developer is now six weeks removed from the
development work and will have to get back into the "mindset" and drop whatever
he was working on. Also, the precondition bugs you fix will cause exceptions to
be caught upstream which will cause code changes by those that call your code
which will mean that those "up stream" changes will now have to be retested. If
the upstream changes actually change data that flows down to you it will affect
those that you call with that "new" data and may cause changes to be made down
stream. Is it sounding expensive not to do unit tests in this imagined scenario?
It was supposed to!</span><br />
<h2>
<span>Unit Testing as Clear (White) Box Testing</span></h2>
<span>This is probably the oldest and most well known role of unit tests.
Typically a person other than the author of the code writes tests to verify and
validate the code. Verify that it does the right thing and validate that it does
it in the right way. Often the right way is not specified and the tests are just
simply verifiers. One of the driving principles behind clear box testing by
another party is that the developer is so close to the code he can not see the
errors and can not imagine alternative uses of the code. However, these
alternative uses of the code is often met with a complaint from the developer
saying, "Your test is invalid. The code works correctly for the uses that the
system will require."</span><br />
<h2>
<span>Unit Tests as Usage Examples</span></h2>
<span>Another role that has been filled by unit tests is to provide an
example of how to use the unit. Unit tests that show the proper usage and
behavior of a unit are a verification activity. These unit tests might better be
termed usage examples but are usually lumped into the term unit test. These
usage examples will show how to call the unit and asserts the expected behavior.
Both valid and invalid paths are shown. These usage examples are used to verify
the old term "works as designed." This type of unit test will qualify many bugs
found by the QA team as "works as designed." These tests do not validate the
design but verifies the current implementation instance of the
design.</span><br />
<h2>
Unit Tests as Diagnostic Tests</h2>
A unit test or set of unit tests are often used in the role of diagnostic
tool. These tests are run after changes to the system to see if the verified
uses of the system are still valid. If a change to the system causes a
diagnostic unit test to fail it is clear that further investigation is needed.
Maybe the change has altered the behavior of the system and the tests need to be
updated to reflect this, or maybe the changes did not consider side effects and
coupling and are flawed.<br />
<h2>
<span>Unit Tests as Programmer/Developer Tests</span></h2>
More and more often unit tests fill a role in programmer tests. Programmer
tests is a term that comes from the eXtreme Programming community. On the C2.com
Wiki the following definition of Programmer tests is given:<br />
<em>(Programmer Tests) XP terminology, not quite synonymous with Unit Test. A
Unit Test measures a unit of software, without specifying why. A Programmer Test
assists programmers in development, without specifying how. Often a Programmer
Test is better than a comment, to help us understand why a particular function
is needed, <strong>to demonstrate how a function is called</strong> and what are
the expected results are, and <strong>to document bugs in previous versions of
the program that we want to make sure don't come back</strong>. Programmer Tests
give us confidence that after we improve one facet of the program (adding a
feature, or making it load faster, ...), we haven't made some other facet
worse.</em><br />
Because programmer tests demonstrate usage it fills some of the role of usage
example. Also the programmer tests are used to make sure previous bugs do not
come back which is part of the role of diagnostic tests.<br />
These programmer tests rarely stand alone as I have described them. They are
used in Test Driven Development.<br />
<h2>
Unit Tests as a Part of Test Driven Development</h2>
Unit tests are used in the Test Driven Development (TDD) methodology. This is
not part of testing or part of quality assurance in the traditional sense
usually defined along departmental boundaries. This is a design activity that
uses unit tests to design (with code) the interfaces, objects, and results of a
method call.<br />
<em>"By stating explicitly and objectively what the program is supposed to
do, you give yourself a focus for your coding."</em> Extreme Programming
Explained, 2nd ed., Beck, p50.<br />
By showing what what a program is supposed to do you have given a usage
example.<br />
"<em>For a few years I've been using unit testing frameworks and test-driven
development and encouraging others to do the same. The common predictable
objections are "Writing unit tests takes too much time," or "How could I write
tests first if I don’t know what it does yet?" And then there's the popular
excuse: "Unit tests won't catch all the bugs." The sad misconception is that
test-driven development is testing, which is understandable given the
unfortunate name of the technique."</em> Jeff Patton, <a href="http://www.stickyminds.com/sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test+Driven+Development%29%2A&sidx=2&sopp=10&ObjectId=8497&Function=DETAILBROWSE&ObjectType=COL">StickyMinds
Article.</a><br />
TDD is about testing close to code changes. This provides a type of isolation
(unit tests are performed in isolation) related to change. If you make hundreds
of changes to your unit and then check it in and run your unit tests how do you
know which change or changes caused the failure? Changes often have strong
coupling and it makes it difficult to figure out which change is the problem. If
you change one thing in the code and then run your tests you can diagnose any
problems because they will be isolated to that change.<br />
<h2>
<br />Adding Unit Tests to an Existing System</h2>
If you are working on existing code and you wish to start unit testing you
are in a difficult spot. If you are going to test your code in isolation then
creating drivers, stubs, and simulators to use with your unit tests could be
overwhelming in an existing system. But as with everything, do some studies,
some analysis and figure out what is the best approach for your situation. A
divide and conquer approach will typically help out. Take small bites and chew
slowly or you will never eat the entire elephant!<br />
A typical approach is that any new code that is developed will have unit
tests supplied with it as well. Some of the difficulty to this approach lies in
the fact of which layer you unit exists. If you are a mid-tier unit then you
have to create a driver for your unit. This driver may not be complicated but it
must reflect some state of the real object that it proxies for. Also, you will
have to create stubs for the lower level units that you call. The stubs could be
standing in for existing units that have fairly sophisticated behavior with
legacy coupling issues and known but painful side effects.<br />
Any tier of code other than the top tier can get caught in a vicious "down
stream" flood. Suppose you have developed a lower tier unit of code. You have
created drivers for your unit which use test data that you have generated to
feed to your unit. Suppose someone upstream adds three integers to the data
object that drives your class. Just to test the conditions of the upper and
lower bounds and one valid value you may have to add 27 data objects to your set
of generated test data. Therefore, down stream situations must be
considered.<br />
If your unit calls several methods that manipulate the data in a pipeline
fashion it increases the difficulty in creating stubs. For example if you call
Method X with object A and it returns a modified object A which we will call A'
and you pass A' into Method Y and it returns A'' and you pass A'' into Method Z
and it returns an A''' then each hard coded stub for X, Y, and Z must behave
correctly for all of the variations of A that is used in your test suite (note
this is true for an existing system or for a newly developed system).<br />
If you decide to use programmer tests as your definition of unit tests then
you do not have to develop all of the drivers, stubs, and simulators that are
required to test the code in isolation. In an exsiting system write some unit
tests that state simply and explicitly how the system is currently behaves and
then start to make changes (refactoring changes) to the existing code. When
adding new units of code to the existing system you may take the TDD approach
from this point moving forward. The choices are yours to make.<br />
But enough doom and gloom. I think it is understood that this is not a
trivial task. The issue is going to be on deciding how many unit tests are
enough.<br />
<h2>
Issues After You Have Unit Tests</h2>
After you have unit tests in place there will be issues that arise because of
their existence. What do you do when someone breaks someone else's unit tests?
What do you do when QA finds a bug that could have been found if there had been
more complete unit tests? What do you do when there is a system change that
causes a chain reaction of changes in all of the test data?<br />
These are all issues that easily escalate into the "blame game". That
will not help team work or morale. Even though it is justifiable it is not wise
to allow the team that works on the "core" technology push around the supporting
teams. In those situations segragation of code begins to occur. Pretty soon you
have the situation where no one wants to work with the "core" team and the
"core" team doesn't want to call any one else's code and the problems begin to
increase.<br />
So, you have to decide how you will constructively handle the opportunities
that will arise. For example, someone makes changes that break someone else's
unit tests. This opportunity can be viewed as good. It is good in that the
"breakage" has been found and has been found quickly. That is a good thing. It
is good in that we know which persons are involved in resolving the issue, the
breaker and the breakee. That is a good thing. The two involved can get together
and figure out the best solution for the business. Best solutions are good
things. So, in this example, many good things occurred.<br />
If you do not take advantage of these opportunities it could go something
like this. Joe broke Sally's unit tests. Sally goes to Joe and says, "These unit
tests represent a usage contract. You have violated the contract. Change your
code." Joe says, "Don't be ridiculous. Your code doesn't do what it should and
your unit tests are bogus. Update your code to work in the new world!" Sally
says, "I don't have time to deal with your inability to work within a team
environment. You fix it." Joe says, "ME, ME not working as a team player. It is
you! Gosh!" I think you get the picture.<br />
<h2>
Conclusion</h2>
Make it clear to your development team what definition of unit tests is being
used. Understand that unit testing is not free and the expense increases with
the amount of test data needed and the management of data bases that are
involved. View failed unit tests as a good thing. The earlier you know a unit of
code fails the cheaper it is to fix. <br />
After you have defined your defintion and use for unit tests pick up a book
on the subject, summarize it, and make it available to the people involved.
Clear communication is always a problem (communication is a topic in every
development methodology and business guide that I have studied) and getting
people to agree on terms and usage will eliminate many wasted hours in
meetings.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-52432681397220686412012-05-11T13:55:00.003-07:002012-05-11T13:55:19.144-07:00Develop Everything the Second Time First<h1>
Develop Everything the Second Time First</h1>
<h2>
an Extreme Maverick Approach</h2>
by Geoffrey Slinker<br />
v1.1 DRAFT March 2006<br />
v1.0 DRAFT October 2004<br />
<table id="Table1">
<tbody>
<tr align="left">
<td><br /></td></tr>
<tr>
<td><br /></td></tr>
</tbody></table>
<br />
<h2>
Abstract</h2>
Applying the Maverick approach using the Extreme premise that if something is
good then we will do it all the time or do it to the extreme the idea of
developing a software product the second time first came to mind.<br />
If a piece of software is always better the second time we develop it then we
will always develop the software the second time.<br />
<h2>
Introduction</h2>
After studying the Extreme Programming methodology it inspired me to consider
other things that can be taken to the extreme. Being a Maverick follower I said
to my self, "Self, why aren't other good practices of development taken to the
extreme?"<br />
I have been a student of product estimations for many years. It seems
commonly accepted that when estimating the cost and time of a project you must
have prior experience that is directly applicable to the new task. Otherwise
estimations can be off 300% in either direction.<br />
After writing a new product if the development team was asked how long it
would take to develop the product they just developed then they would be able to
give you a very accurate estimate that excluded the mistakes of the original
effort. Often I have heard, "If there was just time to write this code over
again I could do it right." Right means a lot of things here but I feel it boils
down to the fact that right means that the correct domain model has finally been
recognized and it would be great if the team was allowed to refactor or
re-implement the product.<br />
So, if writing things the second time produce products that are truly
superior than the original then the first thing we should do is write the
product the second time!<br />
<h2>
Second Time all the Time</h2>
Since coding a project the second time can give great improvements in
performance, coupling, cohesion, and overall domain model then why don't
departments just plan on re-writing the product and only ship the second
release? Because that sounds expensive. That sounds as if better planning had
occurred we wouldn't want to re-write the system. That sounds as if we had hired
better people they could have done it right the first time. That sounds like
something went terribly wrong.<br />
The truth is that it could be a sign of all of the things above and it could
also be a sign of a product that had a scope that was not definable until some
experiments had occurred.<br />
Prototyping is the essence of this idea. I am not saying this is a new idea!
But prototyping sounded expensive and since the company always wanted to ship
the prototype rapid prototyping emerged. The term rapid was used to discourage
the company from wanting to ship the prototype. Because of this desire to ship
prototypes and the understanding from the development that prototypes were very
useful the development team had to undermine the quality of the prototype (at
least by name and often by quality) to keep the company from shipping the
prototype.<br />
In the past few years other terms have arisen that refer to the idea of
writing something first so that the second version can be developed. Terms such
as a "one off", "a thin thread", and "a spike". These obvious prototypes or
experiments are tools that are commonly used. There names may exist to avoid the
conversations with management to justify prototypes.<br />
<h2>
Unit Testing is Prototyping</h2>
As I considered the fact that development continued to prototype and
experiment during software development I thought about how unit testing plays a
role.<br />
I propose this description of unit testing:<br />
Unit testing is prototyping the interface and any stubbed or mocked
components necessary to define the expected behavior. The unit tests are
refactored until the desired behavior is represented and the interface is
correct for the domain. Then you write code to get the tests to succeed.<br />
Isn't that a form of prototyping? Isn't it a way of writing things the second
time? Isn't that what Test-First-Design is all about? You are coding up the
interfaces before they are implemented. You are thinking about those interfaces
and changing them to meet the idea of a fluid design. You are running scenarios
through your mind anticipating issues. Mocked objects maybe considered
oversimplified prototypes. Stubbed methods are definitely simplified to the
extreme.<br />
<h2>
The Future of Prototyping</h2>
The benefits of writing something first as an experiment and then writing it
a second time for production have been known for many years. How can these
benefits be used more efficiently? Ignoring the various names of current
activities that are centered on the old term prototyping there should be more
use of these activities without the fear of shipping the prototype. Maverick
development is concerned with trust. Trust your engineers to know that a
prototype, experiment, or spike is necessary and trust them to take the lessons
learned and apply those to a truly production quality resultant.<br />
<h2>
Conclusion</h2>
If allowed to re-write a piece of software it is generally accepted that the
second version is superior to the first in a myriad of ways.<br />
Since writing software the second time is better, we will write the software
the second time at first.<br />
Prototypes, rapid-prototypes, one-offs, thin threads, experiments, spikes,
and unit tests are all methods that address the idea of writing things the
second time give better results.<br />Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-83815652297628765412012-05-11T13:54:00.004-07:002012-05-11T13:54:46.518-07:00Scouting and Reconnaissance in Software Development<h1>
Scouting and Reconnaissance in Software Development </h1>
by Geoffrey Slinker<br />
v1.0 October 2004<br />
v1.1 January 2005<br />
v1.2, v1.3, v1.4 July 2005<br />
v1.5 March 24, 2006<br />
<table id="Table1">
<tbody>
<tr align="left">
<td>Accesses: <img src="/cgi-bin/counter.gif?fg=0,0,0&geoffrey.slinker_scouting" /></td></tr>
<tr>
<td><a href="http://home.comcast.net/%7Egslinker/agile.html">Maverick
Development</a></td></tr>
</tbody></table>
<h2>
Abstract</h2>
Scouting and reconnaissance are two well known methods of discovery. By these
means information and experience are gained when faced with the unknown.
Experience is critical to writing good software. Experience allows you to
correctly identify problems and address them. Scouting and recon for software
development is a great way to gain experience and avoid the pitfalls of the
unknown.<br />
<h2>
Introduction</h2>
In the well known book ‘The Mythical Man-Month’ Frederick P Brooks states:
<br />
<blockquote dir="ltr" style="margin-right: 0px;">
<em>Where a new system concept or new technology is used, one has to build a
system to throw away, for even the best planning is not so omniscient as to get
it right the first time. Hence plan to throw one away; you will, anyhow.</em>
</blockquote>
As the years passed and systems grew in size and complexity it became
apparent that building a "throw away" as not the most efficient approach. In the
20th anniversary edition of his same book, <em>Brooks states that developing a
throwaway version is not as efficient as iterative approaches to software
development</em>.<br />
In Extreme Programming Explained Second Edition, Kent Beck states:<br />
<blockquote dir="ltr" style="margin-right: 0px;">
<em>"Defect Cost Increase is the second principle applied to XP to increase
the cost-effectiveness of testing. DCI is one of the few empirically verified
truths about software development: the sooner you find a defect, the cheaper it
is to fix it."</em> </blockquote>
Scouting and recon techniques are used to discover defects through
experiments and to completely avoid the presence of the defect in the "real"
software. These techniques work within phased or phasic development
methodologies as well as within iterative methodologies and give knowledge and
experience through their use.<br />
<h2>
Gaining Experience</h2>
There are many software development activities concerned with gaining
experience. Some of these activities include creating proofs of concept,
prototyping, and experimenting. I will refer to all of these activities as
experiments.<br />
How much effort should be placed in an experiment? Enough to gain the
experience needed to get you to the next step.<br />
<h2>
Software Scouting</h2>
“Scouting” will be the metaphor. During the exploration of the American
frontier, scouts were sent out ahead of the company to determine the safest path
through unknown and hostile territory. Through software “scouting missions” one
can save time and money, and reduce the risks to the company.<br /><br />Brooks’
first statement concerning building a "throw away" is akin to exploring the
entire route first and then moving the company. His revised statement concerning
iterative development is akin to scouting out a few hours (or days) ahead and
returning to guide the company. This pattern of short scouting trips would
continually repeat, making the technique both iterative and incremental. Through
the scouting metaphor you can gain a certain feel for why building a "throw
away" version is more costly than iterative development.<br />
<h2>
Scouting Tools</h2>
There are many ways to explore the unknown. These activities have many
similarities. One of the key differentiators is the stage of software
development in which the activity occurs. Following various "tools" for scouting
are defined and the stage in which they are typically used is specified.<br />
A <strong>"Proof of Concept"</strong> occurs after a solution has been
conceptualized. Investigation is needed to gain confidence and verify the
viability of the solution.<br /><br />A<strong> "Prototype"</strong> is made after a
design has been made. Investigation is needed to validate that the result of the
design solves the problem. In software prototyping development activities are
scaled back. In engineering prototypes may be scaled functioning models. In
software there is no physical dimension so development activities are scaled
back which include minimal effort for robustness and usually only implementing
the “happy path” of the functionality. Also techniques to reduce coupling are
skipped and cohesion is ignored as much as possible (Even though these
activities are skipped the experience of prototyping bring to light how the
software components should be coupled and an overall domain definition emerges
that allows for better cohesion). <br />
Ed Mauldin explains prototyping as thus: <br />
<blockquote dir="ltr" style="margin-right: 0px;">
<em>“Prototyping is probably the oldest method of design. It is typically
defined as the use of a physical model of a design, as differentiated from an
analytical or graphic model. It is used to test physically the essential aspects
of a design before closing the design process (e.g., completion and release of
drawings, beginning reliability testing, etc.). Prototypes may vary from static
"mockups" of tape, cardboard, and styrofoam, which optimize physical interfaces
with operators or other systems, to actual functioning machines or electronic
devices. They may be full or sub-scale, depending on the particular element
being evaluated. In all cases, prototypes are characterized by low investment in
tooling and ease of change.”</em> </blockquote>
<br />An <strong>"Experiment"</strong> occurs after software modules have been
developed. Investigation into their behavior under varied conditions is needed.
An experiment is conducted to observe the behavior.<br />
A "<strong>Mock Object</strong>" is created during software implementation.
Components have been developed and investigation into their behavior needs to be
done. To isolate these components from the effects of other components the other
components are replaced with "mocks" that have simple and specific behavior.
<br />
A "<strong>Driver</strong>" is created during
software implementation. Components have been developed and investigation into
their interfaces and usability need to occur. A driver is developed to interface
with and drive the component. The interfaces or entry points of the components
are confirmed correct and the pre-conditions of the components are exercised.
The driver can validate the post-conditions of the component as well. <br />
A <strong>"Stub"</strong> is created during software
implementation. Functionality has been developed and investigation of the code
paths needs to occur. Called interfaces are developed with the simplest means in
order to return specific results and exercise the code paths of the caller.
These simple interface implementations are stubs. <br />
A <strong>"Simulation"</strong> is typically created after the system is
implemented. A deliverable needs to be tested in various environments and
conditions. A simulation of an environment is developed and it is used for
testing. Common examples are simulated users, simulated load, simulated outages,
and such. <br />
<h2>
When to Scout</h2>
Remember, scouting activities address the issue of gaining experience in
unknown territory. These activities are not necessary when experience is
present. Simply said, “If you know how to do the job, then do it!” <br /><br />When
one is in unknown territory scout ahead for information, then come back and
apply the knowledge gained. Have enough discipline not to get distracted by the
sights along the way. Stay focused, travel light, and get back to camp as
quickly as possible.<br /><br />Can you afford not to scout ahead? The answer to
this question only comes at the end of the journey. Did you make it to your
destination or not?<br />
<h2>
Scouting for Phasic Methodologies</h2>
One reason that experiments work is because they address issues and concerns
in context and as they occur. It is a "learn as you" go approach. Below are some
scenarios in which scouting can be used in a traditional phased or phasic
methodologies.<br />
<blockquote dir="ltr" style="margin-right: 0px;">
<h3>
Phase 1: Analysis and Requirements. </h3>
• Paper prototypes of the user interface. <br />• Proof-of-concept of a
requirement (i.e. the database must support 500 simultaneous
connections).<br />
<h3>
Phase 2: Design. </h3>
• Refined paper prototypes of the user interface. Paper models of the
architecture and model (i.e. UML). <br />
<h3>
Phase 3: Implementation. </h3>
• Develop an experiment for the “happy path” to discover boundaries and
interfaces.<br />• Create prototypes ahead of implementing frameworks so that
the framework's approach can be reviewed.<br />
<h3>
Phase 4: Testing. </h3>
• Create experiments to test scenarios.<br />• Create testing harnesses
that allow for proxy users (a proxy user can be a user simulated by a computer
program).<br />• Simulate extreme conditions such as system load. <br />(Testing
is scouting ahead of the user to make sure the user’s experience will be a good
one.)</blockquote>
<h2>
Scouting for Iterative Methodologies </h2>
<blockquote dir="ltr" style="margin-right: 0px;">
<h3>
User Stories</h3>
<ul>
<li>Create a proof of concept to verify the User has conveyed their
desires.</li>
</ul>
<h3>
Project Planning</h3>
<ul>
<li>If the user story involves a User Interface, create paper prototypes of the
interface to stimulate user input and direction.</li>
</ul>
<h3>
Release Planning</h3>
<ul>
<li>Create a prototype to identify dependencies to facilitate iteration
planning. </li>
</ul>
<h3>
Iteration Planning</h3>
<ul>
<li>Create design prototypes using a modeling language such as UML. </li>
</ul>
<h3>
Iteration</h3>
<ul>
<li>Create stubs, drivers, and mock objects to increase confidence in the
behavior of isolated units.
</li>
<li>Create an experiment to observe object behavior.
</li>
<li>Create a simulation to test things like performance under a heavy
load.</li>
</ul>
</blockquote>
<div dir="ltr">
This list is supposed to be thought provoking, not complete. The idea
behind scouting is to perform some scouting activity when faced with the
unknown. When doing experiments in conjunction with an iterative development
methodology the experiments are "lighter" than they would be in a phasic
development methodology if the customer/user is taking an active role. With the
customer present one can prototype a user interface with a white board and some
drawings. If the customer is not present then a prototype for a user interface
is usually mocked up with some kind of computer aided drawing package or even a
"quick and dirty" user interface is developed with a GUI building tool or
scripting language.</div>
<h2>
Benefits of Scouting</h2>
<ol>
<li>Scouting brings light to a situation. Through scouting activities
estimations become more accurate. The accuracy comes from the application of the
experience, not from an improved ability to predict the future.
</li>
<li>Scouting reduces coupling and improves cohesion. When writing software in
the light of experience, the coupling between objects is reduced and the
experience unifies the system's terms and metaphors which increase cohesion.
</li>
<li>Scouting builds trust and confidence by eliminating incorrect notions and
avoiding drastic changes in design and implementation. </li>
</ol>
<h2>
Risks of Software Scouting</h2>
<ol>
<li>Is management mature enough to allow the proper use of an experiment and not
try to “ship” the prototype and undermine the effort?
</li>
<li>Is development mature enough to refrain from features creeping into the
product because the experiment revealed something interesting? </li>
</ol>
<h2>
Project Management Ensures Adequate Software Recon</h2>
Project Management should scout and see if their development environment can
support activities that rapidly gain experience. Probing questions include:<br />
<ul>
<li>Are the software developers aware of all of the activities that can lead to
experience?
</li>
<li>Are the stakeholders aware of the benefits of prototypes and experiments?
</li>
<li>Is everyone aware of the risks of not doing recon and the risks of doing
recon? Remember, one of the risks of a prototype is that sometimes people try to
ship it!</li>
</ul>
An interesting exercise would be to listen for concerns expressed by
developers and ask them what activity would address their concern. Some concerns
expressed by developers that can be addressed through recon are:<br />
<ul>
<li>“If I just had time to write this right”
</li>
<li>“I don’t think we know how difficult this is going to be”
</li>
<li>“I really don’t have any idea how long this is going to take”</li>
</ul>
When a concern is expressed ask the developer what they would do to address
it. Listen for solutions that bring experience and shed light.<br />
<h2>
Conclusion</h2>
Experience is key to writing good software. The sooner you discover a problem
and correctly fix the problem the cheaper it is. Scouting ahead in software by
using prototypes and experiments is a great way to discover the right path
without risking the entire company to the unknown.<br />Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-3252484157558542942012-05-11T13:54:00.001-07:002012-05-11T13:54:14.281-07:00Reporting for Accountability<h1>
Reporting for Accountability</h1>
by Geoffrey Slinker<br />version 1.3<br />March 24, 2006<br />April 22,
2005<br />July 1, 2005<br /><br />
<table id="Table1">
<tbody>
<tr align="left">
<td><br /></td></tr>
<tr>
<td><br /></td></tr>
</tbody></table>
<h2>
Abstract</h2>
Reporting and accountability are essential for business processes. Without
those budgets can not be calculated, resources can not be utilized efficiently,
as well as many other issues. Reporting has come to a level where one can truly
do "more with less." Daily stand-ups, end of cycle reporting, damage charts,
dashboards, and burn charts accurately and concisely disseminate
information.<br />
<br />
<h2>
Introduction</h2>
Often the challenge of doing "more with less" is
extended to teams as a catalyst for thought but many readily accept that
generally the paradox is not possible. In the area of reporting of status and
progress in software development the paradox is true. This is accomplished
through the use of less technology than has previously been used and also the
acceptance of new mediums for documenting and reporting.<br /><br /><span style="text-decoration: underline;">The goal of reporting should be to accurately
report the subject matter concisely and precisely. To facilitate that reporting
is done often the mechanism should be easy to use.</span><br /><br />The practices
that will be used for reporting are project planning, release planning,
iteration planning, 10 minute stand-ups, end of iteration reflections, end of
release reflections, end of project reflections, and information radiators or
dashboards.<br /><br />The information radiators or dashboards include damage
charts, burn charts, and project status charts.<br /><br />
<h2>
Ten Minute Stand-Up</h2>
This meeting should be held early and it sets the tone for the day. The
meeting should be held in proximity of the information radiators so that
everyone can see what they are supposed to be doing.<br /><br />Some questions that
can drive the stand-up meeting are:<br />1. Have the expectations for success
changed?<br />2. Has the scope of current tasks changed?<br />3. Have there
been any changes in related or dependent projects?<br />4. Has the priority of
any remaining tasks changed?<br />5. Are there changes to any risk
factors?<br />6. Do you feel the project is focused on solving the right
problems?<br /><br />From these questions you should receive <span style="font-weight: bold;">yes </span>or <span style="font-weight: bold;">no
</span>answers. Any no answers should be noted and addressed afterwards with the
right set of people.<br /><br />
<h2>
Project Planning</h2>
In the 20th anniversary edition of the Mythical Man Month Brooks states that
iterative development has been shown to be more efficient than previous
development approaches.<br /><br />I will not go into the details and benefits of
iterative development and will assume that it is generally understood to be
superior to strict "phased" approaches. I have elaborated on this topic on the
paper "<a href="http://home.comcast.net/%7Egslinker/maverick/Scouting.html">Software
Scouting and Recon</a>".<br /><br />At this point you begin the wheels turning as
described in "<a href="http://home.comcast.net/%7Egslinker/maverick/DBU.html">Design By Use
Development</a>" (DBU). The project requirements are fed into the DBU process.
DBU uses this information to identify subsystems and boundaries. This additional
information helps in the organization and scheduling. The information from DBU
is combined with the project requirements become "User Stories" which are
organized for each sub-release of the project.<br /><br />
<h2>
Release Planning</h2>
The user stories identified as part of the project are now divided into small
related groups that will be developed during the iterations of each release. The
user stories are fed into the next part of DBU and the usage examples are
created. Notice that development starts early but with sufficient information to
be headed down the correct path.<br /><br />Each use case has a priority determined
by dependencies, complexity, and an estimate for completion.<br /><br />The use
cases with their usage examples are fed into the iteration planning.<br /><br />
<h2>
Iteration Planning</h2>
All of the use cases and usage examples for the release are taken and
organized and placed into a particular iteration. When an item has been finished
the actual time for completion is recorded next to the estimated
time.<br /><br />Completion means that the usage example runs without any errors and
implies that the usage example truly represents correct usage and all contracts
(pre and post conditions and invariants) have been satisfied, and that the
completed item has been integrated with any piece that is completed and awaiting
its use.<br /><br />If this is not the first iteration then recommendations from the
previous iteration reflection are considered.<br /><br />
<h2>
End of Cycle Reports / End of Iteration Reflections</h2>
At the end of iteration comments and congratulations are given concerning the
completed items. Any items there were not completed are discussed and
dependencies and release schedules are update.<br /><br />
<h2>
End of Release Reflection</h2>
At the end of release comments and congratulations are given concerning the
completed releases. Any items there were not completed are discussed and
dependencies and project schedules are update.<br /><br />
<h2>
End of Project Reflection</h2>
At the end of the product comments and congratulations are given concerning
the project. The key here is to celebrate the hard work and the finished
product. If scope had to be changed or dates had to be altered for the project
the information concerning those items should have been recorded in the end of
iteration and end of release reflections. This is a time to take pride in the
hard work so don't dampen any spirits. At the next Project Planning meeting the
lessons learned can be discussed and improvement activities can be
identified.<br /><br />They say that each project fails one step at a time but also
each success builds one step at a time. Let's take the positive look on things
and remember to allow people to have success.<br /><br />
<h2>
Information Radiators</h2>
Information radiators are placed where they can be easily seen by those who
are concerned with the project's information.<br /><br /><span style="text-decoration: underline;">Information radiators are low tech for a
reason and that is ease of update.</span> Information radiators should be very
active and therefore necessitate easy change. They should be well organized and
easily captured though the use of a high resolution digital camera. The digital
photograph is the medium for recording. Remember if it wasn't recorded it didn't
happen and notice how easy it is to record. That is like having your cake and
eating it too!<br /><br />There are certain types of charts or layouts that convey
information rapidly that are considered essential for each project. A
description of each type follows.<br /><br />
<h3>
Damage Chart</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1-kGmcv_XX2hL1694EVY-JDhfbLDDAPJgwRUufQN7b_l94QLcJAe6atMnAY7B2eJQziWVBATB72tj_ahm9rR9Q7vrDY1i5gSzh31JXxQRL1kzXDknv79Z5PMCbtD_l0SshjX8T_gHurU/s1600/damage_plot_1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="472" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1-kGmcv_XX2hL1694EVY-JDhfbLDDAPJgwRUufQN7b_l94QLcJAe6atMnAY7B2eJQziWVBATB72tj_ahm9rR9Q7vrDY1i5gSzh31JXxQRL1kzXDknv79Z5PMCbtD_l0SshjX8T_gHurU/s640/damage_plot_1.jpg" width="640" /></a></div>
The damage chart shows damage plotted against amount of planning. Some
projects need lots of planning because the damage from insufficient planning
could be devastating. Other projects need less planning. Just remember, all
projects are not the same and one size does not fit all.<br /><br />Alistair
Cockburn described it to me at a users group meeting something like this: "In
the web browser market the race between Netscape and I.E. was concerned with
getting anything to market. The damage caused by not planning was not the
concern. The key was getting anything into the market. Trying to make the best
web browser didn't matter. Software concerning the space shuttle is completely
different. The damage caused by insufficient planning could be extremely
expensive and cost lives."<br /><br /><br /><br />Other types
of damage plots can be created. Damage for a missed "release window" could be
plotted but this type of chart must be very accurate or you will not be able to
motivate people after wolf has been cried too many times. Estimating the damage
for missing a window of opportunity is similar to the inaccuracy in estimating
when code will be finished. The similarities should cause development and
marketing to appreciate the difficulty of each other's tasks and alleviate some
of the bickering and finger pointing. Holding marketing to their estimates
should be done with the same rigor that development is held to their estimates
or in other words "play fair".<br /><br />
<h3>
Burn Up and Burn Down Charts</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwd4VGiyO5_hkwMwHpOeOSadidhh-NBMueVyixlhdVgbqIfC5amflyIzezIEv9EYDaY5D3LyqQyk0glw0aveqs1xqA240KD-0NGQWVa_4LTF4QBqcR3kBT9lZAjoWCjKHdyxrhyphenhyphenj0tEtM/s1600/burndown_chart_1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="472" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwd4VGiyO5_hkwMwHpOeOSadidhh-NBMueVyixlhdVgbqIfC5amflyIzezIEv9EYDaY5D3LyqQyk0glw0aveqs1xqA240KD-0NGQWVa_4LTF4QBqcR3kBT9lZAjoWCjKHdyxrhyphenhyphenj0tEtM/s640/burndown_chart_1.jpg" width="640" /></a></div>
<br />
These charts show progress. The key is determining the units for the Y-axis.
There are many reports on these charts and one should study them to determine
how you will do them. Here is an excellent reference:
http://alistair.cockburn.us/crystal/articles/evabc/earnedvalueandburncharts.htm<br /><br />In
this example burn down chart it shows that the project estimated the completion
of 100 features in 8 weeks. The chart shows that it took 10 weeks to complete
the features. It also shows that the project was in trouble significant trouble
at four weeks and that the team got the project back on schedule on the fifth
week but was unable to maintain the velocity.<br /><br /> <br />These charts should be updated and
posted with any information radiator that is related to or concerned with this
information.<br /><br />
<h3>
Project Status Charts</h3>
These are those charts on butcher paper or white boards covered with sticky
notes.<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3OC8uLL3cnyLNJY1RuFu-8zVb6nYl6d_2Dwc-1Ea8iaVzuTpcxF8qsm9WHDRQSuJTg6z8AnykCekm4xhbDi5TnXIwO4FULb6k7BHP7w3qni-W3E0o5QENIHVjW1XceZe0sEG1FxFLxgw/s1600/progress_chart_1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="372" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3OC8uLL3cnyLNJY1RuFu-8zVb6nYl6d_2Dwc-1Ea8iaVzuTpcxF8qsm9WHDRQSuJTg6z8AnykCekm4xhbDi5TnXIwO4FULb6k7BHP7w3qni-W3E0o5QENIHVjW1XceZe0sEG1FxFLxgw/s640/progress_chart_1.jpg" width="640" /></a></div>
<br /><br />In this progress chart each line
represents a developer and the use cases for this iteration. Each yellow box
represents a sticky note that will have a short description of the use case and
an estimate for completion. The sticky note moves from left to right showing the
representing the percent completion. When the use case is finished it is placed
on the right with the actual time for completion noted next to the
estimate.<br /><br /> <br /><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicS3ezazpKg1GOSCRS0StBN2mPOGAieydiR511VZJl7KX2MvDT2imPhH395NI8UtHPNIZU42IiCQKNTCpd2Jfz3cfZ3vPI2PZEWoYHNXn6udEDFTMScPg5y7zBKUaIOlNlWlfrF298NZ4/s1600/progress_chart_2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="616" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicS3ezazpKg1GOSCRS0StBN2mPOGAieydiR511VZJl7KX2MvDT2imPhH395NI8UtHPNIZU42IiCQKNTCpd2Jfz3cfZ3vPI2PZEWoYHNXn6udEDFTMScPg5y7zBKUaIOlNlWlfrF298NZ4/s640/progress_chart_2.jpg" width="640" /></a></div>
<br />
This
progress chart shows the entire product. The thick line represents the product
boundary. Every use case above the line will be included in the product. Every
use case below the line are things that were considered but haven't made it into
the product at this time.<br /><br />The use cases labeled "Release Sets TO DO LIST"
are the use cases grouped by release. The current iteration at the top shows the
release set that is currently being developed and are in progress. The finished
uses cases are those that were completed during the previous iterations. The
green arrows show the flow from the left side or to do side to the current
iteration and from the current iteration to the finished side.<br /><br />Each use
case has a time estimation and the total of all of the uses case estimations
form the "to-do" area, the "in progress" area, and the "finished" area the total
time to develop the product. If an item is moved from the "use cases not
currently in the product" into a release set then an item from the release sets
with an equal or greater estimation time must be removed to keep the project on
schedule. <br /><br />
<h2>
Conclusion</h2>
Reporting and accountability are crucial for business processes. The time has
come that reporting can apply the paradox of "doing more with less". Planning
meetings, daily stand-ups, end of cycle reporting, damage charts, dashboards,
and burn charts accurately and concisely disseminate information. By using
digital cameras in conjunction with information radiators the state can be
documented as often as desired. Through these planning and reporting techniques
the goals and state of a project is readily visible and easily
reported.<br />Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-77408975395055066312012-05-11T13:49:00.003-07:002012-05-11T13:49:11.298-07:00Object Oriented Modeling and "Computer Stuff"<h1>
Object Oriented Modeling and "Computer Stuff" </h1>
Geoffrey Slinker <br />
version 1.5 March 2006<br />version 1.4 April 2005<br />version 1.3 September
2004 <br />
<table id="Table1">
<tbody>
<tr align="left">
<td><br /></td></tr>
<tr>
<td><br /></td></tr>
</tbody></table>
<h2>
Abstract </h2>
During object oriented modeling one is tempted to adhere to a rigid approach
of allowed behavior. Once I was working with a Person Object and needed to
assign an instance of a Person to another Person. There was no assignment
method. I asked the owner of the Person Object code if there could be an
assignment operator provided. The response was, "In the real world you can not
assign a person to be another person. I can not add the method, it breaks the
model." <br />
Objects may model a real world entity but they exist in the computer world.
Objects are at least two-dimensional. Objects are made of "computer stuff" or
"computer matter". Objects have their representation of the real world entity
and they have the properties and laws of the computer realm in which they exist.
It is not breaking the model to add methods from the second dimension. The
object has certain behaviors that are fully acceptable in the second dimension
of the computer world that are not acceptable in the real world.<br />
<h2>
Introduction </h2>
Object oriented modeling is attaches behavior to structure. Inheritence is
typically used to model either static subtyping or runtime/behavior subtyping.
Static subtyping is typically used in simple examples of inheritence. Runtime
subtyping is usually more interesting and facilitates polymorphic behavior.<br />
This paper considers object oriented modeling that uses runtime subtyping.
Modeled objects will exist in a computer system and be defined using some
computer programming language. Seems obvious enough doesn't it? <br />
Let’s begin by modeling a person for use in a genealogical system. <br />
A person has a name, a birth place, a birth date, a death place, and a death
date. When you create the object you pass in the birth information. It can not
be changed. You are born in one place at a specific time. The name information
can be changed because in the real world you can change your name. Once the
death information is entered then you can no longer change any of the
information. You are dead and dead is dead. <br />
Let's suppose that the methods are sufficient to model the person and the
system has been in development for many months. During the testing of the system
it becomes apparent that we need a way to generate people objects to drive these
tests. Some of the people objects need to be valid and some need to be invalid
in order to test thoroughly. So you create a Person generator and find that you
would like to assign one person object to another. You need an assignment
operator that can do a deep and correct copy of the Person object. You ask the
owner of the person object to create this method for you and he says, "Sorry, in
the real world people can not be assigned to people. It breaks the model." Since
I am known for my tact my response would be, "I understand completely. Would you
like me to remove the constructor and destructor? Real people are not
constructed or destructed or at least they shouldn't be." <br />
<h2>
Objects are made of Stuff </h2>
Objects are made of stuff. Suppose you make a model of a cube. What are the
properties of a cube? It is a regular solid with six congruent square faces. Are
there any other properties for a cube? Not that I am aware of. Now suppose you
make your model cube from pine wood. Now your cube floats in water. Do cubes
float? This one does. It will burn as well. Suppose you make your cube out of
steel. Now your cube sinks, rusts, and is subject to magnetic forces. Which is
the correct model of a cube? Suppose you make your cube out of ice. Your ice
cube will melt and could be used to chill a beverage. Will the true and proper
cube model please stand up? <br />
Since objects are made of "stuff" they take upon them properties of the stuff
they are made of. The object is subject to constraints of the stuff from which
it is made. An ice cube can not exist in boiling water. The object is destroyed.
When you model something in a computer language the object will be made of
"computer stuff". The constraints and rules of the computer world will act upon
the object. Many of the constraints of the computer world are resource
constraints. There is a finite amount of computer memory. A computer object can
be replicated until the memory resource is exhausted. Similarly I guess you
could say you can make pine wood cubes until all of the pine wood in the world
is exhausted. <br />
A computer object has a lifespan in the computer world. It has a behavior
because it is a computer object. In most computer worlds objects can be
constructed and destructed. Objects can be assigned to other objects. Objects
can be cast into other objects. Objects can be turned into Xml descriptions of
their state. Xml is like the transporter from Star Trek. We take the object, put
it into the Xml pattern buffer and send it across the net where it is
reassembled at the destination. Objects have scope in which they exist and when
that scope is exited the object ceases to exist. <br />
When defining an object be sure to consider that the object exists in a
computer system and that it will need certain behaviors for that existence. <br />
<h2>
"Is A" may be "Is not A" </h2>
In static subtyping the only thing you are interested in are the member
variables and not the methods. In runtime or behavioral subtyping you are only
concerned about the methods and not the member variables. Behavioral subtyping
is used more often because of polymorphism and specified
responsibilities.<br />
The classic example of the "Is A" relationship is the Rectangle object and
the Square object. In "The Liskov Substitution Principle" article found on the
Object Mentor web site this interesting example is explained. <br />
Suppose you model a rectangle object. It has a width and a height and methods
to get and set these properties. Now you want to add a square to the system. You
remember that a square is a rectangle with the constraint that the width and
height are equal. You make sure the methods for your rectangle's properties are
declared virtual and you create a new class called square that inherits from
rectangle. You override the set methods for width and height so that if the
width is changed then the height is changed to be the same value and visa versa.
Now you have a square that can be used where ever a rectangle is used. <br />
Well, we seemed to have forgotten that objects are made of computer stuff and
are manipulated by other computer objects. Suppose you have a procedure that
takes a reference to a rectangle. <br />
boolean ChangeWidthAndValidate(Rectangle &rect, int newWidth) <br />
{ <br />
int height = rect.GetHeight(); <br />
rect.SetWidth(newWidth); <br />
return ( (height == rect.GetHeight() && (newWidth == rect.GetWidth())
); <br />
} <br />
If you pass a square into this procedure and set the width to five then the
square will set the height to five as well in order to maintain its squareness.
Unless the new width is the same as the old width this routine will return
false. <br />
The problem here is behavior. A square object does not behave the same as
rectangle object. The behavior difference is in the SetHeight and SetWidth. In
the rectangle SetWidth only changes the value of the width and SetHeight only
changes the height. For the square if you set the height there is the side
effect of setting the width, and if you set the width the height is changed. So,
the computer square does not behave the same as the computer rectangle. If they
do not behave the same then they can not be substituted for each other.<br />
So, what is the solution? One is to have a property of the rectangle that
tells you if the rectangle is square. If you want a rectangle to stay square
then you can instantiate a immutable instance of the rectangle with the width
and height to be the same. Since this instance of the rectangle is immutable
there will be no behavior available to change the width and height of this
instance and thus it will remain square.<br />
Or another solution could be that you make a square class that does not
inherit from the rectangle class. The rectangle takes two variables for defining
the width and the height. A square only needs one to define the length of the
sides. In this case the computer square is clearly not a computer rectangle.
They don't have the same methods or the same member variables. You can make a
copy constructor that can create a rectangle from a square. The copy constructor
for converting a rectangle to a square would throw an exception if the
rectangle's sides are not the same length. <br />
Suppose you decide to change the ChangeWidthAndValidate procedure to check
the type of the object and have conditional logic for each type of rectangle.
Then you have introduced a maintenance issue through coupling. If you take this
approach you have to ask your self, "Did I find all of the procedures that may
suffer from similar problems?" <br />
Maybe you decide to make every procedure that operates on a rectangle a
method of rectangle so that you can virtualize each one. In this case the
ChangeWidthAndValidate method would be added to the base class and sub-classes
as virtual and the square would override the rectangle's implementation of the
method to correct the validation behavior. This means that you can not have any
procedures that manipulate objects directly. All object manipulation behavior is
part of the class. A class would then model the data, the behavior of the
object, the behavior of any computer world needs, and the behavior of every
thing that can manipulate the object. To ensure that all manipulation behavior
is modeld in the class you can make every property setter private. This solution
is very complicated and would be difficult to maintain or enforce. Think about
all of the classes in your system and all of the sub-classes in the system and
imagine changing every access specifier to private for each method that sets
a property value. How much refactoring would that cause?<br />
<h2>
Conclusion </h2>
Object oriented modeling is more interesting when it is modeling behavior.
There are behaviors that the object will have because it exists in a computer
program. Two well known behaviors are construction and destruction. Java and C#
demonstrate this aspect by having the base class of Object. The class Object
models behaviors that are needed to exist in the computer world. All objects
have this second dimension of behavior because they are made of "computer stuff"
or in other words exist in a computer program. It does not break the real world
model to have the computer world behaviors as part of the class. <br />
Because objects are made of computer stuff they are subject to the rules of
the computer world. The Liskov Substitution Principle is something to be
followed if you want inheritance and virtual functions to behave as designed.
This principle applies to computer realms and not to the real world. It
constrains how we model and forces us to remember that if a method of a subclass
alters the state of the object in a different way than the base class then
polymorphism is going to demonstrate inconsistent results depending on the real
type of an object.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-537179984052937782008-01-21T21:18:00.000-08:002008-01-21T21:22:06.295-08:00Maverick Software Development Model(April 1, 2004)<br /><br /><span style="font-weight:bold;">Abstract</span><br /><br />The Maverick Development Model is concerned with identifying the best practices for a given situation. A model development process is one that produces the correct development process for the current situation and constraints.<br /><br />A model of development differs from development methodologies (such as Waterfall, Spiral, or Agile) in that the goal or desired outcome is the driving force, ever present, and never forgotten. Methodologies are approaches to achieving goals, but to often the reason for the steps of the methodology have been forgotten and no one knows the reason things are done except that the method requires it.<br /><br />There are many good practices that have been accepted over the years and some of them will be presented as well as personal insights and philosophies concerning the software development process and the roles that make it up.<br /><br />It is time for software developers to become computer scientists. The computer scientist is a role that encompasses all of the responsibilities necessary to complete the tasks of software development.<br /><br />It is time for managers to become leaders and to forgo the methods of management that do not improve the development process. The process exists to help the workers and not the other way around were the workers are there to satisfy the process. The tail should not wag the dog.<br /><br /><span style="font-weight:bold;">Introduction</span><br /><br />Since 1987 I have been participating in software development. I have watched the struggle between the programmers and product marketing, where the later sets the features and the delivery date and then complain about the quality, missed dates, or missing features. This struggle still exists and remains basically unchanged to this day.<br /><br />I have witnessed the introduction of management to the software development process. This management consisted of processes with the idea of making the software development predictable, traceable, controllable, and manageable.<br /><br />Several times over my career my various employers have trained me to perform formal reviews and in all of the roles of a review session. At each company, after the training and within a few short weeks, the review process ceased and the programmers went back to their old ways.<br /><br />I have witnessed the acceptance and use of waterfall methodologies and their many variants. I have watched management follow the methodology with only the rigor that a true manager can attain. The requirements were gathered by product marketing and from that a design was made. This design became a hard and fast contract. However the design seemed to be used more as a defense exhibit (CYA) because every product date was always missed and development dragged on with no apparent end.<br /><br />I have watched the release dates for the product set by the next occurrence of COMDEX and not by anything that actually pertains to the development of quality software. I have personally asked for requirements to be updated while in the development stage of the life cycle only to have management say that the waterfall method did not allow you to go back and change anything. I was flabbergasted! "The method doesn't allow" is a statement that just doesn't make sense. A method is not alive and does not make choices or demands. Management didn't allow the change because they didn't understand the goals the method was trying to reach. Management didn't allow the change because they can't change the process because they didn't understand the development process in the first place. As hard as I tried to indicate that changes were needed it was like talking to the wall. Where are we today? I feel we have made some evolutionary improvements that place us at a point to achieve revolutionary improvements. The idea is to recognize goals and create custom processes to achieve those goals for the current situation. One shoe does not fit all.<br /><br />While working for the Department of Energy I struggled with the lack of contact the developers had with the customer. As a developer I felt completely out of touch. I had a written description of what they wanted. The description captured the letter of the law, but I had no feel for the spirit of the law. In 1992 I presented this analogy to my colleagues.<br /><br />"Once there was a famous painter who was retained by the head of a European State. His time was so valuable that there was an assistant assigned to the artist. This assistant was to go out and find work for the artist and to gather the description of the desired painting. The assistant met with a wealthy merchant and convinced the merchant to commission a painting of his son. The assistant promised the painting finished in three weeks and returned to the artist. The assistant described the merchant's son to the artist and the artist painted a young boy in a silken blue suit holding in his hand a hat with beautiful plumage. The assistant took the painting to the merchant who agreed that the painting was exceptional but in reality it did not look anything like his son and that he wanted his son painted with is brother standing in a lane by a tree outside of their home. Needless to say the artist never delivered exactly what the merchant wanted. Each version became closer to the desired outcome but never just right."<br /><br />My argument was that computer programming is only one small piece of the training received at the University. I hoped that we could be more than just a programmer; I hoped we could be a computer scientist. I wanted to apply what I had learned in requirements gathering, systems analysis, effort estimation, and design as well as write the code. However, my skills in writing code were expensive to acquire and my employer deemed my time too precious to be spent doing non-programming tasks that could be delegated to less expensive employees.<br /><br />Also I have dealt with another extreme where managers that thought the developers where "prima donnas" that did not work hard, that waited until the project was well beyond the point of no return and then asked for raises and stock options and held the company hostage. Also the managers thought the engineers padded their dates so they could take it easy. There where managers that said they were sick of the attitudes of the developers and that if they were not happy then they should just leave because they are easy to replace.<br /><br />If it wasn't enough to have managers without any real understanding of how to develop software I have watched developers dup management into believing heroics are required to develop software. Duped into believing that there is only a few that can develop the product and the rest of the developers are to take supportive roles. I have watched these clever developers build empires to protect themselves and become the very prima donnas that management complained about.<br /><br />I have seen excellent developers black balled by these empire builders because the empire builders realized that this person was skilled enough to replace them. I have watched these empire builders wait for a power vacuum to occur and rush in and fill the gap. I have seen them target other developer's features that are late and secretly criticize the developer. Then, while the developer's reputation is in doubt, the hero works many late hours and rewrites the feature and presents it to management who in turn praises their effort and commitment to the company. The other developer is then regulated to a subservient position and is basically layoff fodder for the next round.<br /><br />I have watched managers closely and found that very few managers excel at their task. Why? Leadership was the original goal, and management somehow was adopted. If a manager does not write code then what does he bring to the development effort? I have noticed that most managers consider their job to be reporting state in meetings. Therefore, they are only working when they are generating reports that capture the state of development and when they are in meetings presenting their reports. Managers are rewarded on their reporting skills and thus the amount of reporting grows beyond their ability to control. Then they assign the developers to help by making intermediate reports that will be used as sections in their master reports. Soon developers are spending one or two hours a day generating reports of the current state of the development effort. That state of the project has changed before the report is finished and the report captures only a ghostly representation.<br /><br />In 1997 a friend gave me a copy of "Maverick: The success story behind the world's most unusual workplace. Ricardo Semler. Warner Books. 1993." I never read books on other people's success stories because I always figured that the revenue from their book was their success story. I reluctantly began to read the book and soon found a kindred spirit in Mr. Semler. Everything he said made sense to me, even though his business was in manufacturing. I could see benefits for software development. Eagerly I summarized his book and presented it to management. They laughed at the idea of publicly known salaries. When designing a new workspace for development I suggested that they give the developers a budget and let them pick their desk and chair. They responded that the furniture was an asset of the company and that the developers would pick a hodge podge arrangement that would look terrible. Wow, it was almost word for word from Semler's book when they were trying to select uniforms for their workers. I name my development model after his book, the Maverick Development Model. Mr. Semler has never met me, and the name does not mean to suggest he has supported this effort or endorses it in any way. It is my way of giving credit to one that has inspired and reinforced my ideas.<br /><br />After being formally mocked for presenting the Maverick concept I went about my work trying to inject those ideas into the environment whenever the possibility presented itself. Needless to say, I was more often labeled radical, a loose cannon, and someone that had no idea of how real business works. After several years of frustration I decided it is easier to be quite and draw my paycheck. I lost all love for the software development process and kept my head low to avoid the laser-targeting sights of the layoff assassins.<br /><br />Since I was unhappy with anything to do with the process I focused solely on object-oriented development and how to model systems in a way that the code was easy to maintain and be bug free. Before agile methodologies required unit test I had a personal policy of testing each piece of my code before introducing it in the system. My rationale was, if you don't have any confidence in you own code then how can you determine where a bug lies when you integrate your code with someone else's? I felt each piece of code had to be solid so that you can build upon it. You had to have confidence in some piece of the system; otherwise you will never know if you fixed a bug in the right place. For example, if the compiler is suspect, the third party libraries are suspect, the code from the rest of the team is suspect, and your code does not have some proven level of quality, then when the system fails where do you look for the problem? I have heard "compiler bug" cried probably a hundred times. In all of those, I have seen it to be the case only twice. Why do I share this? Because the evolutionary path that has led us to Agile process and Test Driven Development has be trodden by many of us.<br /><br />This rationale of building on a solid foundation came from a few years of porting code. I have seen the memory manager rewritten too many times. You remember the guys that said, "You can't use alloc, it is inefficient. I read somewhere that you have to write your own to get any kind of performance from dynamic memory allocation." Always the reason was to improve performance. This piece of code then became a roadblock in the porting effort. Also, the code required the complete attention of a developer. I would say, "We are not in the operating system services business. We shouldn't be rewriting what the OS should provide. If the OS is not working, then develop to a better platform and quit supporting this garbage." They dismissed my comments as to hard-line. But I learned that we did not have a solid foundation because of all of the in-house developed services. The core service of memory management was now always a suspect. Many bugs were found in the memory manager. When something didn't work, were did you look for the problem? You had to go to the lowest layers and verify that the memory manager was not the source of the problem. Ironically the memory manager became the bane of the main platform as well. The system was taken to Intel to profile the product and suggest improvements. They pointed out that one of the trouble spots was the proprietary memory manager. It did not perform as well as the standard memory manager provided by the current version of the OS on the current hardware. The reason was that the OS people continued to develop and improve their services and to optimize their services for new hardware. The proprietary version, once debugged, was left "as is" and in a few short years become obsolete for the advances in hardware and operating systems. I relate this story because it is necessary to recognize the facets and subtle interplay in software development that the development process must recognize and support. If the memory manager would have had regression tests then it would not have been a suspect with every bug. If the developers would have delivered on the core business instead of optimizations of OS functionality they would have been better off in the long run. Agile has concisely described this as building the functionality that delivers value first, do it with the simpliest implemenation that meets the requirements, and use a test first design technique.<br /><br />Since those times of which I described there have been some events that have occurred and set the stage for Maverick Development. One is the development of Java. The other is the acceptance of what is now termed Agile Methods.<br /><br />Java has helped by reinforcing my idea that you shouldn't develop services that the OS should provide. This may be termed "don't reinvent the wheel" but it is much more than that. It is about letting others have their core business and trusting that they might be just as smart as you. It is amazing that the developers that were so concerned about performance and writing their own memory manager would ever accept Java.<br /><br />Java was slow compared to anything we had seen for years. So, why did the same engineers that wrote their own memory manager embrace Java? Because, it was time to rewrite the system again or they wouldn't have a job! They had to sell management on another version of the product. They dropped the old buzzwords of web services, n-tier, peer-to-peer, and all the others. Regardless of the reasons the acceptance of Java has opened the door for me to try again to change the way software is developed. I have been quite for too many years. I love software development and it is time to present ideas and hopefully start meaningful discussions that lead to a revolutionary change in software development.<br /><br />Agile methods have really helped in motivating me to gather my ideas and write this document. Honestly I am really shocked that agile methods have been accepted. The agile methods are addressing the same issues I have been concerned with for years. One of which is that of "the process doesn't allow us to go back and change the requirements." Finally in the name of agility you can go back and fix things that are wrong and work in a reasonable manner. But alas, as soon as you specify your ideas as a methodology, and there is some missing step for a specific situation, some manager that only knows the letter of the law will still say, "you can't do that, the process/methodology doesn't allow it." I have been doing research on XP for large teams and XP with Integration Testing. I have found many statements like, "XP doesn't do that" or "XP only does unit testing and Integration testing has to be added in a Waterfall fashion." Why do these managers "lock" XP down? I feel they lock it down because they do not understand the real problems and the appropriate solutions.<br /><br />It reminds me of a 300 level fine arts class I had in college. Being a CS major and having artistic skills are not common and the application of logic to art is probably not something the Art Department was accustomed to. I remember learning of the masters, the great artists that had created a new style and had altered a norm and had become famous for their unique perspective and talent. Then in art class the instructor teaches you how to hold the brush in your hand, how to make the strokes, how to portray depth, how to do each and everything and then grade you on your conformance. If I painted just like Picasso then I would never be famous. I would be another painter that painted like Picasso. I had been taught what made a great artist and then told not to do the very things that made them great. I had been exposed to the model but taught to follow the method.<br /><br />Why do I go into these past experiences? They form the foundation of my reasoning. I have always said, "It takes a village to make a village idiot." Without the foundation of understanding then methods are followed for the wrong reasons. I heard this story once.<br /><br />A woman was cooking a ham. Her daughter-in-law notices that she cuts the ends off of the ham before baking it. She asks why. "Because it makes it taste better." Does it really make it taste better? After some investigation it was learned that the reason why she cut the ends off of the ham is because her mother did the same. The reason her mother did it was because she had seen it done by her mother. The reason the grandmother did it was because her baking pan was too small to hold the ham unless she cut off the ends.<br /><br />Why do software development methodologies have the steps that they do? In the beginning the reason for the method was known. The key is that reason must not be lost and must be understood.<br /><br />As computer scientists, instead of just developers, we have been trained to act in all the roles of software development. If your software process falls short in some area, we can fix it. We can have emergent processes if managers will get out of the way and if developers can wake up and become computer scientists and if we will work towards a goal and take whichever road gets us there. Life may be a journey and the road taken important, but software development is a destination. We have to lay down the pride, we have to give up the heroics, and work as a team. I guess this means we have to understand what work is. We have to understand why methods exist and what goals they are trying to achieve. We have to wake up and be thinking individuals that question everything and that do not want fame for anything.<br /><br />Maverick Development is about goals and understanding. It is about accomplishing the goal the best way possible at that time. It is about changing anything and everything including the way you work, the way you think, and the way you interact with others. It is about removing dead end jobs. It is about real rewards. It is about trust and selflessness.<br /><br /><span style="font-weight:bold;">Work</span><br /><br />Work is something that we all know when we are doing it and we also know when we are not. However, to give a firm explanation of one's work is difficult. Work is physically described as a force applied through a distance. In creative processes there is no physical object to be moved. That is why effort is used to describe creative work. Distance is also a non-physical attribute of creative work. Progress is used to describe this aspect. So, with effort and progress we work.<br /><br />In a methodology, work is anything that progresses from the current step to the next. In a model, work is anything that finishes some attribute or artifact of the goal. Thus said, work on a method is very different than work performed on a model.<br /><br />Traditionally one of the tasks of management is to measure work. The measurement of work is an intrusive inspection that interferes with the work that is being measured. The benefits of measurement should out way the costs of acquiring the measurement. If measurement activities are not worth the effort to perform then why continue to measure in the same way? Think and change it. Make it worth the effort. I often wonder at what point thinking was disallowed. It sure seems like it has been disallowed.<br /><br />Developers are smart and once they learn the rules of a game they try to win. When developers are monitored and their performance measured, they learn to perform by what is measured. If lines of code are measured, you will get lines of code. If number of bugs found is the measurement, they will find bugs. The problem is we have forgotten why methods measure these things. Management wanted to measure quality and then they created a process. Somewhere down the road we ran amuck.<br /><br />The measurement process uses terms like defect discovery rate and whether or not it is decreasing. It was anticipated that if the defect discovery rate is decreasing then the quality of the product was increasing. There are a lot of assumptions here, especially that all bugs are created equal. If one thousand bugs where found and eliminated and the product ships with just one bug and that bug manifests itself you have a problem, especially if that one bug happens to loose and corrupt data.<br /><br />Even algile processes are not perfect. Agile and iterative processes have the expectation of seeing the additions of new code into the product to be rather constant over the iteration. Instead we see that the last three days of the iteration the number of new or modified files in the system increase dramatically. Why? It could mean many things. Managers readily accept conclusions from journals and well-known experts instead learning the current reason behind the problem for themselves. Without the understanding of reasons the ability to correctly apply the lessons of these experts rarely happens. Simply said, "You can't rely on books, papers, and publications to solve your problems. You have to get in there and figure things out for your specific situation and this requires understanding of the process and how work gets done."<br /><br />In reality the check-in rate could be the symptom of any number of problems. Maybe the iteration is to long or the build process is too painful. Maybe integration is too painful. It could be that the Use Cases where unclear and too much time was needed to design the code. Maybe it was dependencies on other modules such that coupling became a bottleneck. This list could go on and on. Most likely the reason is not simple, but is complex and there are many reasons that differ from each team and each person. There is no simple fix and there might not be a complex fix. It might be the fact that this is the way it is.<br /><br />My point is that it takes more than methods and management to understand the development process and to identify when progress is being made and when work has been done.<br /><br />In Maverick Development work is defined to be any task that moves things forward to the ultimate goal. Most processes do not measure time spent helping other team members. Traditionally if help has been given to a team member it is not unusual to label the person that needed help as a weak link. Being labeled a weak link is like putting strawberry jam in your pockets because in the next layoff you are toast. So, people will not ask for help. Is that what management wanted? I doubt it. This is what they get and often they cannot recognize the environment they have created. In Maverick Development helping another developer get work done is work. Helping the team move forward is work. It does not affect the person's task list in a negative way. If the person does not finish their tasks for the iteration yet they worked hard on unforeseen tasks then the person is still successful and considered a great worker.<br /><br />When helping others is not rewarded you will see symptoms of it. You will hear developers say things like, "I didn't get anything done today because of interruptions" or the person that needs help will passively say "I hate to bother you right now for some help but I am stuck" or they will only ask for help through non-intrusive manners such as e-mail.<br /><br />Work together and be concerned for others success. If managers are counting and measuring, then developers will only work on what is being counted. If there is no metric on how many others you helped to be successful today, then no one will help others. Maverick Development demands less measurement OR it demands management to truly measure work, which would be a very difficult task that most managers are not up to. Maverick development raises the bar on management.<br /><br /><span style="font-weight:bold;"><br />Computer Scientist</span><br /><br />The developer has to be more than just a code writer. The bar is raised on the developer. For lack of a better term I say the developer must become a computer scientist. I chose the term computer scientist because during my formal education as a computer science student I learned all the aspects of developing software. I learned about programming languages, algorithms, requirements gathering, quality assurance, effort estimation, software cost, motivating programmers, ...<br /><br />The computer scientist is a leader in the area of software development. The computer scientist understands that heroic efforts can destroy teams and skew business perspectives into believing heroics are necessary. The computer scientist understands when to use multiple inheritance. A computer scientist understands runtime behavior as compared to static behavior. A computer scientist understands the costs of coupling and poor cohesion. The computer scientist understands activities that improve productivity and activities that slow things down.<br /><br /><span style="font-weight:bold;">Management</span><br /><br />First I need to define the type of manager to which I will refer. Historically developers have been promoted to team lead, then manager, then director, and on up the ladder. I have also noted there are two paths to manager. The other path comes from the business side of the company instead of the technical side. In the organizations I have experienced often the manager has a technical role. The manager reviews and approves designs and architectures. Also the manager choses the development methodology, the amount of reporting, the format for meetings and documents, coding styles, and other things that directly relate to the development process. In addition to these responsibilities these managers also perform reviews, do budgets, and report status. The manager often uses the position to inject their desire in one situation and delegate when they have no opinion. This inconsistent use of position is not helpful.<br /><br />Management has to come to its own in the Maverick Development Model. What does this mean? They have to have clear understanding of all of the aspects of development. First they have to understand each individual. Why, because they are managing people, they are not managing skill sets and resources. Everyone communicates in different ways. Everyone expresses concern in different ways. Everyone is motivated in their own way. I would imagine that a good manager , like a good poker player, can read a person as well as listen to a person.<br /><br />Managers have to understand why different methods and practices are available and know which practice to apply to a situation. Managers are too often like the ship's captain that knows nothing about sailing. As long as the wind blows the ship along the right course everything is fine. However, as soon as there is a problem that requires knowing how to control a ship the so-called captain is in trouble.<br /><br />The skill set of a manager has to be greater than the average developer on the team. A manager in Maverick Development must become a leader. A leader is much more than a manager.<br /><br />Patton was a military leader. He did not care if politicians were pleased with him. He did not care if people did not like him. The Vietnam conflict was managed. It was not lead. The difference is clear. The "feeling" about the situation is almost tangible. Vietnam was managed and the methods were political and had nothing to do with winning a war or fighting for values. The managers of the Vietnam War talked in statistics. How many shots fired. How many casualties. How many sorties. How much money had been spent and are we within our budget.<br /><br />From Mr. Semler's book I paraphrase and quote a section concerning management.<br /><br /><span style="font-style:italic;">"...Fernando was convinced that the Hobart plant lacked organization, ambition, and the necessary controls. He would arrive at 7:30 a.m., to find himself alone in the office until about 9:00 a.m. At 5:30 p.m. people would leave for home and Fernando would stay until 9, 10, and sometimes 11 p.m. This didn't please him and everyone knew it.<br /><br />Many others worked long hours too, and their families were beginning to complain. They were convinced that the hours were temporary, until the company had digested its acquisitions. 'It took us almost a decade to learn that our stress was internally generated, the result of an immature organization and infantile goals.'<br /><br />Fernando was firing people and changing things constantly.<br /><br />'At the Hobart plant, and all over the new Semco, we could track with great precision virtually every aspect of our business, from sales quotes to.welding machines. We could generate all sorts of reports almost instantly with dazzling charts and graphs.. (I)t took us a while to realize that all those numbers weren't doing us much good. We thought we were more organized, more professional, more disciplined, more efficient. So,.how come our deliveries were constantly late.'<br /><br />Work hard or get fired was the new motto. Everyone was being pushed forward instead of being self-propelled.<br /><br />'During this time I often thought of a business parable. Three stone cutters were asked about their jobs. The first said he was paid to cut stones. The second replied that he used special techniques to shape stones in an exceptional way, and proceeded to demonstrate his skills. The third stone cutter just smiled and said: "I build cathedrals.'"</span><br /><br /><span style="font-weight:bold;">Leadership</span><br /><br />Maverick Development is based on leadership. Leadership is something above management. All leaders have management skills. The converse is not true. The bar has to be raised on managers. They have to be leaders.<br /><br />Agile methodologies depend upon emergent processes. Managers cannot control this type of process because of its very nature. Maverick Development goes where ever is necessary to get the work done. When an unexpected situation arises we do not plod along the same path just because the directions say to go that way. Instead, in Maverick, we say, "Hmm, an unforeseen problem. What should we do? Go on? Go back? Go around? ... "<br /><br />Leadership cannot be taught. Quoting Dr. Huge Nibley,<br /><br /><span style="font-style:italic;">"At the present time, Captain Grace Hoper, that grand old lady of the Navy, is calling our attention to the contrasting and conflicting natures of management and leadership. No one, she says, ever managed men into battle, and she wants more emphasis on teaching leadership. But leadership can no more be taught than creativity or how to be a genius. The Generalstab tried desperately for a hundred years to train up a generation of leaders for the German army, but it never worked, because the men who delighted their superiors (the managers) got the high commands, while the men who delighted the lower ranks (the leaders) got reprimands. Leaders are movers and shakers, original, inventive, unpredictable, imaginative, full of surprises that discomfit the enemy in war and the main office in peace. Managers, on the other hand, are safe, conservative, predictable, conforming organizational men and team players, dedicated to the establishment.<br /><br />The leader, for example, has a passion for equality. We think of great generals from David and Alexander on down, sharing their beans or maza with their men, calling them by their first names, marching along with them in the heat, sleeping on the ground and being first over the wall. A famous ode by a long-suffering Greek soldier named Archilochus, reminds us that the men in the ranks are not fooled for an instant by the executive type who thinks he is a leader.<br /><br />For the manager, on the other hand, the idea of equality is repugnant and indeed counterproductive. Where promotion, perks, privilege and power are the name of the game, awe and reverence for rank is everything and becomes the inspiration and motivation of all good men. Where would management be without the inflexible paper processing, dress standards, attention to proper social, political and religious affiliation, vigilant watch over habits and attitudes, etc., that gratify the stockholders and satisfy security? ... Managers do not promote individuals whose competence might threaten their own position, and so as the power of management spreads ever wider, the quality deteriorates, if that is possible. In short, while management shuns equality, if feeds on mediocrity... For the qualities of leadership are the same in all fields, the leader being simply the one who sets the highest example; and to do that and open the way to greater light and knowledge, the leader must break the mold. " A ship in port is safe," says Captain Hopper, speaking of management, 'but that is not what ships were built for," she adds, calling for leadership... True leaders are inspiring because they are inspired, caught up in a higher purpose, devoid of personal ambition, idealistic and incorruptible... So vast is the discrepancy between management and leadership that only a blind man would get them backwards... "</span><br /><br />It is a common known practice when hiring and retaining software engineers to retain what is referred to as the 10x performers. Maverick Development requires the same from its Leadership. Managers that are leaders will be 10x performers.<br /><br />Trust is the key and here is what Mr. Semler had to say,<br /><br /><span style="font-style:italic;">"We simply do not believe our employees have an interest in coming in late, leaving early, and doing as little as possible for as much money as their union can wheedle out of us. After all, these are the same people that raise children, join the PTA, elect mayors, governors, senators, and presidents. They are adults. At Semco, we treat them like adults. We trust them. We don't make our employees ask permission to go to the bathroom, nor have security guards search them as they leave for the day. We get out of their way and let them do their jobs."</span><br /><br /><span style="font-weight:bold;"><br />Performance Reviews</span><br /><br />Maverick Development changes the traditional performance review process. The goal is to truly review the performance of the team and the individual. Each person's performance is reviewed by each member of the team and this includes the team leader. There is no protection because of hierarchy, title, or rank.<br /><br />For more information read Maverick Reviews.<br /><br /><span style="font-weight:bold;">Compensation</span><br /><br />In Maverick Development, compensation is public knowledge within the company. Mr. Semler points out executives with high salaries should be proud of their salary and confident that they are worth it. If they are not confident they are worth their salary then they will be inclined to hide it.<br /><br />For more information on compensation please read the section entitled "Compensation" in Maverick Hiring.<br /><br /><span style="font-weight:bold;">Meetings</span><br /><br />In Maverick Development all meetings are to have an agenda that is known before hand by all attendees. The agenda should be concise and if the meeting is to be one of discovery then state that fact.<br /><br />I have attended to many meetings where some important and complex idea is briefly presented and management unexpectedly asks for opinions and if there aren't any they will move to the next topic. This unfair tactic does not produce the proposed desire of gathering more information. Prior to the presentation, management has taken as much time as they saw fit to discuss the matter and formulate their solution. Then they come to a meeting and blind side the entire team with a topic that is usually nontrivial. Do they really expect valid input? It is like they are saying, "Okay you have five minutes, be creative starting now!" Or is it a paternalistic approach and they are satisfied with the stupid looks and blank stares? This approach does not meet any goal and is not part of Maverick Development. Present a decision as just that, a decision. Present a proposal as that and give people time to prepare for suggestions.<br /><br />In Maverick Development there is never a lunch meeting. Lunch meetings are rarely necessary. Downtime is essential, and if you want to have a lively mind for the afternoon then you may want to take a break at lunch. Do you ever feel that lunch meetings are used to squeeze and extra hour out of the day? How often have you attended a lunch meeting and then afterward you still take a lunch break? Any manager that calls a lunch meeting is to be gibbeted in an iron cage outside of the conference room for all to see just like what happened to Captain Kid.<br /><br />The 15-minute standup from XP is sufficient to relay the current state of development. Details are not necessary. If there is a problem, then the details will be addressed by all those who can provide a solution to the problem. If things are on track, no one cares to hear about each item and how "on track" it is. State is the key, not details.<br /><br />It seems that some managers only produce two things that are their work products. One is meetings, the other documentation. Maybe three things, the third being carbon dioxide. The documentation becomes the information presented in the meetings. These items include endless spreadsheets and huge step-by-step procedures on how the process is to be maintained. (Remember in the abstract the comment of the tail wagging the dog!) When a manager is in a meeting he is working. A developer is considered to be working when he is writing code. If a developer is in a meeting he is not working. If a developer is filling out some status report for management, he is not working. When they are doing these tasks, they are doing management's work.<br /><br />The goal for a status meeting should be to determine the state of the project. Not to pour over minute details. The XPM methodology states:<br /><br /><span style="font-style:italic;">"...meetings with the Product Manager and the Steering persons should be context not content. Have the success expectations changed? Is there any change to the scope/objectives? Have there been any changes in the stakeholders/related projects? Are the benefits and cost assumptions still relevant? Are benefits-realization plans still relevant? Has quality been changed? Are there changes to project risk or risk management issues? In other words, is the project still FOCUSED on the right business outcomes?"</span><br /><br />This is a method of achieving the goal of reporting the state of the project. Since Maverick Development is goal oriented, and any method that achieves the goal is fine, then this or any other way to discover the state is within the Maverick model.<br /><br />If there is not a goal, and there is not an agenda, then there is no meeting.<br /><br />In Maverick Development meetings that deal with details instead of status are called by those who can do something with those details. Developers call meetings on details to discuss problems in detail with peers and individuals that can create a solution, not with people that conduct meetings. When managers attend these meetings they try to do the tricks of their trade such as injecting comments to stimulate thought and regulating the conversation to facilitate communication. Stimulate, regulate, and facilitate, and managers hate developers that can't produce tangibles. Go figure.<br /><br />Managers interrogate to find the details of the state of the process. Leaders investigate and recognize on their own. Interrogation is intrusive. It takes to much time. It removes people from their real work.<br /><br /><span style="font-weight:bold;">Documentation</span><br /><br />One reason documentation exists is because someone was trying to meet the goal of communication. Documents are created so that things do not have to be said over and over. Documents state things that are fixed, wrote down, and locked in state, thus the term statement.<br /><br />When documentation does not meet the goal of communication then the document should not exist. If the document is not read then it clearly has not communicated anything and it should not exist. How many of you have ever put some comment in your weekly report to see if anyone was actually reading them? I have and many times I have not received any response from my manager. Clearly that report was not necessary. When my manager is busy doing what he really thinks is important he is not reading fifty status reports. Since in Maverick Development reviews are not done solely from the top down it cannot be said that status reports are required for the review process.<br /><br />One approach that achieves the goal of conveying weekly status is just these three statements: on target, concerned, in trouble.<br /><br />If the state is anything but on target, managers will then ask the obvious question, "Are you taking the appropriate action to rectify the situation?" How many times have managers pointed out the obvious?<br /><br />In Maverick development there is one place to report status. There is not a team dashboard, and a textual weekly report, and a management spreadsheet. There is only one of these items, or some other single reporting method. If someone wants to generate a new report including other items, then they are responsible for the format and media difficulties, they cannot make this an assignment to others. The tail can't be allowed to wag the dog.<br /><br />For more information on documentation please read Maverick Documenation.<br /><br /><span style="font-weight:bold;">Release Dates</span><br /><br />Release dates in Maverick Development are based on real goals and supported by development.<br /><br />In Maverick Development there is no "release date by trade show". How many times have you had a release date for a product set by product marketing to be for the next trade show? Where is the basis on that choice? They will tell you that if you miss that date we will miss our window of opportunity. The ability to market and display a product at a trade show is advantageous. However it is not sufficient to require the release of a product based on date alone. If the original time estimation for the set of features places the release date beyond the trade show then the feature set must be changed to correspond with the shorter development time.<br /><br />Release dates are based on budget, features, quality, and timing. Product management will always try to set the date for release, the number of features in the release and the quality for that release. Well, everyone knows they can only choose two of the three. The third is always a variable.<br /><br />Maverick development says that there are only two choices that are variable and that third, quality, is fixed. You can pick the features or the release date, but not both. Quality is always set at high. That never changes. No one will accept low quality. If you relax quality then you have opened the door for your competition to take your market share by merely reproducing the same functionality with improved quality. You have to have high quality so that the purchase decision is based on such things as features and solutions.<br /><br />In Maverick development a goal can be set to reach a certain point in the production by a certain date. Since Maverick is based on real work, and doing work right, then it really doesn't matter if the date is not met. Work has really occurred and real progress was made. Goals are essential for a target. If the goal is to far out there, it is hard to hit. Should we get down on ourselves if we miss it? No. Why not? Because Maverick Development produces real work every day. In reality software is done when it is done. The scope can be reduced and thus you can be done sooner. Maverick Development supports these simple facts. Motivating development to work hard every day is the responsibility of the leaders of the development team.<br /><br /><span style="font-weight:bold;">Conclusion</span><br /><br />Since Maverick Development is goal driven, the goals for the development process are essential. If a goal for development is to respond quickly to changing requirements then an agile development methodology could meet this goal. If you were trying to get awarded a government contract then a process based on SW-CMM could be the means to the end. Now, one would say, Maverick development is really nothing. It doesn't tell me how to do anything. The point is, you should be a computer scientist and you should already know how to do something or have the ability to learn how to do something for your current situation.<br /><br />Maverick development opens the door for leadership and for understanding why methods exist and the real issues the method addresses. I am currently working on a Maverick Development Methodology for Agile Development. Maverick Development Model means there is a goal to be reached. If the method is not the right one you are not stuck. If you are not progressing, or if there is something missing, or whatever the problem is, Maverick says you must do something about it. You must apply your skills as a computer scientist. You must apply your leadership capabilities. Maverick Development Model addresses the issue of people that live by the letter of the law and not the spirit. It is out of the box thinking, but it shows that you have to have skills, knowledge, and understanding to survive out of the box.<br /><br />Maverick Development demands that people are worth their salt. Reviews are going to happen and you had better be ready. Managers are not protected and leadership is the goal. Managers cannot promote mediocrity in Maverick Development. Managers cannot protect themselves from the movers and shakers. They cannot create empires. They cannot reward those whom please them and remove those whom do not.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com1tag:blogger.com,1999:blog-8390064019981582628.post-6861378987711893462008-01-21T21:16:00.002-08:002008-01-29T07:50:53.433-08:00Software Development Methodology for Large Teams<span style="font-weight:bold;">Abstract</span><br /><br />Maverick Methodologies are guided by these steps:<br /><br /> * <span style="font-weight:bold;">Understand </span>the current state.<br /> * <span style="font-weight:bold;">Identify </span>the areas of concern and set goals.<br /> * <span style="font-weight:bold;">Consider </span>all solutions known or available at this time.<br /> * <span style="font-weight:bold;">Choose </span>a solution that meets the goal which is best for this situation.<br /> * <span style="font-weight:bold;">Act </span>upon the choices and adapt or change solutions when it becomes needed.<br /><br />This methodology, for large teams, was developed under the following situation:<br /><br /> 1. Software and System requirements are not all known in advance.<br /> 2. Customer requires high quality in the first public release.<br /> 3. Team members are not all co-located.<br /> 4. The system is made of many components which are in various layers or tiers thus making integration a concern.<br /> 5. The team is made up of over 40 software developers.<br /><br />The goals are for improvements in these areas:<br /><br /> 1. Requirements and Design<br /> 2. Testing<br /> 3. Build Process<br /> 4. Iterations<br /> 5. Off-Site Issues<br /> 6. Development Platform and Setup<br /><br /><span style="font-weight:bold;">Terms</span><br /><br />2D requirements.<br /><br /><span style="font-weight:bold;">Requirements</span><br /><br />Interviewing to capture requirements as a one time effort has been shown to be difficult and rarely accurate.<br /><br />As recommended by most methodologies, having the individuals that know the requirements (the customer) available to development is currently considered ideal. If development is not restricted to one site then consider training individuals to be a customer representative. These representatives are trained by the customer and communicate often with the customer.<br /><br />Product requirements must be avaible to development. Colocated development can use index cards and tape them to a wall. Distributed teams may choose an electronic medium. Choose a medium that is easily shared and easily updated.<br /><br />The developer requirements must be considered as well. What are developer requirements? The most obvious is that the product requirements can be implemented in software. Other developer requirements may be that the system is testable or the system run on Unix based systems. These requirements along with the product requirements make up what is termed 2D requirements.<br />2D Requirements<br /><br />Suppose the developers are creating an Object Oriented solution. Objects exist to satisfy requirements in two dimensions. The first dimension is that of the real world entity being modeled. The second models the behavior of the object in a computer system.<br /><br />There will be methods that meet the requirements for both dimensions. For example you have an object that models a Car. There may be methods like get the color or set the color. These are methods that have to do with the real world object. But the Car object exists in the computer world as well. And in the computer world we do things like compare objects. You normally don't think about saying, is this car equal to that car. But in the computer system such comparisons exist. Therefore, Maverick Agile Development uses requirements for the real world and well as the computer world and these are called 2D requirements.<br /><br />In Maverick Quality Assurance (MQA) three requirements are identified that are of this second dimension.<br /><br /> 1. Object factories. Object factories are needed by MQA to allow for the develoment of test harnesses, stubs, and mock objects that are needed to develop complete unit tests.<br /> 2. Object Validators are validation facilities that examine an object for comformance with required values. MQA component tests needs object validators to check objects returned from a component call.<br /> 3. Object Equivalence Verifier. MQA tests will need to compare two objects to see if the are the equivalent. A test that needs this functionality would be a persistence test. Equivalence can be a difficult problem to solve (e.g. The Record Linkage Problem) and there may be a valid need to relax the definition of quivalence.<br /><br />Factories, Validators, and Equivalence Verifiers may not be part of the model for the real world object. However, since the object exists in the dimension of a computer system these are necessary requirements that must be met.<br /><br /><span style="font-weight:bold;">Testing</span><br /><br />I was involved in the development of a large software product with a large team using common agile techniques that had not matured for large teams. The development division was doing unit tests (some developers did test first, some code first) and a team of developers under the Quality Assurance division was developing the integration tests.<br /><br />It wasn't long before the integration developers fell victim to "down stream" issues. The product developers where changing things so quickly that the integration developers were constantly playing "catch-up". Also, the product developer's code had functionality that allowed for unit testing but was lacking functionality for integration testing. The integration developers could not get product developers to add functionality to help with integration tests. Ideas such as making integration developers into customers so that they could drive product requirements was considered.<br /><br />The solution I propose is that having those with the domain knowledge perform all white-box tasks instead of an external team. With the requirements continuously being refined, and the design emerging, the transfer of this specific knowledge is too expensive. The product developers don't want to slow down to help or train the integration developers. Therefore, product development is responsible for unit tests and integration tests.<br /><br />Many unit tests can be reconfigured to be component tests. If stubs of a unit test are replaced with real components then the test is now exercising the integration of multiple "real" components. Because of this, component tests are more of a build/configuration issue than a seperate issue from unit tests.<br /><br />A system is integrated when no mock objects are used in the build and the system passes all of the component tests.<br /><br /><span style="font-weight:bold;">Continuous Build</span><br /><br />During the development of this large system using many developers it became apparent that there were issues with the continuous build process.<br /><br />The goal of the continuous build is to present a version of the product that is always functioning correct for the features implemented. Another goal of the build process is to eliminate broken builds at the main repository..<br /><br />This presents a particularly difficult task when the team is large. If a developer updates code from revision control he may only get part of the files of a large "check in" that another is currently submitting.. Transactions are needed to prevent getting only part of the files of a large commit.<br /><br />Long running tests cause developers to save up their changes inorder to avoid the wait. When one waits to commit changes increase the conflicts with other changes and cause the developer to get caught in a refactoring frenzy. Since files are changing so often it requires the idea of relaxing the constraint of developing from the "head" of the revision control system.<br /><br />I suggest code is always updated from a good build which is labeled as a specific revision. The negative thought comes to mind that people will be working on "stale" code, but on a large team with many changes the code is stale so fast it doesn't matter when you get it. One reason to get from a revision is if the "head" build is broken and you have made changes and you want to update your local code to do a build and run the tests locally before you commit changes. If you update to a broken build you will have to wait until that build is fixed, or rollback to a good revision, or worse yet you don't notice the build was broken when you updated and you think that your changes have broken the build.<br /><br />Other processes for updating and committing code can be used. A patch process can be used where the differences of the local files are sent to a build machine and that machine builds the system and if it compiles and passes the tests it is then committed to the "real" build machine (the machine that has the revision control repository). This process can take a long time to perform. On large systems the setting up of test data can take several minutes and the running of all of the tests could be a significant amount of time as well. If you are trying to commit a change that another team member is waiting on it could be a few hours before the changes propagate through the process.<br /><br />The continuous build must be as fast as possible. Distributing the build process can help with a patch process. Each feature team (or some topological division of the developers) has a patch build machine. But that alone is not enough. To improve turn around time the builds themselves have to be changed. The ideal is to have a build for a large project (which includes running tests) be no longer than 15 minutes. Doing a clean build in the continuous build process takes to long. For large teams a clean build is done every fourth build or every hour. Interim builds are not clean builds. In the interim only changes and their dependencies are built.<br /><br />A goal of the build process is to eliminate broken builds. Before submitting changes to the build process the developer should get an updated version of the system and build it locally and run the tests. Usually this local build would not be a clean build. If the build process is fast enough this step should be eliminated. In Maverick Development you do whatever moves you down the road, and if there no need for a step you eliminate it. This is built on the idea of being a thinking individual that understands the ramifications of decisions and that the individual is concerned and will not do anything to interfere with another team member's ability to work. So, if the build process is a patch process and it is fast enough the local build is redundant.<br /><br /><span style="font-weight:bold;">Iterations and Increments</span><br /><br />The goal of incremental development is to always provide an improving product. Improvements are not limited to added functionality alone. Improvements in quality or performance are valid as well as anything else that is a real improvement.<br /><br />For large teams iterations are no more than 3 weeks. It is about planning, refocusing, refactoring, and staying on target. Any more than three weeks is too long to readjust. If there is a concern that the iteration planning takes to much time or is too expensive to do every three weeks, then the way the planning is done needs to be improved.<br /><br />There is some overhead in pulling everyone together. If the Maverick Development Model is followed and meetings have goals reflected by agendas and the meeting will be as optimal as a meeting can be. Maverick development is based on an idea that software is done when it is done and there are at least a certain minimal number tasks that will be performed before the software is done. Since these essential tasks will be done no matter how long the iteration it does not slow the development momentum to have short iterations.<br /><br /><span style="font-weight:bold;">Offshore/Offsite</span><br /><br />If offshore/offsite teams are used in the development, the iterations are two weeks or less. This increases the communication to a level that is needed for redirection. The problem is that offshore teams suffer from poor communication and may get off target and no one knows until it is late. The method is to use an iterative approach where there is always a working subset of the product until it is developed entirely. With shortened iterations you will be able to use the iteration to quickly see if the offshore team is working as planned and if not to make a course correction. Like other agile methods, this depends on the other processes of the methodology in place. The continuous build is essential for this to work. The offshore team must be working from a shared source base and a patch process will address the build needs for a distributed work force.<br /><br /><span style="font-weight:bold;">Development Platform</span><br /><br />One goal for large development teams is to keep developers up and working and to get new employees setup quickly. While working on this large project I quickly noticed that some developers were using Windows based machines and others were using Linux based machines.<br /><br />I recommend the development machines should be setup the same, using the same OS, same versions of the SDK and such, same versions of Ant, Bash, etc. It becomes an unnecessary burden to manage special shell scripts and suttle differences of each platform and configuration.<br /><br />There is an argument that if the product is going to be delivered on multiple platforms and configurations it is good to have such platforms and configurations spread about development. This is where Maverick Development comes in and says "Why?" One of the most prevalent arguments for having the various machines is to detect any problems with the product running on the different configurations. That is a valid goal, but the solution of having developers with different platforms and configurations is not satisfactory for large teams.<br /><br />With large teams the different development platforms typically find problems with the build process, not the product under development, across the various platforms. The problems with the build become the predominant issue with the different platforms instead of finding issues with the product deployed on various machines.<br /><br />The configuration of each development build should be the same. The location of items on each machine should be the same. The environment variables and paths should be the same.<br /><br />If the product is to be deployed on differing systems then the continuous build process should build the product on each varied system. The various platforms that will host the product will be maintained by those in charge of deployment tasks. They will keep the various platforms configured and working. Problems that have to do with code will be brought to the attention of the developers. Problems that have to do with configuration and deployment will be handled by the deployment team. The build will be run continuously on all the platforms and any broken tests will be addressed by development. If a particular platform is becoming problematic then maybe it is good that it was discovered early and you can eliminate that platform from the list of supported systems.<br /><br />Having an exact setup of the desired deployment environment is not usually possible early on in the development of the product. Bringing the various systems on line is dictated by driving forces such as budget, schedule, hosting facilities, and other important decision factors.<br /><br />If the configuration is standard then new employees can receive an "image" that can be easily installed. If a developer's machine experiences hardware trouble the machine can be restored very quickly to a usable state. With the same setup on each machine it is easier to do pair development. The difficulties for large teams are enough and we do not need to add unnecessary difficulties with various configurations.<br /><br />Note if the development is in a language like C++ and there are multiple target platforms development will need to have access to these platforms continuously. Languages that have compiler directives and the ability to conditionally specify code for compilation (#ifdef comes to mind) require that the tests be ran on each target platform in order to catch compile time errors. The continuous build process becomes more complicated as well. An important aspect of this methodology is that there is no porting team. The developers are responsible for their code to run on every supported platform. This will give many benefits. One is that they will not write the code in an optimized fashion for their preferred platform. Another is that you do not have two different individuals working on the same code that might interpret the requirements in subtly different ways. When organizing the teams and if continuous pair programming is used, then wisely pair people with experience on different platforms.<br /><br /><span style="font-weight:bold;">Conclusion</span><br /><br />Using incremental development and iterations for large teams pose specific issues. Working in such a situation I observed that requirements, integration testing, continuous builds, iteration duration, and machine configuration needed specific recommendations.<br /><br />Developer requirements must be considered just as customer/product requirements. Making the system verifiable is a developer requirement. Using object factories, object validators, and equivalance verifiers are part of developer requirements. These developer requirements are another dimension of requirement and are referred to as 2D requirements.<br /><br />All white-box testing should be done by the product developers. This includes component and integrations testing.<br /><br />Continuous builds become more complex with a large number of developers checking in many changes across many files. The "head" of the revision control system may not be "working" at any given instance. Patch processes and lables are used to help alleviate developers from getting a broken build.<br /><br />Iteration length should be no more than three weeks and if parts of the team are off-site then two weeks is recommended as the maximum duration.<br /><br />Developer machine configuration becomes an issue with large teams. Each developer should use the same configuration and directory layout. This allows others to easily pair or use someone elses machine. It also allows for the use of an image of the development setup which can be used to setup new developers or restore machines if there is a crash.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-9750455968790668162008-01-21T21:16:00.001-08:002008-01-29T08:00:52.186-08:00Hiring and Firing<span style="font-weight:bold;">Abstract</span><br /><br /><span style="font-weight:bold;">Hiring a developer</span> is a complex task. To hire the best person for the job you must <span style="font-weight:bold;">understand what job there is to be done</span>, which <span style="font-weight:bold;">level of computer scientist is needed</span> for the job, and what <span style="font-weight:bold;">level of compensation is fair</span> for doing the job.<br /><br /><span style="font-weight:bold;">Understanding the Job to be Done</span><br /><br />A clear understanding of the job is essential. This means that the requirements are known and specified as far as possible. This has little to do with the development methodology. I am not talking about big upfront design versus iterative or agile approaches. This has to do with a level of understanding of what is to be built.<br /><br /><span style="font-weight:bold;">Level 1 Understanding</span><br /><br />This is an idea by a non-computer savvy person. This is when someone says, "I have this idea about a computer program that I want developed." If you ask them, "What platform does this program need to run on?" and they say something like "Windows", did they really mean Windows or did the mean in a Web Browser. This person has no idea of how long it takes to write software and what the expense can be.<br /><br />Level 1 understanding requires an Architect level computer scientist. One that understands desktop versus web based solutions. One that can gather requirements, use cases, user scenarios, and design the software and select the development environment and the deployment environment. The correct computer scientist for this job will also understand cost estimation, effort estimation, strategic planning, testing, and all of the other aspects of delivering quality software.<br /><br /><span style="font-weight:bold;">Level 2 Understanding</span><br /><br />This is a person that is computer literate and has an idea for a software product. They are aware of which computer platform on which they want the software developed. They do not understand the cost of software development. They do not know about development platforms, computer languages, open-source solutions versus major vendor solutions. They have no idea that runtime licenses can be hundreds of thousands of dollars.<br /><br />Level 2 understanding also requires a Senior Developer or an Architect. This computer scientist is a specialist on the platform that is required. The computer scientist understands the current solutions, tools, and resources available on the specified platform.<br /><br /><span style="font-weight:bold;">Level 3 Understanding</span><br /><br />This is a person that is familiar with software development and has experience in the area. A Product Manager is typically at this level. They are aware of customer needs so the requirements will be specified. They have experience with developers and are aware that estimated dates are rarely accurate and that costs often overrun. They know of these difficulties in software development but they do not fully understand why they occur. They know of the levels of computer scientists and are capable of deciding on which level is appropriate for the task at hand. They are familiar with the capabilities of junior developers, senior developers, architects, and the other roles of software development.<br /><br /><span style="font-weight:bold;">Level 4 Understanding</span><br /><br />This is a person that understands the product to be developed and the details of software development. A Project Manager is typically at this level. This person maybe a former software engineer that has taken a management path in their career. This person could be very current in issues even at the level of writing code themselves, or they maybe a few years removed from the cutting edge development practices but still are in touch enough to walk the walk and talk the talk.<br /><br />They know what the job is and what type of person they need to perform the task.<br /><br /><span style="font-weight:bold;">Level 5 Understanding</span><br /><br />This is a person that could do the job. They are typically team leads and senior developers. They are hiring because they do not have the time to do the task themselves. They know exactly what they want. They could do it themselves if they just had the time.<br /><br />Knowing your level of understanding is the first step. It is crucial. Those that deny the facts of their understanding will soon learn from the school of hard knocks. Ignoring your level of understanding is the first step that can lead to failure.<br /><br />A word to the wise computer scientist comes to mind concerning the point of the employer recognizing their level of understanding. If you find yourself working for someone that you thought was at level 3 or higher and you find them at level 2 or lower you are in for a rough ride. They will not understand why you make requests for resources. They will make decisions purely on rules of budget even if you know the decisions will lead to complete failure. You will have to do something and do it quick. What is that something? You have to educate your employer in software development. Most likely it will not be possible. The employer will view your tactics as a means for you to lengthen your task to take the pressure off of your self. All I can say is good luck. Maybe luck will be with you and your employer will know another computer scientist that they trust which will back you up. I use the word trust here because in Maverick development you will find trust is the key to success. The lack of trust leads to many of the problems in business.<br /><br /><span style="font-weight:bold;">Hiring within your Level of Understanding</span><br /><br />If you are not at a level 3 understanding then you are at greater risk of not knowing a good programmer from a bad one. Even if you are a level 3 or higher the risk is still there, it is just lessened. As Dirty Harry said, "A man has got to know his limitations." Once you understand this you can then work better. If you don't understand software development then you have to apply your resources and common sense. What are some of the "common sense" things to do?<br /><br /><span style="font-weight:bold;">Allow someone else to make the hiring decision for you.</span><br /><br />Find someone that is at level 3 or higher. Do you know anyone that has hired successfully in a software development situation? Go through a staffing agency. Use a head-hunter to find someone for you. Hire a consultant to gather the requirements for the task and from these requirements then you can create an accurate job description.<br /><br />Allowing someone else to make the decision is kind of like the chicken and the egg problem. In this situation it goes something like this. I do not really know what type of computer scientist I need to hire. I will consult with someone that does understand the job. How do I select this consultant? Since I do not understand the problem enough to do the task myself how will I know if the consultant I select really knows what they are doing? So now I need another person that understands how to choose a consultant. You eventually have to trust someone to do their job. Once again you can do some simple things when selecting a consultant. You can talk to their previous clients to ascertain their level of satisfaction.<br /><br />If you are at level three or higher then you may decide to do the hiring yourself. Many at this level will have trusted relationships with staffing agencies and head-hunters to do some of the initial work.<br /><br />Even level three's and up can review and improve their hiring process. Maverick development is about getting the job done. Traditional methods are not sacred. Methods that work for the task at hand are more important that organizational policies and former practices.<br /><span style="font-weight:bold;"><br />During the hiring process you must:</span><br /><br />1) Define the job requirements<br /><br />2) Define the employee arrangement (full-time, part-time, contract, on-site, off-site)<br /><br />3) Interview with the purpose of discovering skills and talent that is relevant and pertinent.<br /><span style="font-weight:bold;"><br />Specify the Job Requirements</span><br /><br />At level 3 the defining of the job requirements are at risk of being overly constrained in some areas while being to general in others. For example, the job requirements state that the candidate must have six years Java experience and three years database experience. Many times the language requirement is over constrained. As a senior computer scientist I know that the time it takes to switch from C# to Java is measured in a few days. The time it takes to go from Java to C++ is measured in weeks. So the real job description might say "Six years of object oriented development experience using abstract classes, interfaces, and virtual methods. Java knowledge is a plus." The requirement also says three years database experience. This is typically too general. Database setup and administration varies greatly. Is it an embedded solution? Are stored procedures necessary? Is it an SQL based solution?<br /><br /><span style="font-weight:bold;">Full-time, Part-time, or Contract</span><br /><br />When defining the hiring arrangement be accurate and honest. Too often games are played with peoples careers. If you need a contractor for only six months then hire a contractor. Don't hire a developer full-time with the intent of down-sizing the operation when the software is finished. Full-time "types" are not smarter than contractors. There are many of the best talented computer scientists that enjoy the freedom and diversity of contracting. Also, their experience in specifying the entire gamut of issues in software development may make them more valuable to the level 1 and 2 employers.<br /><br />Also, be accurate and honest by hiring a full-time employee when that is the desired goal. Hiring contractors or converting your full-time staff into contractors in order to re-arrange expense reporting maybe advantageous to a business in the short term it will not be so to your employee base in the near term. If you hire a contractor and treat them as a full-time salaried employee they will not be satisfied. They are hourly or task paid. They will not work 60 hours a week when they are hourly and you pay them for 40. It is not right to even ask them to do so. In the other situation where you take your full-time staff and convert them to contractors you can not expect them to be satisfied. Computer scientist that like full-time employment enjoy the opportunity to grow along career paths specified by the employer. Their benefits and salary are at a rate that justifies working without punching a clock. This means there will be long days and their maybe some short days, but on average every day is a busy day.<br /><br />When hiring a contractor remind yourself that this is not a hard goods manufacturing process but it is the development of software. There is no parts list or building plans unless you are at level 5. The low bidder will not necessarily be the cheapest path. Every software developer knows that once you have started a task it will cost an extreme amount of money to switch horses mid stream. Suppose you hire a software developer and they have spent one year writing code. You are frustrated because the software does not do what the software developer promised it would do by this time. If you fire the software developer it could take one quarter of the time already elapsed to come to an understanding of what is already developed and how to proceed. In this example that would mean three months of absolutely no progress to the end solution. What if you don't fire the original software developer? Maybe they are about finished. It comes down to a matter of trust. Is this developer in over their head? If you are level 3 or lower how would you know? Maybe they are dishonest and are simply wasting your time and money. Everyone knows in software development the ploy of the lowest bid. They know that the employer will be familiar with the costs associated with switching developers mid-project and that the employer will avoid this choice at nearly all cost. So the unscrupulous contractor will bid eight months knowing full well that their true estimate is one and a half years.<br /><br /><span style="font-weight:bold;">Interviewing with a Purpose</span><br /><br />Interviewing with a purpose is so fundamental you would think it wouldn't need to be stated. However, the way companies interview programmers vary so greatly I feel that a little refresher course is needed.<br />Consider the Person<br /><br />The first thing you need to consider is the person. That is what you are hiring. The computer scientist is more than just a brain with hands that can type. Finding a person that fits the company culture is extremely important. Consider this analogy of buying a pure-bred show dog. Let's consider one of my favorite breeds the Australian Shepherd. You want a dog to win best in breed and in agility trials. You have a choice of a dog that does not meet the breed standard and is completely trained in the agility course and a dog that is near ideal to the breed standard but has not been trained in the agility course. These are your only two choices. Which dog do you buy? The dog that fits the standard because you can take the chance on training it in the agility course. The other dog can not change its looks. If you have a candidate for employment that is extremely talented but does not fit in or work well with others and you have a candidate that works well with others but lacks experience which do you hire? I would say the one that works well with others. If it is an out-sourced contract position this analogy will not be as pertinent.<br />Consider the Skill Set<br /><br />After considering the person you must consider the skills and knowledge. This is where I feel many companies do not give due diligence in the hiring of computer scientists. What would be the ideal way to discover a developer's skills? Have them develop something. You know what task that you want them to do. Devise a thin thread of functionality, or some key part of the system, and have them implement it. Have a development machine setup. Have current books available. Online documentation. Access to the internet. Let them bring their laptop and any books they want. Give them the task to do and leave them to do it. No time constraints. They know to do it as fast as possible. If you have a coding standard, give them an easy 1/2 page abbreviated version of it to follow. Really test them. If there is some IDE or code tool that they prefer to use, allow them to install it, to go home and get it and reschedule for the next day. If you are going to pay this person a professional salary for years to come, what is the worth of the time to let them really show their stuff? Remember, good programmers are not necessarily good interviewers or good speakers or have developed social skills.<br /><br />The same goes for hiring an architect or designer as it does for a developer. Have them do something associated with the position to be filled. Have them design a system and talk about the deployment issues. Have them role play and you be the customer and let them try to discover requirements and use cases. Maverick development is about understanding what the end goal is of a method. If there are other ways of achieving the end goal then those methods can replace the current method. The end goal in interviewing is to discover the best candidate. Do what ever it takes to discover this.<br /><br /><span style="font-weight:bold;">Have them Present their Results to the Team</span><br /><br />After you have narrowed the candidates down to the best of the best have them come in together for a different phase of interviewing. In this phase they will talk about the solution to the development problem you gave them earlier. Have each of them in front of the team and the other candidates present their solution and talk about it. Question them all and let any that want to answer speak up. If someone is quiet then single them out and ask them directly for their comments. Then have the interviewers and the interviewees rank everyone that interviewed. Yes, have them rank their competition. This will reveal a lot about each candidate.<br /><br />It comes to mind that there may be some issues with each candidate meeting with the other candidates and their discretion. What if two of the candidates are from the same company? What if one of the candidates is personal friends of the manager of another of the candidates. Once again it is a matter of trust and this trust is that these final candidates have and honor professional ethics. If you can't have the ideal situation with them all together then Maverick development says do the best you can. Use your imagination and talents and come up with an alternative approach that meets the goals of discovering a person's talents and skills. I cannot specify all of the possible scenarios that can occur in a paper or even a book. In the end it is up to you to be up to the task.<br /><br /><span style="font-weight:bold;">Preconceived Notions</span><br /><br />Preconceived notions or implanted notions are extremely powerful. That is why they play such a significant role in philosophy and reason. If you have a particular notion about a candidate before you interview them it will be nigh impossible to not bias everything concerning the candidate through the affects of that notion.<br /><br />One example is poisoning the well. If an employee poisons the well for a candidate and this employee would be working with the candidate then you have to step back and think. Remember thinking on your feet is allowed in Maverick. Why would this person not want the candidate to be hired? Are there real professional reasons? Maybe there are. Maybe there are not. Maybe the person has another candidate that they want to be considered and do not realize that their personal agenda is overwhelming their actions. You have to deduce the answer to the old "what's in it for them" question if you do not hire this candidate. If the things that are in it for them are all business aligned then the comments are appropriate, whether they are accurate or not remains to be known. It seems philosophy here comes to play and the lessons in fallacies. Poisoning the well is one of many fallacies that reveal what I think is human nature to try to convince people that your opinion is correct at all cost including throwing out reason.<br /><br />Sweetening the water. I don't know if this term is reflects what I want to say. It is basically the opposite of poisoning the well. If a recruiter is sweetening the water and saying, "This is the best candidate for the job you will ever find" you have to ask yourself what is in it for the recruiter? Is their a conflict of interest here? The recruiter doesn't get paid unless you hire one of his candidates. It also implies that unless the recruiter gives this glowing testimonial about every candidate that he refers then those without the testimonial must be mediocre.<br /><br />Preconceived notions seem to be the core of a long used interviewing tactic I refer to as tricky questions.<br /><br /><span style="font-weight:bold;">Tricky Questions</span><br /><br />Tricky questions are built upon preconceived notions. I have heard it said about tricky questions, "I like to ask impossible questions. Stupid people will just stare at you." Really. Maybe this stupid person is saying to themselves, that is an impossible question and this interviewer has not shown me any reason not to believe they are an egocentric idiot. Only people that are having their first few interviews in life are surprised by all of the methods and tactics employers use to try to discover talent. If a seasoned professional looks at you like you are crazy for asking an impossible question then maybe you should ask, "Why do you feel this question is inappropriate?" Maybe the candidate is feeling that they have a tremendous set of skills and you haven't even begun to discover them. So, maybe you should ask, "Ok that question is difficult, and you seem impatient about using valuable interview/first impression time on that question. Is there something you would like to say to let me know concerning your skills and problem solving abilities?" There is little need for clever tactics or tricky approaches. Get to the point.<br /><br />Why do interviewers ask these tricky questions? To determine if you can think. I think it would be fair if the interviewee could ask the interviewer some tricky questions as well. The boss should be as smart as the employee. Isn't it amazing that you can lose a job opportunity because you don't know why man-hole covers are round! My point is the value of the question is not properly weighted. Maybe a better question would be something to do with the programming task at hand, like, "what are the trade-offs of shared memory versus a messaging system?"<br /><br />Also questions concerning development commodities are of little use. For example a question like, "How would you write a qsort" is not relevant when sorting is an IT commodity. You wouldn't write a qsort unless the one you where using didn't meet some criteria. Then, you would studying an algorithms book for a bit and decide what type of sort was needed, and then if it is a qsort then implement one by applying the collective knowledge of the algorithms text, the internet, etc.<br /><br /><span style="font-weight:bold;">Compensation</span><br /><br />After you have selected a candidate prepare to compensate them in a rewarding way. One of the many things the Boy Scouts of America teaches the volunteer leader is the value of rewards and the motivating effect it has on people. It would definitely add skills to every manager to volunteer as a Scout leader. Maverick development tries to emphasize the difference between management and leadership and the Scouting program is an example of this.<br /><br />Compensate the new hire well and use your head when doing so. Suppose you have 75K budgeted for the hire. Offer them 70K and a 5K bonus if they will stay on for at least a year. Or, maybe offer them a 3K bonus and then save the other 2K to give to them during the year as they mature into their position. Use your head. Make the most of the rewards. Start the new hire with 1/2 of the annual accrued PTO immediately available. Give them a pay-scale and range of titles and such so they know where they are and how the can strive for more. Actually tell them your expectation of when they should have achieved a promotion.<br /><br />In the review process don't tell them, "No one gets the 'Exceeds Expectation' status, it is only there to drive you." How will that drive a logical person? If "no-one" ever gets it then I will never get it. What you do say is that last year six people received the exceeds expectation status and here is what they did!<br /><br />Compensate them with knowledge and training. Let them have $500.00 budget for any books they want. Also, find conferences or user groups or something for them to attend every year. There are so many local area users groups that long distance travel may not be necessary. You don't have to "make them happy" you simply let them be happy. You say, "Why make them happy unless they deliver." If you say that then you have missed the point.<br /><br /><span style="font-weight:bold;">Firing an Employee</span><br /><br />And what goes with hiring that is never talked about? Firing. How do you select people from your software development department to be fired, laid off, or what ever term you want to use. (Isn't it amazing how people come up with substitute words to describe undesirable things?)<br /><br /><span style="font-weight:bold;">Three Steps to firing.</span><br /><br />1) Make sure the review process is fair and functioning. Maverick Development proposes that reviews are done by every person on the team and they review the others and their managers. The results are posted and are known company-wide. If a person receives a bad review then they have the right to pull all of the reviewers together and discuss the situation. Why? This does many things of which one is that the person doing the review is serious about their statements and another is that misconceptions can be faced openly and the opportunity for improvement is provided.<br /><br />2) Make sure you address the issues and concerns of the employees. I know a developer that was to be fired. My manager told me that since I was the team lead it was my responsibility to let him go. I said that he is a fine worker and I see no need to fire him. The manager said that this employee never got anything done. I asked the employee what he needed to finish his tasks. He said, "Two weeks left alone without interruptions." The manager said that he could have his two weeks, but that this was a probation period. I watched very carefully during the two weeks. The manager continually interrupted this employee. He gave him side tasks. The manager used him as a sounding board for varied topics (because the employee had a vast amount of experience in many areas). The employee lost on average two hours a day. At the end of the two weeks the employee wasn't finished. The manager said to me, "We have to let him go, we gave him what he asked for and he still did not deliver."<br /><br />Most of us know what we need to do our job. If you ask us what we need and then you don't give it to us then you might was well fire us because we are going to quit anyway. No one likes to be setup for failure. When you ask an employee what they need to get the job done then you can evaluate and say,"Ok, I can give you what you request, but this is critical and your job is on the line." Or you can say, "What you ask for is not normal or reasonable, I can get Joe Schmoe to do the same task without these additional resources. You are not the right person for this task. I am sorry." But be fair about this, if Joe Schmoe comes in and takes the task and then doesn't deliver you have to let Joe go as well. You can not allow someone to undercut someone else and then not deliver. It is never acceptable.<br /><br />3) Don't turn on the employee when you have to let them go. Games like, "If you sign this paper that you will not sue us then we will pay out your vacation." Well, I wasn't thinking about suing before, but now I am. Also, when you let someone go you can not expect to dictate to them where they can work. "Sorry we have to let you go. Remember you can not work for any of our competitors for three years." This engineer has worked and developed a very specific set of skills while in your employment. He is not going to have up to date skills in areas other than those that are business related. He has to be able to provide for himself and most likely a family as well. The intellectual property is all that you own. You can't let someone go and then tell them who they can or cannot work for.<br /><br /><span style="font-weight:bold;">Conclusions</span><br /><br /><span style="font-weight:bold;">Understand the job</span> to be performed and <span style="font-weight:bold;">hire the correct person</span> for that job. <span style="font-weight:bold;">Don't</span> hire an architect when you need a junior programmer. <span style="font-weight:bold;">Understand yourself and your ability</span> to select software developers. If you do not understand software development then you are at risk of being duped by an employment candidate. Allow someone that does understand software development do the hiring.<br /><br /><span style="font-weight:bold;">Before </span>you can interview you must <span style="font-weight:bold;">define </span>the job requirements, select the employment type (contract, full-time, etc), and devise an interview plan that will allow you to discover if a candidate is qualified.<br /><br /><span style="font-weight:bold;">During </span>the interview process allow them to <span style="font-weight:bold;">perform tasks that are relevant</span> to the job. Allow developers to write code on a computer using the tools of the trade. Allow architects to design something using the current methodologies. Have them perform a representative set of tasks aligned around the job requirements.<br /><br />Avoid tricky questions like "why man-hole covers are round". Why, because they are loaded with preconceived notions that all programmers that are good know why man-hole covers are round.<br /><br />Avoid questions concerning IT commodities such as sorting routines. Few developers write sorting routines anymore. If a developer is faced with this task they will definitely use reference materials to come up with a proper solution.<br /><br /><span style="font-weight:bold;">Understand rewards and compensation</span> and how to use it to the company's advantage. If you have $75,000.00 budgeted for the new hire, set back $5000 of it to use for a bonus and make sure you give the bonus for some reason or another. Not giving the bonus is not an option. Use your compensation wisely.<br /><br />Use an open review policy that allows everyone to review the others in their group and their chain of management. Do not have impossible grades in the review process. If no one every gets the grade "Exceeds Expectations" then why would any logical person strive to earn that grade. Give examples of people that have earned the highest grade and what they did to earn it.<br /><br />When firing an employee it becomes clearer that the choice to fire is correct if the review process is in place and is working. When someone has to be fired do not treat the person as an enemy of the state. It is amazing how it is one big family when they hired you and now it is business when they fire you. Try to leave a positive impression on the person. Their morale is crushed. This may mean months of unemployment and struggle. Pay them their vacation without strings attached. Don't try to tell them who they can and cannot work for either. You have surely secured your intellectual property and that is sufficient.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-33323326529792744642008-01-21T21:15:00.000-08:002008-01-29T08:09:57.153-08:00Maverick Review Process<span style="font-weight:bold;">Abstract</span><br /><br />The Maverick Review Process is a method in which<span style="font-weight:bold;"> each person reviews those that affect or are involved with their work</span>. Also an individual evaluates each department of the company. <span style="font-weight:bold;">There are no evaluation levels that are unattainable</span>.<br /><br />The <span style="font-weight:bold;">Maverick Review</span> Process is <span style="font-weight:bold;">not</span> the <span style="font-weight:bold;">same as 360 Degree Reviews</span>; however, as with most review processes there will be similar aspects.<br /><br /><span style="font-weight:bold;">Introduction</span><br /><br />As with any Maverick approach one of the first things you should do is ask yourself, "What are the real goals of the review process?" Maverick Reviews identify the main goal of the process as being the improvement of the team. Another goal of the review process is to recognize an employee's performance.<br /><br />Maverick approaches include the idea that salaries are known throughout the company. If you do not adopt the "known" salary policy you can still use Maverick Reviews. In justification of the "known" salary policy consider it thusly; simply stated everyone should be proud of their salary and feel they are worth receiving it, if not then they should consider if there is fairness in their workplace.<br /><br />The Maverick Review process is different than 360 degree reviews. Granted there is no standard for 360 degree reviews, therefore one may exist essentially identical to the Maverick approach. Unlike the Maverick Review Process, 360 processes are typically managed and controlled by HR in a rigorous fashion. 360 reviews are setup and determined by management. Since the 360 review is complex and requires a significant amount of time to perform the process can not be continuously performed. 360 reviews are often driven by a questionnaire and thus being formal and specified can be fed into systems to create reports from the review process. After the score from the 360 review is determined the employee and the manager go over the report and the manager suggests actions, goals, and methods for improvement that I will call an action list. The employee has the opportunity to modify the action list and once agreed upon the action list is then kept so that it can be consulted as the employee is monitored by the manager. Usually in six months the review process is repeated.<br /><br />In the 360 review process the most difficult task of management is to compile and analyze the data. This is probably true with most review processes. Management has the burden of interpreting the data and making the best business decisions possible. It is estimated that it takes 20 hours of work to analyze and synthesize the data of each reviewed employee. That is why it is suggested that management sets up the review schedule, because it is expensive.<br /><br />In the 360 process everything is kept confidential. It is assumed that if the reports are not confidential then people will not give honest reviews of other people. Also, a 360 review is not a performance evaluation. It is concerned with how you are perceived by others and how to better work with the team. It is termed a developmental approach instead of an appraisal approach.<br /><br />The setup of a 360 review has many essential elements to any review process. First you set up the review categories to be aligned with business goals and objectives. In subsequent reviews the categories are built upon the previous review elements and thus the review process is evolutionary.<br /><br />Finally in 360 processes it is recommended to use software to perform the review and generate the review reports. Since the 360 process is not a performance review and is very costly to perform they are not done continuously or as regular as a performance review. As you improve your 360 process you will increase the throughput of the process.<br /><br /><span style="font-weight:bold;">Maverick Reviews</span> are <span style="font-weight:bold;">concerned</span> with the <span style="font-weight:bold;">productivity</span> of a group or workers and the individuals that make up such a group. 360 reviews is a general approach that has a wide application. Therefore the Maverick Review process is considered what is known in the industry as a customized instrument for software development organizations.<br /><br />Maverick Reviews are a type of <span style="font-weight:bold;">mulit-rater feedback</span>. Because multi-rater feedback systems can be manipulated it is essential that you have the right people. This is a chicken and egg problem. To find out if you have the right people you need to perform a thorough review. To do a thorough review you must have the right people. If you want to apply a 360 process or Maverick Reviews to an existing team then be very careful. You could easily create a severe problem. Just as you can not dump democracy on a communist state you can not dump Maverick Reviews on a traditional company. However, gaining the benefits of the Maverick Review process make it worth considering how you can introduce Maverick Reviews into your workplace.<br /><br />Maverick Reviews do not require an HR department to manage and administer the reviews. This eliminates the expense of traditional 360 processes. The reviews are simple enough to be performed regularly. The 20 hours of analysis per review of a 360 process is eliminated. There is no specialized software for tracking the review process. The process is simple and to the point.<br /><br /><span style="font-weight:bold;">The Goal of Maverick Reviews</span><br /><br />To improve the employees on an individual, team, and company level.<br /><br /><span style="font-weight:bold;">How Its Done</span><br /><br />Each person on the team reviews everyone else on the team, them self, and their management. The review ranking can be one of the following: great job, good job, or poor job. Great job and good job rankings may merit some type of reward. Poor job will mean that the reasons for the rating will be specified and discussed. Realize, a poor job rating will be taken personal because it is personal. Also, a great job rating is personal and when a person receives a great job ranking he/she is glowing and smiling and people congratulate him/her and all that is personal as well. All ratings are personal. Just remember that and work with it. A poor job rating has a concise list of the issues that caused the poor job rating. If a person gets two poor job ratings then they will lose their position on that team and will have to find a new position within the company or in another company.<br /><br />Teams also rank other teams that have an effect on them directly. If there is a company wide bonus and it is based on product delivery and sales then the development team is responsible to deliver and the sales team is responsible to make the sale. In-depth knowledge of the day to day work of external teams will not be sufficient to allow rankings of individuals. Therefore a team ranking will be performed based on public knowledge of published team performance.<br /><br />An example may help.<br /><br />Suppose a team of five software engineers, a software engineer team lead, two software testers, a project manager, a product manager, and a department director. Each person reviews every other person. The reviews are taken and tallied. Suppose that the product manager and one of the software engineers receive a poor job rating, one software engineer and one software tester received a great job rating, and the rest received a good job rating. When the ratings results are posted the two that received the poor ratings are visibly concerned. Their faces become reddened and they scowl at a certain team member as if to say, "I knew you didn't like me." Let's suppose that the product manager actually breaks down in tears and leaves the room.<br /><br />Now there are several things that must be done. One is the consideration of natural human feelings. Another is the specifying of the reasons for the poor job rating. Also it must be determined if there is a coalition or some kind of attempt to control the outcome.<br /><br />First there must be some time for emotions to settle. When this has happened bring the review group back together. I would suggest that the review results are presented in the morning and the discussion of the review commences after lunch. Now comes the open discussion of the reasons why the ratings were given. All of the ratings must be reviewed and not just the poor ratings.<br /><br />Let's suppose that when reviewing the reasons for the poor rating for the software engineer there isn't a clear issue. The engineer had given them self the rank of good. It was the other engineers on his team and the team lead that had given the poor job rating. The reason they give is that the engineer doesn't work well with the team. The engineer doesn't make his code fit within the architecture that the team has adopted. The engineer does deliver the projects and product features on time and with high quality. For this reason the other reviewers gave the good rating. However the other reviewers do not understand the ramifications of not working within the architecture as does the engineers and the team lead.<br /><br />Now the review of the product manager is considered. The poor rating comes from four of the software engineers and the two software testers. It is stated that the reason is the product manager continually changes features and their priority. The product manager had given them self the rating of great job. The reason the product manager says is that the customer is extremely happy with his responsiveness in adding and prioritizing the features for the product.<br /><br />Now the other ratings are reviewed. It is discovered that there may be some block voting amongst the engineers in that four of them ranked them self great and had ranked each other as great. This is suspicious because it is typical that truly great people under-rate them self. It is also typical for people below average to continually rank them self higher than their true rank.<br /><br />Also the team ranks other teams that affect them in some way. In this case they rank the sales team and the executive committee.<br /><br /><span style="font-weight:bold;">What You Do With The Results</span><br /><br />Now is the time for edifying. Edify is a great word. While living in Spain and learning Spanish it soon became apparent that the word edify is about building. So, it is time to build the team. It is time to build the team members. Why do a review process if improvements are not expected?<br /><br />The engineer needs to understand the architecture better. In this mocked example it is discovered that the engineer didn't use the architecture because the team didn't take the time to teach the architecture. This engineer was the last one hired and had been left out because of the urgencies and other factors that detoured the necessary training for the new hire. Since the engineer is very talented he was able to deliver his features independently. Now that the reasons are understood the person is re-rated. Considering the actual work environment the engineer had performed a good job and everyone agrees to change the rating.<br /><br />The product manager needs to understand the effect of changing priorities and features. In this mock example it is discovered that the customer really wants the changes that the product manager keeps requesting. The customer is very happy with the project manager's effort but disappointed that the company doesn't seem to care. Everyone comes together and they realize the project manager needs to revamp the development process to be more agile. Once again the team rates the product manager and gives a rating of good.<br /><br />Finally everyone is looking at the four engineers that ranked themselves as great. They realize immediately that they had not been great because they had let down the new hire by not training them properly on the architecture. Also they realize that the were not great because they had been complaining about the flip-flopping product manager and had not kept themselves current in new development processes in which they would have recognized that a change in process was needed. They re-rate themselves to a poor rating of which the group overturns and gives an overall good rating.<br /><br />The results are used to improve the team. This means that you have intelligent, thoughtful, and considerate team members. Injecting this process into a team that is known for its good old boy networks, heroes, and empires will cause disruption. How do you know if you have a team that will not work well with Maverick Reviews? First, open your eyes and your ears. What do you hear? Do you hear things like, "Don't ever invite so-and-so to a meeting, they drag them out forever over fringe concerns that are not valid" or "I had to work 80 hours a week for the past two months to save this company because no one around here knows how to do anything" or "We need to start an elite team of developers to engineer the next generation product and here is the list of people that qualify." Those are some of the things you may hear. But what about things you may see? Are there certain teams that get all of the perks, all of the ten cent options, or the lion's share of the bonus pool? Are there certain groups that walk on water, than can not be frustrated or disturbed, or that are declared hands-off?<br /><br />In Maverick Reviews there are no ranks that are used as an enticement. There is no exceeds expectations rank that no one can attain and is continually dangled as a carrot.<br /><br />The results of the review do not need to be archived or maintained in a database. Any "dirty laundry" from the review stays with those that participated in the review. Talking about someone's performance to other teams and individuals will result in the "informer" getting a poor rating once they are discovered.<br /><br /><span style="font-weight:bold;">How Often Do You Have Reviews?</span><br /><br />This will depend on the software development methodology that is being used. The goal would be to review the team members after the team members have met some kind of milestone. In an XP world this could be at the end of each release. In a Waterfall world this could be at the end of the development phase for each feature, component, or whatever your choice is for dividing up the work.<br /><br />Since the team members perform the review you do not need to schedule HR or any resources other than the team itself. Maverick reviews also include the review of other teams as well as your own. Those reviews would be done when a larger corporate milestone is met such as the completion of a business quarter. Remember, this is a Maverick approach so do the review when it makes sense. When does it makes sense to do one? Probably when there is some data available such as the quarterly numbers, the results of the end of release reflection, or any other event that your company deems important.<br /><br />A little story to help in deciding how often to review. My example is a basketball game. The scenario is this, there is one 0.2 seconds on the clock, your team is down by one point, and you are at the foul line. You miss both foul shots and the othe team in-bounds the ball and the clock expires. You lose. Everyone looks at you because you lost the game. I call this the last shot at the end of game syndrome. No one seems to remember that in the first half of the game that the Center missed two easy dunks and had the ball stripped from his hands four times.<br /><br />I hope you get the point of my story. If your company does reviews on a six month or once a year basis then you need to make sure you don't goof anything up in the last few weeks before the review. All of your other activities during the year will be discounted due to human nature.<br /><br />Review often so that the results are timely with the current state of the company.<br /><br /><span style="font-weight:bold;">OK, Now I Have To Fire Someone</span><br /><br />As a guideline the participants of the process that hires someone are the participants in the process that fires someone. When hiring a member of a software development team the entire team participates in the hiring process. Thus the entire team participates in the firing process. When hiring a manager the participants are typically the ones that make up the reporting chain. When firing a manager the participants of the reporting chain will consider the reviews given by each team that works with the particular manager.<br /><br />Suppose that someone has two successive poor ratings. The person must find a new position. You can feel confident that the review process is accurate. In Maverick Reviews and other multi-rater review process you will have fewer problems with correct ranking. The burden doesn't rest on someone that may be removed from the real work. The burden doesn't rest on one individual. The, what have I done for you lately, the last shot of the game syndrome, the horns and halo description is eliminated or at least greatly reduced.<br /><br />In Maverick, if someone is "fired" from their team they can apply for any open position within the company. Just because a person doesn't perform well in one circumstance doesn't mean that they will not excel in another. Realistically it would be difficult for the person to find a position unless the team they left has a bad reputation of treating its members unfairly.<br />Whistle Blowing and Anonymous Complaints<br /><br />There are other ways to learn information about a team or individual. Sometimes there is a whistle blower that can bring attention to a problem that needs addressing. Sometimes there are simple complaints that are made. These are all tidbits of information that should be taken serious. Listen, watch, and learn. That is the key. Don't delegate the responsibility of knowing your team and your company to the bean counters or soul-less reports, charts, and dash boards. Use their information but don't depend on it solely.<br /><br /><span style="font-weight:bold;">Conclusion</span><br /><br />Maverick Reviews are a customized instrument for a multi-rated or 360 degree review process.<br /><br />Make sure you have a team that is concerned about the welfare of each other before you introduce the review process.<br /><br />A fundamental piece of information to make the review process work is that of everyone's salary is known. This does not cause civil war unless salaries are unfair. Unreasonable people will be removed through the review process.<br /><br />The goal of the review process is to improve individuals, teams, and companies. Maverick teams are teams that are made of individuals that want to do a good job. It is the people that make the difference.<br /><br />References<br /><br />The Great Debates About 360 Degree Feedback<br />360 Degree Feedback: The Good, the Bad, and the UglyGeoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-48247463830537356312008-01-21T21:14:00.000-08:002008-01-29T08:12:59.961-08:00Corporate Communication<span style="font-weight:bold;">Introduction</span><br /><br />How do you communicate concerns and ideas for improvement? How does the work environment and corporate culture facilitate freely sharing ideas or concerns? The answer to these two questions should be on the lips of every employee, from the CEO and down. As a challenge to your company I suggest you create a questionaire that would reveal if your employees know the answers to these two questions.<br /><br /><span style="font-weight:bold;">Problem Recognition</span><br /><br />Some people have a knack at recognizing existing problems or predicting future problems. Their ability usually is enforced by experience that they have in the area. Many of us can identify a problem with our automobile and even be very precise about the problem but lack the ability to fix the problem or even suggest a possibly remedy.<br /><br /><span style="font-weight:bold;">Problem Resolution</span><br /><br />When a problem has been recognized a resolution must be discovered. The resolution may be that you avoid the problem altogether or the resolution may be that something is changed. I don't think ignoring a problem should be considered as a type of resolution.<br /><br />For example suppose that you manage a race car team and that every May at Daytona your car's air intake gets clogged with insects. You could alter the situation so that the problem can not surface by not racing your car during the month of May at Daytona. Or you could solve the problem by replacing your current air intake with one that is modified so that insects can not clog it. Ignoring the problem would not win any races.<br /><br />The resolution of a problem requires an understanding far greater than that of recognition. Expertise and experience in the field in which the problem exists is required.<br /><br /><span style="font-weight:bold;">Communication of Concerns and Ideas</span><br /><br />The first question introduced is how do you communicate concerns and ideas for improvement. The "how" suggests what medium is used. But let's get to that in a moment. The first things are what are you going to communicate and to whom.<br /><br />First make sure what you are communicating as a problem really is a problem. If the things you perceive as problems are not really problems then people will not treat your communications with urgency. Problems have severity and the level of severity needs to be estimated. A problem with a computer game may be an annoyance but a problem with a heart monitor could be fatal.<br /><br />Next you need to decide to whom to communicate the problem. If the severity of the problem is low enough then telling your immediate manager might suffice. If the problem is sufficiently severe then you should tell you manager and his manager at the same time. Notice that there is no end-run-around.<br /><br />Finally how do you communicate a problem? The severity also should come into consideration. If the problem is severe or complicated then a letter, email, or some traceable medium should be used in conjunction with a face-to-face meeting. Traceability or paper-trails are useful in documenting the situation.<br /><br /><span style="font-weight:bold;">Collaborative Corporate Culture</span><br /><br />The second question introduced by this paper is how does the work environment and corporate culture facilitate freely sharing ideas or concerns. The answer to this question is complex and requires the right culture and environment. The Maverick principles in hiring play a role in this as well as the Maverick principle that all salaries are company knowledge. Also, the Maverick principles concerned with the review process are part of the culture necessary for an open and collaborative environment.<br /><br />If you have a culture where politics is a problem and people are defensive and distrustful then you will never have efficient communication. Too many factors will come into play that will bias the recognition, resolution, or communication of any problem. Manipulation will become part of every conversation. Coup d'etats and end-run-arounds will be the methods used. Each resolution will be preceded with "poisoning the well" against any other resolution that another may present. I dare say, if you think you are experiencing these behaviors then your probably have a serious situation.<br /><br />To create the right culture the top of the company must open up and share the information and must demonstrate trust with the employees. One way to do this is to have company wide knowledge of all salaries. Think about it this way, if the knowledge of a salary would upset the workforce in such a way that production would drop then the question is what is wrong with the salary and the question is not what is wrong with the employees.<br /><br />In the Maverick hiring process people are selected that work well in a collaborative environment. During the hiring process all of the candidates are brought together to present their solution to a problem that was presented to them in advance. Each candidate presents their solution and comments on the solutions from the other candidates. Most everything you need to know concerning a persons knowledge, presentation skills, ability to take criticism, ability to give criticism, and ability to work with others will be manifested. Through this process you will hire people that know how to communicate.<br /><br />Through the Maverick review process people that are too political, that are empire builders, or that are heroes will be identified early and they will not be rewarded for such behavior. Those guilty of such offenses will either change or be fired in very short order. By removing these types of people others can communicate freely without the fear that someone will try to use some means against them.<br /><br />Also the Maverick principle of the emergent work methodology can be seen as the results of a collaborative corporate culture. If the teams organize and re-organize themselves and their way to do the job in ways that are more efficient then you have succeeded!<br /><br /><span style="font-weight:bold;">Conclusion</span><br /><br />Some people are good at recognizing problems and others are good at resolving problems. The communication of problems is essential for a company to be successful. If your company suffers from coup d'etats and end-run-arounds then you probably have a severe problem. Through the sharing of salaries, the hiring process, and the review process a culture will come about that gives way to collaboration naturally and without the need of managing it into existence.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-83704955172618721202008-01-21T21:13:00.002-08:002008-01-29T08:17:09.301-08:00Maverick Common SenseMaverick Common Sense<br />by Geoffrey Slinker (This is an experiment where I have applied the language of Thomas Paine's writings entitled "Common Sense" to the area of business organization, management, and government.)<br /><br />December 2006<br /><br />Introduction<br /><br />Maybe the thoughts contained in the following lines aren't generally excepted or understood enough to gain general approval. It seems to be human nature that if over a long period of time something isn't challenged as being wrong or inefficient then the thing is accepted as being right or optimal. Any challenge to the long standing "thing" is usually at first met with resistance, but soon the commotion settles down and reason prevails.<br /><br />Long experience and empirical evidence of inefficiencies, failures, and abuses is sufficient reason to question the correctness of business management organization and process. These problems have caused people at all levels in business to question the generally accepted "ways" of managing and organizing a business.<br /><br />In this paper, I have avoided singling out any one management model as being good or bad, or any business leader as being good or bad. Those that have championed change do not depend on the success of my ranting. Also, in this paper, the arguments of those who prefer the status quo will ultimately be forgotten if there is not too much consideration given to their defensive remarks.<br /><br />The cause of the Worker is, in a great measure, the cause of all people. Many circumstances have, and will arise, which are not specific to a business sector or management style, but are universal, and through which the principles of all those that desire the satisfaction of a "good days work" are affected, and because they are affect by these universal circumstances they are also rightly concerned. The using of employees in such a manner that they are nothing more than a resource, like so much cattle, which destroys self worth and self esteem and ultimately works against a business' need for efficiency and profitability is the concern of every employer and employee that has the capacity of reason.<br />The Origin and Design of Popular Business Organization and Process.<br /><br />SOME writers have so confounded the concept of Team with the management organization, as to leave little or no distinction between them. They are not only different but have different origins. A Team is the organizational results of real need. Management organization is an attempt to deal with our weaknesses and pride. A Team promotes the happiness of each member by uniting on goals and needs where management organization is to minimize the negative affects of human vices. Teams encourage working together with a common cause while management organization creates distinctions, distinctions that have no correspondence with business efficiency or profitability. Team-ship is a patron. Management organization is a punisher.<br /><br />Team-ship, community-ship, sociocracy, or whatever the term, is a blessing, but the common management organization of business in its best state is but a necessary evil in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries by a business organization, which we might expect in a business with no organization or chaos, our calamities is heightened by reflecting that we furnished the means by which we suffer. High ceremony business organization, like government, is the badge of lost innocence; the mansions and estates of CEOs are built on the ruins of the humble home with the white picket fence and have redefined the organization of the family unit. If the intrinsic desires of a clear conscience were obeyed then there would be no need for another set of guidance. Since that is not the case, it is necessary to surrender up a part of the business earnings to furnish a means for the protection of the rest; and this is induced by the same prudence which in every other case advises one to choose the lesser of two evils. Wherefore, security and predictability being the true design and end of business organization, it unanswerably follows that whatever form thereof appears most likely to ensure it to us, with the least expense and greatest benefit, is preferable to all others.<br /><br />In order to gain a clear and just idea of the design and end of a business organization, let us suppose a small number of persons start a new company, unconnected to existing companies. In this state of natural liberty, team work will be their first thought. A thousand motives will excite them thereto, the strength of one man is so unequal to his wants, and his mind so unfitted for perpetual solitude, that he is soon obliged to seek assistance and relief of another, who in his turn requires the same. Four or five united would be able to found a fledgling company, but one man might labor out the common period of a life without accomplishing any thing; when he had envisioned the business opportunity he could not bring it to market in a timely manner; the continuous burn of capital would drive him to more short term ventures, and every different want call him a different way.<br /><br />Thus necessity, like a gravitating and organizing power, would soon form our newly found company into a team or society, the reciprocal blessing of which, would supersede, and render the obligations of corporate government unnecessary while they remained perfectly just to each other; but as nothing but heaven is impregnable to vice, it will unavoidably happen, that in proportion as they surmount the first difficulties of team work, which bound them together in a common cause, they will begin to relax in their duty and attachment to each other; and this remissness, will point out the necessity, of establishing some form of organization to supply the defect of moral virtue.<br /><br />Some convenient empty office will afford them a conference room in which every employee of the company may assemble to deliberate on company matters. It is more than probable that their first by-laws will have the title of "company guidelines", and be enforced by no other penalty than company-wide disesteem. In the first company organization every man, by natural right will have a seat.<br /><br />But as company portfolio and employment increases, the company concerns will increase likewise, and the distance at which the members may be separated, will render it too inconvenient for all of them to meet on every occasion as at first, when their number was small, their offices near, and the company concerns few and trifling. This will point out the convenience of their consenting to leave the business management part to be managed by a select number of chosen from the whole body, who are supposed to have the same business concerns at stake which those have who appointed them, and who will act in the same manner as the whole body would act were they present. If the company continues to grow, it will become necessary to augment the number of representatives, and that the interest of every part of the company may be attended to, it will be found best to divide the whole into convenient parts, each part sending its proper number; and that the elected might never form to themselves an interest separate from the electors, prudence will point out the propriety of having elections often; because as the elected might by that means return and work again with the general divisions of the company in a few months, their fidelity to the company division will be secured by the prudent reflection of not making themselves a permanent authority. And as this frequent interchange will establish a common interest with every part of the company, they will mutually and naturally support each other, and on this (not on the unmeaning title of CEO/President) depends the strength of the company, and the happiness of the employee.<br /><br />Here then is the origin and rise of business organization; namely, a mode rendered necessary by the inability of moral virtue to govern the company; here too is the design and end of business organization, that is to say., predictability and security. And however our eyes may be dazzled with snow, or our ears deceived by sound; however prejudice may warp our wills, or interest darken our understanding, the simple voice of nature and of reason will say, it is right.<br /><br />I draw my idea of the form of business organization from a principle in nature, which no art can overturn, that is to say., that the more simple any thing is, the less liable it is to be disordered, and the easier repaired when disordered; and with this maxim in view, I offer a few remarks on the so much boasted high ceremony organization of most businesses. That it was noble for the dark and slavish times in which it was erected is granted. When the world was overrun with tyranny, child labor, etc., the least therefrom was a glorious rescue. But that it is imperfect, subject to convulsions, and incapable of producing what it seems to promise, is easily demonstrated.<br /><br />Absolute leadership through a single office (though the disgrace of human nature) has this advantage with their kind, that they are simple; if the company suffers, they know the head from which their suffering springs, know likewise the remedy, and are not bewildered by a variety of causes and cures. But the corporate politics of high ceremony business organization is so exceedingly complex, that the company may suffer for years together without being able to discover in which part the fault lies, some will say in one and some in another, and every new management fad will advise a different course of action for remedy.<br /><br />I know it is difficult to get over local or long standing prejudices, yet if we will suffer ourselves to examine the component parts of high ceremony business, we shall find them to be the base remains of two ancient tyrannies, compounded with some new republican materials.<br /><br />First.- The remains of monarchical tyranny in the office of the CEO and other Chief positions<br /><br />Secondly.- The remains of aristocratical tyranny in the offices of the Executive committees, such as Vice Presidents and Directors.<br /><br />Thirdly.- The new republican materials, in the persons of the committees, offices, and middle management.<br /><br />The two first, by being appointed by the Board of Directors or the CEO, are independent of the employees and their business duties; wherefore in a constitutional sense they contribute nothing towards the representation of the needs of the divisions of the company.<br /><br />To say that the organization of the company is a union of three powers reciprocally checking each other, is farcical, either the words have no meaning, or they are flat contradictions.<br /><br />To say that the Board of Directors es a check upon the CEO, presupposes two things.<br /><br />First.- That the CEO is not to be trusted without being looked after, or in other words, that a thirst for absolute power is the natural disease of autocracy.<br /><br />Secondly.- That the Board, by being appointed for that purpose, are either wiser or more worthy of confidence than the CEO.<br /><br />But as the same business organization which gives the Board a power to check the CEO by withholding the supplies, gives afterwards the CEO a power to check the lower managers and committees, by empowering him to reject their other bills; it again supposes that the CEO is wiser than those whom it has already supposed to be wiser than him. A mere absurdity!<br /><br />There is something exceedingly ridiculous in the composition of high ceremony business organization; it first excludes a man from the means of information, yet empowers him to act in cases where the highest judgment is required. The state of a CEO shuts him from the world, yet the business of a CEO requires him to know it thoroughly; wherefore the different parts, unnaturally opposing and destroying each other, prove the whole character to be absurd and useless.<br /><br />Some writers have explained high ceremony business thus; the CEO, say they, is one, the employee another; the Executive committee are an house in behalf of the CEO; the middle managers in behalf of the people; but this hath all the distinctions of an house divided against itself; and though the expressions be pleasantly arranged, yet when examined they appear idle and ambiguous; and it will always happen, that the nicest construction that words are capable of, when applied to the description of something which either cannot exist, or is too incomprehensible to be within the compass of description, will be words of sound only, and though they may amuse the ear, they cannot inform the mind, for this explanation includes a previous question, that is to say. How came the CEO by a power which the company is afraid to trust, and always obliged to check? Such a power could not be the gift of wise people, neither can any power, which needs checking, be from God; yet the provision, which high ceremony business makes, supposes such a power to exist.<br /><br />But the provision is unequal to the task; the means either cannot or will not accomplish the end, and the whole affair is an act of suicide; for as the greater weight will always carry up the less, and as all the wheels of a machine are put in motion by one, it only remains to know which office in the company has the most weight, for that will govern; and though the others, or a part of them, may clog, or, as the phrase is, check the rapidity of its motion, yet so long as they cannot stop it, their endeavors will be ineffectual; the first moving power will at last have its way, and what it wants in speed is supplied by time.<br /><br />That the CEO is this overbearing part in high ceremony business organization needs not be mentioned, and that it derives its whole consequence merely from being the giver of places, positions, and pensions is self evident, wherefore, though we have been wise enough to shut and lock a door against absolute power, we at the same time have been foolish enough to put the CEO in possession of the key.<br /><br />The prejudice of business men, in favor of their own corporate government by CEO, Board of Directors, and Executive committees, arises as much or more from personal pride and self serving ambition than reason. Individuals are undoubtedly safer and treated more fairly than in the Industrial revolution, but the will of the CEO is as much the law of the land in Toyota as in Ford.<br /><br />An inquiry into the organizational errors in high ceremony form of corporate government is at this time highly necessary; for as we are never in a proper condition of doing justice to our work, while we continue under the influence of some leading partiality, so neither are we capable of doing it to ourselves while we remain fettered by any obstinate prejudice. And as a man, who is attached to a prostitute, is unfitted to choose or judge of a wife, so any prepossession in favor of a rotten high ceremony form of corporate government will disable us from discerning a good one.<br /><br />Thank you Thomas Paine.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-30867804878794361992008-01-21T21:13:00.001-08:002021-04-07T12:39:15.572-07:00Quotes and Maverickisms<ul style="text-align: left;"><li>"Hey, I knew that methodology when it was still just a complaint." </li><li> "Experience trumps formal estimation." </li><li> "Smells like chicken!" </li><li> "We do not model for the sake of modeling; we model so that an implementation can be made."</li><li> "Fundamentally most software development methodologies strive to improve communication and shorten the time of gaining experience." </li><li> "Experience is better than iterations." </li><li> "If you know what to do then why don't you do it?" </li><li> "Revolution is for visionaries. Evolution is for apes." </li><li> "You know with a flat-head screw driver, a pair of vice-grips, and a hammer you can fix almost anything but you can build almost nothing!" </li><li> "Definition of Shared Code: Code that someone else wrote that you don't trust." </li><li> "Don't tell me it is my problem and how you want it fixed. If it is my problem I will fix it the way I want." </li><li> "A sheep herder is a sheep manager. A shepherd is a sheep leader." </li><li> "Some people demand to be heard, some beg to be heard, and some are blessed to be heard." (Some are lucky to be heard!) </li><li> "Frustration is the mother of invention." </li><li> "Unless you take great risks how will I be able to rip you off?" </li><li> "Servers: What comes up must come down." </li><li> "Would you like some syrup with that waffle?" </li><li> "Oh yeah, I know what to do, code faster!" </li><li> "Of course I am lying, I can really do that in a week instead of three. Gosh, you caught me." </li><li> Manager : "If programmers produce code what do you think managers produce?" Programmer: "Hirudin?"</li><li>"How often do you send a hero into battle? Until they don't come back."</li></ul>Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-43402416901858413922008-01-21T19:28:00.000-08:002008-01-21T19:53:45.055-08:00The Final Review of Maverick Software DevelopmentI just deleted the Maverick Software Development group. I had ran it for three or more years. It had nearly 150 members. I posted many thoughts and ideas on how I felt a software company should be ran.<br /><br />I captured some of the posts and put them in this blog.<br /><br />I did a lot of work on that group trying to change some ideas on how business can be ran and how software can be developed. When I reflect back on the effort I can not see that I effected any change. It seemed that everyone fell into two camps. Those that already believed in the ideas and those that felt the ideas where not practical. So I feel that I have caused no change and thus done no work.<br /><br />Is part of the problem that I did this for free? Maybe if I had written a book and charged for it things would have been received better. Maybe if I had went around as a consultant or something. I don't know.<br /><br />The current "players" in the software process space never seemed to get on board with any of my ideas. Either they they would say nothing or would say, "Oh, what you have proposed is something we did years ago and we called it XYZ-ABC-123".<br /><br />When I started the Maverick group it was because I had gained renewed hope for improvements when XP and Agile came on the scene.<br /><br />I had originally proposed Semco style changes years before Agile. Those "Maverick" ideas were rejected and my professional reputation had suffered because of my public alignment with those ideas. So I focused on programming, design, object oriented modeling, and other related fields and kept my head down.<br /><br />Well, I have came full circle once again. The evangelizing of the Maverick ideas seems to have done me no good and probably harm. So, I go back to what pays the bills and I leave the problems of process and improvement to those that have the book deals, the conference appearances, and the consulting companies. Clearly their financial success in their respective areas indicates that they are truly the most knowledgeable in the field of software development.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-88904942070098846052008-01-21T18:57:00.001-08:002008-01-21T20:04:59.350-08:00The Maverick CartaThe Maverick Carta<br /><br /><span style="font-weight:bold;">We </span>recognize that results reflect leadership.<br /><br /><span style="font-weight:bold;">We </span>acknowledge that everyone desires to enjoy their career, whatever career path they chose.<br /><br /><span style="font-weight:bold;">We </span>assert that the quality of life enjoyed by each employee is a cornerstone to product quality, productivity, and the resulting success of the company.<br /><br /><span style="font-weight:bold;">We </span>claim that trust is essential and therefore champion trust building policies and take the initiative.<br /><br /><span style="font-weight:bold;">We </span>assert that a company should not be paternalistic, the power to reward and punish is too powerful to be centered into the hands of a few or even one.<br /><br /><span style="font-weight:bold;">We </span>recognize that the financial situation of the company must influence decisions and that this information must be shared.<br /><br />The <span style="font-weight:bold;">trust </span>building policies include:<br /><br />Company wide <span style="font-weight:bold;">disclosure </span>of salaries and other benefits.<br /><br />Company wide <span style="font-weight:bold;">disclosure </span>of the financial status of the company presented in an honest and straightforward manner.<br /><br />Company wide <span style="font-weight:bold;">reviews of all</span> employees such that everyone one's position is just as safe or unsafe as anyone else's position.<br /><br />Company <span style="font-weight:bold;">direction </span>set through a consent basis.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-41221117852603931462008-01-21T18:56:00.000-08:002008-01-21T18:57:04.680-08:00Layoffs and an Open Book PolicyLayoffs can occur for many reasons. The first one that comes to mind<br />is that company income is not sufficient to support the current<br />number of employees. Another reason I have witnessed is that you<br />company merges with another company and there are departments that<br />are now duplicated. Often these duplicate departments are H.R.,<br />Finance, I.T., etc.<br /><br />Another reason for a layoff is to reassign the money that was going<br />towards salaries. Whatever the reason, the company wants to spend its<br />money on something other than salaries. Could be the company is going<br />to pursue a new direction or buy out a competitor. The bottom line is<br />the company needs to free up some cash.<br /><br />For the general work force a layoff is typically a surprise. Yes,<br />there may be rumors floating about, but when it finally happens it<br />usually surprises most.<br /><br />Now imagine a different type of work environment. Imagine that the<br />books are open and the conversations of the Executive Committee and<br />the Board of Directors is made known to the entire company. Also<br />imagine that you are just an employee, lets say a software developer<br />working on your company's search engine and indexing technology.<br /><br />With this open book policy you find yourself with information. With<br />information you can make decisions, choose how much risk you want to<br />take, plan your future, make predictions for the future, etc.<br /><br />Scenario A:<br />Suppose the information indicates that there is a dramatic downturn<br />in profits. You know about it as soon as the EC and Board know. There<br />are those that oppose the open book policy and through the use of<br />uncertainty and doubt say, "We can't have an open book policy because<br />if people hear about the down turn they will start to quit in droves<br />and thus worsen the situation and make it impossible for the company<br />to implement a plan inorder to turn things around." I personally<br />think that this attitude under estimates the worth of a company that<br />implements an open book policy and underestimates the employee. If<br />you were to work for a company that gave you all of the information<br />then you would value that aspect, that distinguishing aspect, of the<br />company and you would not want to leave the company on a whim and you<br />would want the company to succeed. Also, with the open book policy<br />you can know that information from your department is making it to<br />the top and that the information is accurate (accurate in the areas<br />where you have knowledge and responsibility). This omni-directionaly<br />flow of information will enable you to have confidence that the EC<br />and Board are making informed decisions. This makes the company even<br />more appealing to you. If the EC and Board are planning for layoffs<br />then you can make choices. Maybe you find another job. That saves<br />your manager the stress of laying you off. It also saves the company<br />the severence payouts and paperwork and such. Also, it allows you to<br />leave with dignity and keeps the door open for when the company<br />rebounds. Maybe you can't find another job and you are laidoff.<br />Because the process was open the chances of illegalities may be<br />reduced. You definetly couldn't choose the people to layoff by race,<br />gender, etc. It would be likely that you would layoff people by<br />teams, departments, and divisions and it would be less likely that<br />people could protect their "friends" by transferring them off of a<br />team that was to be let go and placing them onto a team where they<br />would not be laidoff. The protecting of friends and special employees<br />are one of the things that make layoffs so personal and so hurtful<br />and damaging. Also, for defense against a possible future layoff it<br />causes people to play games and work on only the cutting edge teams,<br />both of which are not in the companies interest. (This makes me think<br />of all of the games we play at work inorder to protect our jobs and<br />how they are not in the best interest of the company and how people<br />say that open book policies are not in the best interest of the<br />company. Clearly the argument to do things in the best interest of<br />the company is not sound because the current mode of operation for<br />most companies support "games", politics, posturing, and positioning.)<br /><br />Scenario B:<br />The company wants to take $1,000,000.00 that was going for salaries<br />and use it to buy out a small startup company. The open book policy<br />allows you to know about this choice as soon as it happens. Since the<br />EC and Board know that everyone will know about this choice they will<br />also have taken time to consider the ramifications. A layoff while<br />the company is profitable is tricky at best. I myself have survived a<br />few such layoffs and you always wonder why they did the layoff, which<br />usually becomes apparent 3 to 6 months down the road, and you always<br />feel lessened or devalued. Back to the story... so the EC and Board<br />has decided to layoff and have considered such things as salary<br />reductions and taken a loan. So you know, because of the open book<br />policy, that the EC and Board has considered many options. Since they<br />have decided to reduce the work force then they have decided to<br />reduce the work as well. The open book policy allows you to see in<br />which areas the company is going to ellimate work. Maybe this time<br />they pick who goes and who stays based on the previous performance<br />review (that is why I think that that a Maverick-ish review process<br />is so important). I believe that if you do it on a performance score<br />then you have to let everyone go that falls into the catagory. Let me<br />give an example. Suppose that the performance scores are from one to<br />ten. The company decides to let everyone go that got less that a 7.<br />Also the company knows that they want to layoff around 60 employees<br />inorder to recapture that 1 million bucks. Know imagine that 85<br />people got below 7. I believe it is fair to layoff the 85 if you are<br />going to base it on performance. If you decide you are going to keep<br />15 of the 85 then you have the potential for the problems of "games",<br />politics, good ol'boy network, and such things as Pedro promising you<br />his protection. If 85 is too many then only layoff those that got a 6<br />and below. Suppose that number is 47. Then you don't raise the<br />million solely on layoffs, and the company then decides to take a<br />loan or reduce everyone's salary (and I mean everyones) by a<br />percentage.<br /><br />End Scenario<br /><br />When a traditional company has layoffs it is very very messy. Messy<br />in that it puts into play all kinds of things. Some people are hurt.<br />Some people loose confidence. Why, because traditional companies<br />always paint blue skies and dangle sweet carrots (these aren't the<br />only reasons why, but some... :-) ) I was at a company meeting where<br />the employees suspected that a layoff might be needed. It was a<br />friday. The EC was asked if there were any plans for a layoff. They<br />said "NO". Monday morning the layoff started and 30% was let go.<br /><br />I have been at companies that have laidoff and then within 3 months<br />or so they want to hire. Usually because of attrition after the<br />layoff. They ask us if we know of any good people that we could get<br />to submit their resume. We all sit there and give them a blank stare.<br />Why would we bring our friends in when we don't know if we may be<br />talking our friend out of a good job to come to work here at this<br />company and then get laidoff 3 weeks later.<br /><br />Open book benefits both ends of the employee spectrum. The bottom<br />know what the top is up to. The top knows that the bottom has<br />reported correctly because the bottom checks that the reports made it<br />to the top. A Maverick style review process insures that if you have<br />to do a layoff based on performance that the performance scores are<br />as accurate and up to date as possible. Open books help elliminate<br />practices that are not in the best interest of the company. I feel<br />these practices are extremely expensive. These practices include<br />personal agendas, back stabbing, networking, protection schemes, etc.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-92878997658033242008-01-21T18:54:00.000-08:002008-01-21T18:56:07.104-08:00Maverick "like" companiesOf course there is Semco lead by Ricardo Semler.<br /><br /><br />Do you know of any "maverick" type companies?<br /><br />We know of the GE Durham facility.<br />It seems that Car Fax has some things going for it.<br />There is Johnsonville Sausage as well.<br /><br />I know there are groups advocating certain aspects:<br />www.worldblu.com<br />http://evolutionarysystems.net/<br /><br />And the amount of people talking about this on the web is growing.<br /><br />http://jeremy.zawodny.com/blog/archives/006273.html<br />http://www.leighfarnell.com/docs/ManagersIntoCoaches.pdf<br />http://ccs.mit.edu/21c/21CWP001.html<br />http://www.tonellomanagement.com/NewsDetail.asp?NewsID=26<br />http://was4.hewitt.com/hewitt/resource/rptspubs/subrptspubs/next_generation.pdfGeoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com2tag:blogger.com,1999:blog-8390064019981582628.post-57408566049682586732008-01-21T18:53:00.001-08:002008-01-21T18:53:55.299-08:00Adopting parts of Maverick / Maverick best practicesIs it possible to adopt parts of Maverick style management but not<br />the whole?<br /><br />This brings up some issues. First let me contrast this to a common<br />topic, can you adopt parts of XP and gain /most/ of the benefits?<br /><br />I have found that most people adopt TDD and continuous builds, throw<br />in some code coverage, use some type of standup meeting, and call it<br />good.<br /><br />The reason I bring up XP is that TDD has been identified by many as<br />the major contribution of XP.<br /><br />So, to answer this question about Maverick style businesses, are<br />there some /parts/ that can be identified as the major contributors?<br /><br />I think the major contributors are:<br />1) Company-wide knowledge of salaries.<br />2) Team based review process.<br />3) Team based hiring process.<br /><br />What /parts/ do you think are the major contributors?<br /><br />If items 1-3 are a subset of the complete Maverick style of business,<br />what are the other items that make up a Maverick style business?Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-52403212211260276622008-01-21T18:51:00.001-08:002008-01-21T18:51:47.899-08:00Opportunities for major improvements and advancesI was just thinking about software development over the years. I<br />don't know if I will be able to express these thoughts in 'text' but<br />I will try.<br /><br />There are many many things that have to come together for<br />improvements in software development process.<br /><br />These things (IMO) include:<br />a) the development environment, including the build system, the<br />language, etc.<br />b) the demand of the market, such as an almost insatiable appetite<br />for new software<br />c) Corporate Government, such as a rebalancing of power in a company<br />where the technical units are not dominated by the business units in<br />a fashion that constricts growth or stifles thought.<br /><br />Imagine this:<br />You are on writing software for a machine that you can not have<br />access to but for 2 hours a day. You write your programs on cards.<br />Your turn comes and you hope your program "loads". In such an<br />environment you will not be apt to conceive the notion of continuous<br />builds. It is not an environment that is ready for such thought.<br /><br />Imagine this:<br />You are writing software in C on a Unix machine in the early '80s.<br />Your salary is well above average. The machine you access through<br />your terminal is a major capital expenditure. Libraries and seperate<br />compilation units are available to you now. You have access to the<br />hardware all day, but your compiles take a long time because of the<br />time-sharing of the machine. You are thinking in terms of abstract<br />structures and you are aggregating fundamental types into domain<br />concepts. Memory is expensive. Disk space is expensive. You are<br />frustrated with the slow build times. You are frustrated with memory<br />management. You are frustrated with the debugger. There are so few<br />programmers that in order to utilize their skills more thoroughly<br />divisions appear such as Testing/QA and Product Management because<br />the developers are too expensive to use for other tasks. Because of<br />this the waterfall approach is used to serialize the tasks just as<br />developers would serialize tasks to be batched and ran on the<br />computers. Immediately it was recognized that feed-back loops and<br />recursion could help, and notice that both of these ideas are from<br />computer science (and electrical engineering).<br /><br />Now imagine today:<br />We have desktop machines that are more powerful than the original<br />super computers. We can distribute programming easily. Threading is<br />easy. So, what can we focus on? Continuous build. Rapid feedback. We<br />can focus on improving the software process once again! What shows<br />up? XP, Crystal, Lean, etc. Were the ideas that form the basis of<br />thesse process had only by Beck or Cockburn? No, many many people<br />were having similar thoughts working through similar problems. I<br />don't want to diminish their contribution, because there were many<br />many people that were happy with the state of software development as<br />well. We can see the division even today.<br /><br />Now imagine tomorrow:<br />What I have been describing is "overcoming constraints". When<br />development is not the bottleneck who is? What changes are going to<br />happen? After these constraints are removed it will eventually fall<br />back on development and when it does what will be the focus for<br />improvement?Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-33271752393940050342008-01-21T18:50:00.001-08:002008-01-21T18:50:45.515-08:00My Vision for Maverick Software DevelopmentA friend asked me about my vision for Maverick. Since it doesn't make<br />any money, why do it?<br /><br />---------------------------------------------------------------------<br />Ah, my Maverick vision you want (said in Yoda voice).<br /><br />I would like to have a Wiki where there are sections that match your<br />situation. Let's say you are a one man band and you want to do XP.<br />There's a section. Say you are a member of a Spiral Team on a DoD<br />contract. There is a section for you.<br /><br />Also all of the books are online and living. Suppose XP Explained was<br />on the Maverick Wiki. We don't have to wait for editors and<br />publishers. If there is a change it shows up. Imagine the discussion<br />on BDD versus TDD in a Maverick world. We all talk about it, and if<br />BDD is deamed more appropriate, we refactor the text to be BDD.<br /><br />I know there is big business in writing books, etc. But I don't see<br />how it is the best way to deliver ideas to the development community.<br />I am not motivated by money in Maverick. I realize that the authors<br />of these books are also consultants and my idea is going to be met by<br />resistence because I am saying that their part of the business is not<br />necessary.<br /><br />So, I would like enough members that believe in Maverick and are<br />found in enough different sectors to build up the repository of<br />living information on how to develope software.<br /><br />-------------------------------------------------------------------<br /><br />So there you have it. I am "bucking" traditional software development<br />from "every concievable angle".Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-84484222271585436522008-01-21T18:46:00.000-08:002008-01-21T18:49:54.973-08:00Intent revealing code...From my personal experience (many many years of it) I find that there<br />are some people's code that is easy to read and understand and there<br />are other's that is not. One person's intent revealing code is not<br />always intent revealing to someone else.<br /><br />It would seem ill-advised to try to understand a design in XP if you<br />cannot understand code.<br /><br />If that is true, it would mean that anyone who is concerned with the<br />design has to be someone who understands code. Programmers understand<br />code. Who else really understands code?Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-71925944527358935142008-01-21T18:44:00.000-08:002008-01-21T18:45:53.699-08:00TDD'ers have run a muck...I am re-writing my <a href="http://home.comcast.net/~gslinker/maverick/Scouting.html">Scouting </a>paper. The idea is that if code tests are<br />good for upfront, why not include other types of tests or experiments?<br /><br />I want to show that Software Scouting and Reconn is a natural part of<br />design.<br /><br />I was looking for some definitions of TDD and Test First Development<br />so that I could show the relationship I know exists between TDD and<br />Software Scouting/Reconn.<br /><br />I came across this:<br /><br />http://www.xprogramming.com/xpmag/testFirstGuidelines.htm<br /><br /><br />The Test-Code-Simplify cycle (Quoted verbatim from "Extreme<br />Programming Applied", p159)<br /><br />Write a single test<br />Compile it. It shouldn't compile, because you haven't written the<br />implementation code it calls<br /><br />Implement just enough code to get the test to compile<br />Run the test and see it fail<br /><br />Implement just enough code to get the test to pass<br />Run the test and see it pass<br /><br />Refactor for clarity and "once and only once"<br /><br />Repeat<br /><br /><br />I find it completely wierd that I "have to" compile something I know<br />will not compile. I also find it just as troubling that I have to run<br />a test that I know will fail.<br /><br />This is what I call a methodology gone amuck. Steps for steps sake<br />IMO.<br /><br />What is the goal of TDD?<br /><br />IMO it is to help design the code. It is a design process. My<br />thoughts should be about "how do I want to use this system", "what do<br />I expect from the call into the system", "what domain terminology is<br />needed/used by this call into the system", "which subdomain will<br />handle this behavior", "what objects exist in the caller's world<br />versus the callee's world", you know, those kinds of thoughts are<br />going through my head.<br /><br />What is not going through my head is following some "hard coded"<br />steps!<br /><br />I don't think TDD has gone amuck, but I think that the description of<br />what it is doing is lacking.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-35534559362198095872008-01-21T18:37:00.000-08:002008-01-21T18:38:30.889-08:00Simplicity versus ComplexityIn many agile processes they say "do the simplest thing possible".<br /><br />I agree that you should not program some cool solution because you<br />wanted to learn or use some technology or algorithm at the expense of<br />those paying for the product.<br /><br />I think the Maverick value would be:<br /><br />We value 'lateral understanding' (if that is a term, based of of<br />Lateral thinking) and then choosing the right solution.<br /><br />Near the bottom of my web site I say this:<br /><br />"You know with a flat-head screw driver, a pair of vice-grips, and a<br />hammer you can fix almost anything but you can build almost nothing!"<br /><br />http://home.comcast.net/~gslinker/agile.html<br /><br /><br />I came up with that saying outside of the context of discussing<br />agile's idea that you must do the simplest thing.<br /><br />A flat head screw driver, vice-grips, and a hammer are very simple<br />tools. They are the most common tools for household repairs. They are<br />included in the toolbox of the carpenter or constructor, but they are<br />accompanied by a myriad of other tools.<br /><br />People must know the complex solutions and when the are applicable.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-12706952248504955262008-01-21T18:36:00.000-08:002008-01-21T18:37:16.715-08:00Agilista...Agilista - a person doing some sort of agile development that doesn't<br />seem to consider alternatives and that their agile approach is the<br />right way to do it. They say things like, "you have to do X before<br />Y", or if you say that the agile methodology didn't work they imply<br />that you "did it wrong or skipped some step or you just aren't smart<br />enough to get it." It is really funny too, some saying to embrace<br />change but when you present an alternative you are a heretic.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0tag:blogger.com,1999:blog-8390064019981582628.post-61944530479972809752008-01-21T18:35:00.002-08:002008-01-21T18:36:21.918-08:00Can Code alone convey design information?Is code sufficient for someone to understand the design or additional<br />artifacts needed such as external design documentation?<br /><br />People learn in many ways. People have a preferred method of<br />learning. Some of the current methods of learning are identified as<br />Visual, Auditory, Reading/Writing, and Kinesthetic. In the absence of<br />a physical handicap to one of the sensory systems, I feel that most<br />people have a preferred method of learning for specific topics. When<br />studying literature I find that learning through reading suffices for<br />me. When studying architecture I find that visual learning is most<br />appealing. When studying music I find that listening to music is more<br />meaningful to me than reading the score. When studying mathematical<br />topics I find that at some times a formula suffices and at other<br />times I need a plot or graph. As well when studying chemistry,<br />sometimes formulas suffice but other times 3D visualizations of<br />compounds increase my ability and speed to learn. Does this mean that<br />I am not a visual, nor an auditory, nor a reading/writing learner but<br />that I am a Kinesthetic learner?<br /><br />I read this description of a Kinesthetic learner:<br />The Kinesthetics group learns through all of the senses being<br />stimulated, they also like suitable analogies, real life examples, or<br />metaphors, and they learn through application.<br /><br />I am not sure what "type" of learning I am, but I do feel that I do<br />learn and I do it through many different ways. I use all of my<br />senses to internalize experience.<br /><br />To me there is significant difference in these two statements:<br />"Internalize in the same way" (methods of learning)<br />"Internalize the same" (results of learning)<br /><br />Internalize in some way refers to the preferred method of learning. I<br />might prefer to internalize the design of a software system through<br />the examination of UML diagrams, or I may internalize the design of<br />a software system through the reading of the source code. Two<br />different methods or ways of internalizing a software design. People<br />that prefer UML are people that prefer to internalize the software<br />design in the same way.<br /><br />Internalize the same refers to understanding the correct attributes<br />of the topic. You can see with your eyes and hear with your ears but<br />do you understand within your heart. The eyes and ears are the ways<br />to internalize. The understanding within the heart is that one has<br />truly understood. True understanding can come though many ways, but<br />there is only one understanding.<br /><br />Since I am not formally trained in the field of Learning, my terms<br />and definitions may not be standard, but if one will be patient in my<br />weakness then maybe some learning can occur.<br /><br />Since I know I have learned through Visual, Auditory, Reading/Writing<br />(VAR) then I know I use methods of information presentation based on<br />all of these. I also believe that one can learn to consume new<br />methods of presentation which may become a preferred method of<br />presentation for specific topics. To me it is not conceivable that<br />someone is limited to only one of these but my research on the topic<br />leads me to believe that there are those that do believe that some<br />are limited to one of these presentation methods in order to learn.<br />Working on this assumption (which seems counter intuitive) let's<br />consider the question that has been before the XP group.<br /><br />Is code sufficient for someone to understand the design or additional<br />artifacts needed such as external design documentation?<br /><br />Let's suppose you learn through reading. XP seems to be optimized for<br />this type of learner. After researching in five texts on XP I found<br />that four of the books do not mention the topic of UML. I found all<br />five to focus on little or no documentation. Also simple design and<br />refactoring are the focus of discussion when referring to design.<br /><br />Simple and intent revealing is the description of how source code<br />should be. Why should the code be this way? To avoid ambiguity. If<br />the code is to communicate the design of the system it needs to do so<br />with little or no ambiguity. "Code-talkers" is what I call people<br />that can do this. These people can read and write code easily and<br />through this they can build an understanding of a design that<br />encompasses the code.<br /><br />Code-talkers preferred method of presentation is Reading and Writing.<br />Given a team of code-talkers the hope is that each will understand<br />the same design when they read the same code.<br /><br />I feel that the idea of using code to both capture a design and<br />convey a design seems reasonable since all programmers clearly write<br />code. But I wonder this, is the preferred method of presentation to<br />learn something also the same method the person would use to present<br />the thing that was learned. If you are good at learning through<br />reading does that make you a good writer? If you are good at learning<br />through graphs and charts does that make you capable of producing<br />quality graphs and charts? If a programmer is good at capturing a<br />design in code does it mean that he is good at conveying a design<br />through code?<br /><br />I imagine that there are many that can learn visually through the<br />studying and viewing of paintings. Out of those students of the<br />visual arts, how many of them can communicate through the same<br />medium, how many of them can paint? There seems to be a difference in<br />the way one can learn and the way one can teach or share what they<br />have learned.<br /><br />But back to the question at hand, is the code sufficient to convey a<br />design or are additional artifacts necessary. If you can only learn<br />with a single method of presentation then it would seem that in XP<br />being a Reader would be advantageous. But what if your XP team is<br />made up of a few people that prefer to study design through UML<br />diagrams? In order to get feedback from the entire team there will<br />have to be two methods of presentation of the design, one in code and<br />one in UML. Granted both are visual but are significantly different.<br />I have met many programmers that are code-talkers that can't<br />understand a UML diagram. By introducing these diagram-talkers with<br />these code-talkers the effort for communicating design has increased.<br />Is it worth this increased work?<br /><br />I suggested the following idea to the XP discussion group:<br />Maybe it would be better to hire people for your team that has the<br />same preferred method of presentation of design in order to decrease<br />the effort in communication.<br /><br />A concern was pointed out that having people that "think alike" would<br />be detrimental to creativity.<br /><br />Do preferred methods of presentation affect one's creativity? The<br />thought of me being more creative than someone else just because I<br />can read seems arrogant. The idea that some method of presentation<br />can stimulate more creative thought seems incorrect as well. Chinese<br />are renowned for their ancient wisdom and philosophy. I imagine that<br />the ancient Chinese taught their students with written text (but not<br />limited to that method alone). Should modern students of philosophy<br />switch to studying in Chinese in order to stimulate more create<br />thoughts? What of the ancient Greek philosophers. Were they not<br />considered to be creative in the field of philosophy? But we have two<br />different types of written language, one phonetic and one pictorial.<br />But I delve into areas where I have superficial knowledge, that is,<br />the history of education in ancient China and ancient Greece.<br /><br />Is a blind person incapable of being as creative as a seeing person?<br />A deaf person to a hearing person? I seem to recall that Beethoven<br />wrote symphonies while he was deaf. Granted Beethoven once heard<br />sound, but he didn't lose his creativity with the loss of the ability<br />to hear.<br /><br />People with high IQ's are not necessarily considered creative<br />individuals either.<br /><br />Were the ancient Aborigines of Australia less creative than the<br />Renaissance man of Italy of France?<br /><br />It is suggested that creativity is not recognized in its own time but<br />recognized at a later date. Large steps forward in some field are<br />often not recognized for their foresight and worth for many years.<br /><br />A definition of creativity I like because it allows for everyone to<br />be creative is this - creativity is work hard and going the extra<br />mile to produce a quality product for a given domain. Practice and<br />not innate talent seperates the creative from the mere compitent<br />technician. (These definitions were found on the web).<br /><br />I conclude that a team made up of people with different preferred<br />methods of presentation does not increase or descrease the creativity<br />of the team.<br /><br />So, if creativity is not at risk then what is wrong with hiring<br />people with the same preferred method of presenting design?<br />(Remember we are working under the premise that some people have only<br />one preferred method of receiving information, Reader/Writer, Visual,<br />or Auditory. I personally don't think people are so one-dimensional).<br />Would not not increase accurate communication? If you have to present<br />the design in code an UML do both descriptions describe the same<br />thing?<br /><br />Eventhough I think hiring people that prefer the same methods of<br />presentation will not hurt creativity, I don't feel that it is<br />realistic. When hiring a programmer there are many important factors<br />that must be considered.<br />From my experience most developers can read code well and understand<br />UML well. If they are deficient in an area I have seen people learn<br />how to read a UML diagram. Learning to read code is not as easy.<br /><br />This brings me to XP's concern of simple and intent revealing code.<br />These two considerations are necessary inorder to have a chance at<br />using the code as the design document or in other words "reading<br />code."<br /><br />My first concern is that there is no such thing as simple code.<br />Simple code is so subjective that few can agree on even the most well<br />known algorithm's varied implementations as to which implementation<br />is the simplest.<br /><br />I would suggest that we can determine if code is over-engineered.<br />Over-engineerd code is code that has functionality that is never<br />called upon or used. TDD and DBU both address this by only writing<br />code that is needed. In Object Oriented programming you will see over-<br />engineered classes that have many overloaded methods to do the same<br />thing. The overloaded methods exist just incase someone wants to call<br />the class in a slightly different way. These types of methods don't<br />come about if one designs code using DBU or TDD.<br /><br />Intent revealing code is also important. This is done through careful<br />use of names, naming conventions, and coding conventions. Code<br />comments can be helpful if kept up to date.<br /><br />So, if you have intent revealing code that is not over-engineered and<br />you have code-talkers you can have the code be the design as long as<br />the only audience of the design is the programmers. If someone that<br />is outside of the team wants to see a design then you have a<br />situation. XP addresses this by saying the design isn't really want<br />you want to see (these aren't the droids you are looking for), you<br />want to see delivered and working code.<br /><br />If you use UML to describe the design does that mean you don't care<br />about not over-engineered code and code that does not reveal its<br />intent. No.<br /><br />Do methods embrace diversity or do they seek conformity? Do methods<br />seek out people that are alike in some way? Once again I will use XP<br />as an example.<br /><br />Pair programming is part of XP. This is needed inorder to assist with<br />design as you go and making sure that the code is not over-engineered<br />and intent revealing. I know a programmer that has a diagnosed<br />disorder in which he is terrified of close interaction with people.<br />This person is not capable of pair programming. Does XP reach out to<br />this person seeking their unique contributions or does it shun this<br />person because of his inability to pair program.<br /><br />I remember a study where it was shown that women learn better in<br />quiet environments and men learn better where there is background<br />commotion. With the common work area of XP does this environment<br />empower the person that needs quiet and no distractions or does it<br />reject this persons because they can not excel in the environment?<br /><br />If we are going to require certain abilities from the team then are<br />there other abilities that should be required?<br /><br />Any methodology will exclude one set of attributes while inviting<br />another set.<br /><br />It has been suggested by a friend that programming itself is a Visual<br />task and has rewarded only the visual learners and excluded the<br />others. I can imagine this to be true.<br /><br />In conclusion I feel that most people have varied preferred methods<br />of presentation for different topics. I also feel than many people<br />can learn new methods of presentation. A person that prefers a<br />particular method of presentation when receiving information doesn't<br />mean that person is capable of using that same method of presentation<br />when conveying what they know or understand. People with the same<br />preferred method of presentation do not think alike, two readers can<br />read the same text and come to different conclusions. Creativity is<br />not controlled by a person's preferred method of presentation.<br />Methodologies optimize for certain characteristics and exploits the<br />commonality. XP needs people that can work in pairs, work in<br />environments that potentially have more commotion than say a private<br />office, and can understand software design through reading code.Geoff Slinkerhttp://www.blogger.com/profile/12365501393247949005noreply@blogger.com0