The essay contrasts two different free software development models: The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers; and, The Bazaar model, in which the code is developed over the Internet in view of the public.

The essay helped convince most existing open source and free software projects to adopt Bazaar-style open development models, fully or partially

Raymond posits that there are 19 guidelines for creating good open source software:

1. Every good work of software starts by scratching a developer’s personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. Plan to throw one away; you will, anyhow.
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around.
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible – and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

A user persona is a representation of the goals and behaviour of a real group of users. In most cases, personas are synthesised from data collected from interviews with users. They are captured in 1–2 page descriptions that include behaviour patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. For each product, more than one persona is usually created, but one persona should always be the primary focus for the design.

The use of personas as a technique was popularised by Alan Cooper in his 1999 book The Inmates are Running the Asylum. The book outlines the general characteristics, uses, and best practices for creating personas.

So, how do you actually go about creating a persona or a set of personas for your project? The following is based upon work carried out by Dr. Lene Nielsen in her 2004 thesis and published in HCI Vistas.

Finding the Users

The initial step is to get hold of as much knowledge of the users as possible.

Questions asked:

• Who are the users?
• How many are they?
• What do they do within the system?

Methods used:

• Contextual interviews
• Online surveys
• Observations
• Second-hand information
• Reports (e.g. from marketing)
• Cultural probes

Documents produced:

• Reports

Building an Hypothesis

Working with personas really means focusing on users in a certain context, which originates from the project that is being researched. Often companies have a certain way of talking about their users, or should we say customers, which does not take into account the different context in which the users use a website or a system.

Questions asked:

• What are the differences between the users?

Methods used:

• Looking at the material
• Labelling groups of people

Documents produced:

• A draft description of the target groups

Verifications

The focus here is on finding data that supports the initial patterns and at the same time supports the personas descriptions and the scenario writing.

Questions asked:

• Data for personas — What are the likes/dislikes, needs and values?
• Data for situations — What are the areas of work and work conditions?
• Data for scenarios — What are the work strategies and goals. What are the information strategies and goals?

Methods used:

• Quantitative data collection

Documents produced:

• Reports

Finding Patterns

Questions asked:

• Does the initial labelling hold true?
• Are there other groups to consider?
• Are all equally important?

Methods used:

• Categorisation
• Task analysis

Documents produced:

• Descriptions of categories

Constructing Personas

A crucial step is what to include in a persona’s description and how to avoid creating stereotypes if at all possible. The purpose of a persona is not to describe users as such, but to create solutions that use the needs of the persona as a starting point.

Questions asked:

• What are their basic attributes — name, age, gender?
• What is their psyche — introvert/extrovert?
• What is their background — occupation and interests?
• What are their emotions and attitude towards technology, the company or the information needed?
• What are their personal traits?

Methods used:

• Categorisation

Documents produced:

• Descriptions of categories

Defining Situations

The real purpose of the personas is to create scenarios from the descriptions. Each need or situation is the beginning for a scenario.

Questions asked:

• What is the need of this persona?
• What is the situation?

Methods used:

• Looking for situations and needs in the data

Documents produced:

• Catalogue of needs and situations

Validation and Buy-in

Personas are often viewed as a means for communicating users (read: customers) to developers and stakeholders, but it is as much about a process that ensures a user-centered development.

Questions asked:

• Do you know someone like this?

Methods used:

• People who know (of) the persona read and comment on the persona descriptions

Dissemination of Knowledge

Not only do personas need to be distributed to everybody on the project, but also the data behind the personas and how and for what you are to use the personas. Many projects forget to inform and teach developers and designers on how to use the personas, how to think in scenarios or how to use them in the use-cases.

Questions asked:

• How can we share the personas with the organisation?

Methods used:

• Posters
• Meetings
• Emails
• Events

Creating Scenarios

A scenario is like a story, it has a main character (the persona) a setting (somewhere the action takes place), it has a goal (what the persona wants to achieve), it has actions that lead to the goal (interactions with the system/website/device), and last but not least, it has obstacles that block the way to the goal. Scenarios should be both positive and negative.

Questions asked:

• In a given situation, with a given goal, what happens when the persona uses the technology?

Methods used:

• The narrative scenario, using personas, descriptions and situations to form scenarios

Documents produced:

• Sceanrios
• Use Cases
• Requirement Specifications

On-going Development

Finally, always update information on the personas, afterall you may find some interesting scenarios that weren’t originally considered, or new situations in which the system/website/device is used. Indeed you may discover new personas!

Questions asked:

• Does new information alter the personas?

Methods used:

• Usability tests
• Focus groups
• Surveys (online)

The following cartoon, by blogged about by Alex Gorbatchev, is a modern take on an old, yet still relevant, problem; the reasons for software engineering failures.

Designing systems today is difficult because there is no consensus on what the problems are, let alone how to resolve them.

