There is no one leader. Typically there is one manager. The leader rises to the occasion and situation. Leader is not a title once bestowed and thusly endures, but it is a adjective for a moment. Granted there are great leaders but what makes them great? Is it that the occasion and situation in which they rise is a situation with a fundamental concern such of freedom or religious belief? Is it that the situation itself is of great concern?
For instance let me give an example concerning the founding of the United States of America (based upon my opinion that the founding of the USA is a great and good thing). A leader arises in a situation to give guidance and share knowledge. The masses of people that lived in the colonies did not come to a common and practical definition of government. The common people may not have ever defined a government and constitution. However the fundamental need was something that was understood or was spreading in popularity. Those that had opinion, education, experience, and vision concerning sovereignty, how power can be used and misused, and other pertinent issues rose to the occasion. These leaders left behind a document outlining what should be valued and what should be shunned. This document then is used in the managing of the affairs.
The "work place" tries to identify a leader and then assign them the task of being "the" leader from that point forward. Maybe it comes from military like organizations, maybe not, I do not know. Just because you were brilliant in one situation does not mean you will be so again in a different situation.
Is a leader measured by his followers? I would think not. The follower can only be measured by how well the follower studies and internalizes the teachings of the leader. That is why I say that one should always understand the fundamental reasons behind a method. Lets say that some "leaders" in software development propose that testing first is better than testing later. I want to know why it may be true and I care less about who said it. As the follower if I understand they why's then I can manage myself and I do not have to be lead continuously.
What if a leader has no followers? It does not reflect that the person did not rise above a situation. Maybe this person was in a unique situation. Or maybe the others in the same situation are blind to the advantage that the leader expounds. The number of followers do not validate or invalidate the leader.
In business the number of people that are under a Manager is important. Head count is an essential part of the leverage and power of a manager in business. This head count should not be confused with "followers" but honestly is more inline with the concept of "cattle and ownership".
I do not believe that Management is a science and Leadership and art. As a matter of fact I do not even separate science and art.
Do we leave tactical issues to Leaders and strategic issues to Managers? I find this to be overly simplistic.
Leaders help define a set of guidelines for the situation as they traverse the situation.
A fundamental attribute of a leader is selflessness. This is not a necessary or needed attribute of a manager. A leader is willing to suffer the results of his guidance along with those that follow. If there is a group that is following a leader and the group fails the leader does not blame the group for being poor followers but instead accepts responsibility for leading those that followed and usually blames himself for not having an better understanding of those individuals that were following. Management behaves differently is this situation.
I do not feel that any other list of leadership attributes come close to that of selflessness.
Can everyone be a leader? Yes in that I think we are all equal in capacity (generally). Will everyone seize an opportunity to lead when it presents itself? No. Not in my opinion. Even if someone is capable of leading in a situation there are infinite reasons why the person may chose to not act.
Here is a snippet on a paper I wrote that includes sections on leadership and management.
Leadership
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.
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? ... "
Leadership cannot be taught. Quoting Dr. Huge Nibley,
"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.
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.
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... "
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.
Trust is the key and here is what Mr. Semler had to say,
"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."
http://home.att.net/~geoffrey.slinker/maverick/MaverickDevelopment.html
Sunday, November 26, 2006
Friday, November 24, 2006
What makes a good Software Design?
What makes a good software design? Can software be good and have a poor design?
I will address the second question first. Can software be good and have a poor design? I think so. Of course this depends on my defintion of good. Good software meets the current goals of the user. For instance the software does what the user wants and it does it with no errors, mistakes, or unwanted side effects. The user usually does not care what language the software was developed with, or what process was used to guide development, or how much the programmers were paid to write the software, or even if the software has a good design.
Software design is a practice that addresses issues the programmers find important. Such issues are changeability, extensibility, understandability, usability, and verifiability (if these are even words).
In my opinion code must meet the usability quality in order for the design to be considered good. What does this mean?
Code is developed to be called or in other words to be used. If the design is such that the code is easily called then it has an improved design. What makes code easily called? If it is easy to setup the state necessary to initiate a meaningful call. What makes state setup easy? That depends on the system and problem domain. Often this is an attribute of coupling and cohesion. Therefore, easily callable code is often losely coupled and cohesive code.
A good software design will make it possible to verify the software. How do you verify software? By using the code. Do you see the relationship? Usable code has a relationship to code verification. The easier it is to setup a call into the system maps directly to the ease of testing, validating, and verifying the sytem.
The test that exercises code is just another user of the code. Therefore when you write code you have at least to customers or consumers of the code. The first customer is some part of the overall system you are developing. The second customer is the test code that exercises the code you are developing. There are always at leat these two customers. If the first customer doesn't exist then why bother writing the code? If the second customer doesn't exist then what will you use in place of testing code to exercise your code?
A good software design is expressed in code that is usable. The easier it is to use the better. This ease of use reflects the coupling and cohesion of the abstract model. Usable software can be used by multiple customers. One customer should be a verification customer which is a piece of code to use your code and check if your code did what is expected. I believe this leads to the important axiom that testable code is code with a good design. I think that testability is a subset of usability.
Geoff
I will address the second question first. Can software be good and have a poor design? I think so. Of course this depends on my defintion of good. Good software meets the current goals of the user. For instance the software does what the user wants and it does it with no errors, mistakes, or unwanted side effects. The user usually does not care what language the software was developed with, or what process was used to guide development, or how much the programmers were paid to write the software, or even if the software has a good design.
Software design is a practice that addresses issues the programmers find important. Such issues are changeability, extensibility, understandability, usability, and verifiability (if these are even words).
In my opinion code must meet the usability quality in order for the design to be considered good. What does this mean?
Code is developed to be called or in other words to be used. If the design is such that the code is easily called then it has an improved design. What makes code easily called? If it is easy to setup the state necessary to initiate a meaningful call. What makes state setup easy? That depends on the system and problem domain. Often this is an attribute of coupling and cohesion. Therefore, easily callable code is often losely coupled and cohesive code.
A good software design will make it possible to verify the software. How do you verify software? By using the code. Do you see the relationship? Usable code has a relationship to code verification. The easier it is to setup a call into the system maps directly to the ease of testing, validating, and verifying the sytem.
The test that exercises code is just another user of the code. Therefore when you write code you have at least to customers or consumers of the code. The first customer is some part of the overall system you are developing. The second customer is the test code that exercises the code you are developing. There are always at leat these two customers. If the first customer doesn't exist then why bother writing the code? If the second customer doesn't exist then what will you use in place of testing code to exercise your code?
A good software design is expressed in code that is usable. The easier it is to use the better. This ease of use reflects the coupling and cohesion of the abstract model. Usable software can be used by multiple customers. One customer should be a verification customer which is a piece of code to use your code and check if your code did what is expected. I believe this leads to the important axiom that testable code is code with a good design. I think that testability is a subset of usability.
Geoff
Wednesday, November 08, 2006
Democratic Workplaces
WorldBlu has started a search for the Most Democratic Workplaces.
The WorldBlu Search: November 1, 2006 - February 16, 2007:
The WorldBlu Search for the Most Democratic Workplaces is a GLOBAL search from November 1, 2006 until February 16, 2007 designed to identify organizations from the for-profit, non-profit, government, and education sectors practicing organizational democracy.
Recognizing the Mavericks, Inspiring Others:
We believe there are many highly successful and profitable – yet often unnoticed – examples of democracy in the workplace. These organizations are defying convention, rewriting the rules of business, and pioneering the next generation of organizational design and leadership. The WorldBlu List of Most Democratic Workplaces seeks to shine a spotlight on these champions of freedom and inspire others in the process.
The WorldBlu List of Most Democratic Workplaces 2007:
On March 6, 2007, WorldBlu will announce the first annual WorldBlu List of Most Democratic Workplaces in conjunction with the celebration of Democracy in the Workplace Day.
How it Works:
Organizations apply to have their employees take the online WorldBlu Democratic Workplace Scorecard which measures the degree of organizational democracy in their workplace. The WorldBlu List will be comprised of organizations that took survey and scored at the top level, identifying them as one of the most democratic workplaces in the world. There is no fee to apply.
All Sectors Invited to Participate:
The WorldBlu List is open to any organization from the for-profit, non-profit, government and education sectors, as long as the organization has at least five regular full-time or part-time employees and has been in operation for at least three years.
Learn More + Get Started:
To learn more or have your organization get started now to apply for the WorldBlu List, please go to www.worldblu.com .
If you are interested in discussing "Democratic Workplaces" there is a users group found at Maverick Software Development
The WorldBlu Search: November 1, 2006 - February 16, 2007:
The WorldBlu Search for the Most Democratic Workplaces is a GLOBAL search from November 1, 2006 until February 16, 2007 designed to identify organizations from the for-profit, non-profit, government, and education sectors practicing organizational democracy.
Recognizing the Mavericks, Inspiring Others:
We believe there are many highly successful and profitable – yet often unnoticed – examples of democracy in the workplace. These organizations are defying convention, rewriting the rules of business, and pioneering the next generation of organizational design and leadership. The WorldBlu List of Most Democratic Workplaces seeks to shine a spotlight on these champions of freedom and inspire others in the process.
The WorldBlu List of Most Democratic Workplaces 2007:
On March 6, 2007, WorldBlu will announce the first annual WorldBlu List of Most Democratic Workplaces in conjunction with the celebration of Democracy in the Workplace Day.
How it Works:
Organizations apply to have their employees take the online WorldBlu Democratic Workplace Scorecard which measures the degree of organizational democracy in their workplace. The WorldBlu List will be comprised of organizations that took survey and scored at the top level, identifying them as one of the most democratic workplaces in the world. There is no fee to apply.
All Sectors Invited to Participate:
The WorldBlu List is open to any organization from the for-profit, non-profit, government and education sectors, as long as the organization has at least five regular full-time or part-time employees and has been in operation for at least three years.
Learn More + Get Started:
To learn more or have your organization get started now to apply for the WorldBlu List, please go to www.worldblu.com .
If you are interested in discussing "Democratic Workplaces" there is a users group found at Maverick Software Development
Wednesday, November 01, 2006
Composite UI Application Block Model View Presenter
Model View Presenter
is a design pattern support by CAB and the Smart Client Software Factory (SCSF).
A View is a SmartPart.
The Presenter calls methods of the View to update the information the View displays. The View should expose its methods to the Presenter through an Interface. The Presenter stores a reference to the View's interface.
In my examples I have updated UserButton and added IUserButton and UserButtonPresenter.
Here is IUserButton.cs:
Here is the new UserButton.cs:
Here is the new UserButtonPresenter.cs:
How did I know to modify the Dispose methods to remove the Presenter? I looked at lots of code I found on the net.
Listening to a PodCast I learned that a WorkItem is two things.
I moved the Event Publisher inside of the UserButton and put it in the UserButtonPresenter. I am not sure if it "should" be there it just seemed like the thing to do.
In the UserButtonPresenter when the UserButtonClicked method is invoked it does two things:
After I completed these code changes I then installed and started using the Smart Client Software Factory. I used the Guidance Package that was installed into Visual Studio 2005 to create a new solution that uses CAB and the MVP pattern. The guidance package auto generated all of the code. Granted the auto generated code included things I had not yet studied but I found that I have turned the learning curve and have enough foundation and a feel for CAB that I am able to understand the auto generated code. So, this will probably be my last blog entry on the Composite UI Application Block. I have a lot to learn still but I can see enough now that I don't feel like I am lost in the dark.
By the way, I have been learning CAB in this fashion because it is part of an approach I am working on called Experience Driven Development (EDD) and has a fundamental practices Design by Use and Software Reconn.
is a design pattern support by CAB and the Smart Client Software Factory (SCSF).
A View is a SmartPart.
The Presenter calls methods of the View to update the information the View displays. The View should expose its methods to the Presenter through an Interface. The Presenter stores a reference to the View's interface.
In my examples I have updated UserButton and added IUserButton and UserButtonPresenter.
Here is IUserButton.cs:
using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;
namespace CABTestOne
{
public interface IUserButton
{
void SetColor( Color color );
}
}
Here is the new UserButton.cs:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Drawing;
using System.Data;
using System.Text;
using System.Windows.Forms;
using Microsoft.Practices.CompositeUI.SmartParts;
using Microsoft.Practices.CompositeUI.EventBroker;
using Microsoft.Practices.ObjectBuilder;
namespace CABTestOne
{
[SmartPart]
public partial class UserButton : UserControl, IUserButton
{
public MyMessagePublisher publisher;
protected UserButtonPresenter _userButtonPresenter;
public UserButton( )
{
InitializeComponent( );
}
private void button1_MouseClick( object sender, MouseEventArgs e )
{
_userButtonPresenter.UserButtonClicked( sender, e );
publisher.UserButtonClicked( sender, e );
}
[CreateNew]
public UserButtonPresenter userButtonPresenter
{
set
{
_userButtonPresenter = value;
_userButtonPresenter.userButton = this;
}
}
public void SetColor( Color color )
{
this.button1.BackColor = color;
}
}
}
Here is the new UserButtonPresenter.cs:
[ServiceDependency] tells the CAB framework to get the WorkItem from the collection of services maintained by CAB. The UserButtonPresenter needs the WorkItem in order to enhance the dispose method to remove itself from the WorkItem's Item collection.
using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;
using System.Windows.Forms;
using Microsoft.Practices.ObjectBuilder;
using Microsoft.Practices.CompositeUI;
using Microsoft.Practices.CompositeUI.EventBroker;
namespace CABTestOne
{
public class UserButtonPresenter : IDisposable
{
protected WorkItem _workItem;
protected IUserButton _userButton;
~UserButtonPresenter( )
{
Dispose(false);
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
if( _workItem != null )
{
_workItem.Items.Remove( this );
}
}
}
[ServiceDependency]
public WorkItem workItem
{
set
{
_workItem = value;
}
}
public IUserButton userButton
{
set
{
_userButton = value;
}
}
[EventPublication( "topic://CABTestOne/UserButtonClick", PublicationScope.Global )]
public event EventHandlerUserButtonClick;
public void UserButtonClicked( object sender, MouseEventArgs e )
{
_userButton.SetColor( System.Drawing.Color.Blue );
if( UserButtonClick != null )
{
UserButtonClick( this, null );
}
}
}
}
How did I know to modify the Dispose methods to remove the Presenter? I looked at lots of code I found on the net.
Listening to a PodCast I learned that a WorkItem is two things.
- Scoping Container
- Lifetime Manager
I moved the Event Publisher inside of the UserButton and put it in the UserButtonPresenter. I am not sure if it "should" be there it just seemed like the thing to do.
In the UserButtonPresenter when the UserButtonClicked method is invoked it does two things:
- Sets the color of the UserButton
- Publishes the UserButtonClick event.
After I completed these code changes I then installed and started using the Smart Client Software Factory. I used the Guidance Package that was installed into Visual Studio 2005 to create a new solution that uses CAB and the MVP pattern. The guidance package auto generated all of the code. Granted the auto generated code included things I had not yet studied but I found that I have turned the learning curve and have enough foundation and a feel for CAB that I am able to understand the auto generated code. So, this will probably be my last blog entry on the Composite UI Application Block. I have a lot to learn still but I can see enough now that I don't feel like I am lost in the dark.
By the way, I have been learning CAB in this fashion because it is part of an approach I am working on called Experience Driven Development (EDD) and has a fundamental practices Design by Use and Software Reconn.
Podcasts and Links about CAB
While experimenting and learning the Composite UI Application Block I am continuously searching for information. I have found these podcasts to be helpful.
Dr. Dobb's .Net Cast
Composite UI App Block (CAB) Internals
Understanding Dependency Injection
The Power of WorkItems, Events, and Services
Cabpedia
is proving to be very helpful.
Dr. Dobb's .Net Cast
Composite UI App Block (CAB) Internals
Understanding Dependency Injection
The Power of WorkItems, Events, and Services
Cabpedia
is proving to be very helpful.
Subscribe to:
Posts (Atom)