Software engineering is often used to solve complex problems, problems where it’s impossible to visualise all the difficulties you’ll run into without actually building the software. This has led to what is known as Wicked Problems. In other words, writing code doesn’t kill projects, too much planning, too much functionality and too many stakeholders do!

Wicked problems arise when an organization must deal with something new, with change, and when multiple stakeholders have different ideas about how the change should take place.

Every wicked problem can be considered a symptom of another problem.

The article goes on to recommend the iterative development process, first proposed by Takeuchi and Nonaka in “The New New Product Development Game” called Scrum. An iterative, as opposed to a Waterfall, process is clearly a step in the right direction. The customer really needed a simple tyre swing but couldn’t articulate that in a meaningful way. Since we’re software developers, not Zen Masters, an answer is to quickly develop a solution in for the customer and keep evolving that solution based on real usage. That way, we can get from the plank to the tyre swing without the need for the roller-coaster ride of complication.

So what is the distinction between a leader and a manager? Will the definitions help?

Leader noun

• someone or something that leads or guides others.
• someone who organises or is in charge of a group.

Manager noun (abbreviation Mgr)

• someone who manages, especially someone in overall charge or control of a commercial enterprise, organisation, project, etc.

Does this help me…not yet!

Both a manager and a leader may know the business reasonably well, but the leader must know the business to a finer degree and from a different view point. They must grasp the underlying market forces that determine the past and present trends in the businesses niche, so that they can generate a vision and strategy to bring about its future development and growth. A crucial sign of a good leader is an honest attitude towards the facts and objective truth. Conversely, a subjective leader obscures the facts for the sake of narrow self-interest, partisan interest or prejudice.

Effective leaders continually probe all levels of the organisation for information, challenging their own perceptions and validating the facts. They talk to their constituents and employees to find out what is working and what is not. They keep an open mind to the knowledge they gain. An important source of information for a leader is the knowledge of the mistakes and failures that have been and are being made within their organisation.

Leaders conquer the context, the turbulent and ambiguous events that conspire to blur the facts, while managers surrender to the events in a reactionary manner.

Leaders investigate reality, taking the pertinent factors and analysing them carefully. On the basis they produce visions, concepts, plans and programs of change. Managers adopt the truth from others and implement it without regard to the facts.

There is a profound difference between leaders and managers. A good manager does things right whilst a good leader does the right thing. Doing the right thing implies a goal, a direction, an objective, a vision, a dream, a strategy, a path, a reach.

Many people spend their lives engrossed in the ‘rat-race’, attempting to climb the corporate management ladder in a vein attempt to beat mediocrity and make a difference. Unfortunately, many find themselves climbing the wrong ladder. Most companies and organisations become over-managed through this constant, unending, highly competitive race and under-led by those who lack vision. The managers accomplish nothing or the wrong things beautifully and efficiently. They climb the wrong ladder.

Managing is as much about efficiency as leadership is about effectiveness. Managing is about how things need to be done, leadership is about what things need to be done and why these things should be carried out. Management is about systems, controls, procedures, policies and structures whereas leadership is about, trust, vision and hum capital, people.

Leadership is about innovating concepts, inspiring others and initiating projects. Management is about carrying out these visions and managing the status quo. Leadership is creative, adaptive and agile. Leadership looks to the future whilst also being mindful of the bottom line.

Leaders base their vision, appeal and integrity on a careful estimation of the facts, trends and contradictions. They develop the means to re-define the status quo so that their vision can be realised, hopefully, successfully, whilst also enrolling others into the vision of the future. Without, other peoples buy in, a vision will stall and a period of transition will ensue. Leaders, therefore, have to empower others to accomplish the over-arching goal whilst also rewarding their achievements.

There is a profound difference between management and leadership, but both are important. To manage means “to bring about or succeed in accomplishing, sometimes despite difficulty or hardship“. To Lead means “to guide in direction, course, action, opinion, etc.” The distinction is important.

The most dramatic differences between leaders and managers are found at the extremes. Poor leaders are despots while poor managers are bureaucrats. Leadership is a human process and management is a resource allocation process. Both are important and in many instances managers need to also perform as leaders. Indeed first-class managers have significant leadership ability.

So where does this leave me? My opening gambit included the words “…an important aspect of my role is managing expectations, ideas and developments…” this must naturally lead me to a combination of both a leader and manager. Indeed, in my new role as a web development consultant, I have to set directions for developing concepts and applications whilst also planning, organising and promoting effective action of the task at hand. So I could say I am in a period of transition. In the past few years I have learnt much from those I consider mentors, whether they were aware or not. I have seen how things are managed and lead and from these experiences have built upon my own skill-set. I can neither categorically say I am a leader or a manager, or say what I would rather be; this is something that can only come with time.

This Fusedocs file contains the Fusedoc DTD, an example ColdFusion page and documentation on the Fusedoc methodology.