User Driven Development

When we develop software, how do we know which features should we implement? Which features users will use and which will not? User Driven Development is a methodology that helps answer this question early on in the development process, so you do not waste time and money on useless work.


User Driven Development is the Agile Development practices revised to incorporate the best Lean Startups principles, like the Build-Measure-Learn loop and the concept of Minimum Viable Product.



This post is described on its own blog. Check:

http://UserDrivenDevelopment.blogspot.com

Why Stand-up Meetings are a waste of time

A Stand-up Meeting is a reporting meeting.

Reporting things doesn't actually make you think. And just to hear a report that is not necessarily your business is also quite boring. Even if it is for just 15 minutes. Who has participated regularly in Stand-up Meetings understands this sentiment well: It's Not Just Standing Up: Patterns for Daily Standup Meetings

The three standard questions for a standup meeting ("What did I do yesterday? What will I do today? What are my obstacles?") doesn't oblige us to pro-act. I suggest changing them to just one question:

"What am I going to improve next?"

The idea is that each developer will now have to think about: "What I am going to do to solve the problem I am facing at the moment?". It is much more interesting to listen to (and discuss about) proposals for solutions rather than problem reports.

It is common the development team having a lot of opinions on how to solve the company's day-to-day problems. But, unfortunately, most often what happens is that developers just don't talk about it.
The company's environment needs to be accessible to the solutions proposed by the employees. If the development team is not encouraged to offer solutions and doesn't have the authority to implement them, the interest on keep proposing these solutions is rapidly lost.





Improvement Board    x    Task Board

The concept of improvement here in this context has two aspects:

First, the development team is usually aware of  the best solutions for the software problems, because the developers are the people who have the deeper contact with the source code. So, it is very important for a Lean development environment to promote a proactive mindset in developers, instead of "Here we have the Task Board that the developers are running as if they were robots."

The second aspect is that, on the other hand, besides guaranteeing that solutions proposed by the developers are being heard, in a Lean software development is also very important that the end user is directly involved in these discussions. Because if a task simply does not add any value to the end user, even if it is a great solution, still usually is just a waste of time and money.

Method to Develop UNCERTAIN Software

Eric Ries is brilliantly teaching us how to deal with uncertainty in the business world. It is about time to take advantage of these Lean Startups techniques and learn how to apply them to the whole software development process, not only for Startups.

Product Backlog no more!

"You gotta start with the customer experience and works backward to the technology. You can’t start with the technology and try to figure out where you are going to sell it." (Steve Jobs,  WWDC 1997)

The Pareto Principle, unfortunately, has being fully applied to software development. In fact, still today 80% of the developed software is being wasted (CHAOS Report Standish Group 2002). An enourmous amount of money. We should develop software only after making sure that will be used.

It is very common in software projects not to know who the end users are. Is the Product Owner of your team a real user? Or are they only intermediaries? Only the end users can somehow clarify to the development team what they want to use and how they want to use it. Only in a very close relationship with the end users the right features can be revealed.

The "Build-Measure-Learn" cycle, defined for Lean Startups, should also be applied for the software development process since the beginning. In practice this means:

Always having the minimum amount of tasks in the Task Board, just enough to support the next conversation with the end users. (Build) 

Measure closely the production environment results. How the end users are actually using the features that have been developed. (Measure)

Stay completely open to the new directions that the end users will reveal while using the software. Avoid having a Product Backlog already predetermined, preventing the natural flow of the software needs. (Learn)

Figure 1: The Build-Measure-Learn loop from the Lean Startups.

Even for very big and complex applications, it is when is more important to avoid waste. The first thing to be done is divide the big and complex application in a lot of small independent projects, which can be focused and managed in a more accurately and realistic way. After that, clearly define who the end users are and bring them as close as possible to the development team. When the software projects are simple and small, it's much easier for the users to absorb the business concepts, understand the technical needs and provide accurate feedback. As well as much faster and cheaper for the development team to produce the right results. (Further reading: Mini & Lean Applications)

"(...) And some mistakes we made by the way. Some mistakes will be made along the way. That’s good because at least some decisions are being made along the way. And we’ll find the mistakes and we’ll fix them."
 (Steve Jobs, WWDC 1997)  R.I.P.    :_-(   

A Method to Develop Uncertain Software

Figure 2: The Agile Development poster adapted for the Uncertain Software

Agile Development  is undoubtedly a major step forward for humanity. But even with the Agile methodologies and tools, there is still too much waste, too much backlogging, too much repeated documentation and too much planning in software development.

The Agile Development process starts with building the Product Backlog. However, the Uncertain Method starts the development process defining the Minimum Viable Products for the application.

To identify an MVP it is necessary a lot of knowledge about the users (and customers) of the application, otherwise the software will never be viable (Read also: Defining your MVP). It is very common Product Owners having a hard time to minimize and prioritize requirements. They usually want everything to be done, and urgently. Not rarely a Product Backlog has several items with the highest priority. Even if they still think that everything can be done, the development process can be facilitated by identifying which  feature they want to be the first immediately delivered, that means, just put the highest priorities in an order and select only the top one. The goal is to give a starting point to the development team. From there, the next priorities should be defined from the results of the interviews with the end users.

I totally understand that almost every feature has external dependencies. It is difficult to isolate and develop them independently. But if the development team can simulate (mock-up) the external dependencies and focus on each MVP separately, the prospects become much clearer and new possibilities of implementation easily opens up. The advantages are enormous. In fact, what usually happens is that several of this dependencies will not need to be implemented anymore because the plan normally changes when you start to dialogue with the end users.

"It is necessary to deeply understand the essence of a product in order to strip away the non-essential parts." (Jonathan Ive, Apple's chief designer)

Each development team should focus on its own MVP and start working with the first prioritized feature. A Task Board can be used, Stand up meetings, retrospectives, etc, but the most important thing is to deliver something as quickly as possible in the production environment, so the end users can personally manipulate the software and the Build, Measure, Learn loop can run the most efficient possible.

Non-systemic approaches are very helpful, like low fidelity prototypes or any other User eXperience practice. But keep in mind that an end user interview in front of the working software is priceless to a developer. The psychological atmosphere that is formed in a moment like this provides unique insights to the developer with so much valuable information that no documentation and no intermediary can possibly describe it.

Figure 3: The Agile Manifesto revised for the Uncertain Software

Once users are already satisfied with the current MVP, it is time to start the next one. The relationship with the users at this time will probably be much more fluent. It will be easier to identify what they want next. And often they don't care so much if the software is super flexible and adaptive, sometimes even if it has some minor errors. What they normally prefer is a software that has personality, something that makes them say "That's cool!".

No Rights Reserved. Please copy us!

The concept of Mini (& Lean) Apps

After I installed the app from my bank on my phone, I never went back to the website to access my bank account. Even if the computer is in front of me, I still prefer to pick up the phone. The cell phone app from my bank is much more practical, concise and objective.

Why don't we follow the same principles of a mobile app for web sites? This is the idea of ​​Web Apps (see also http://en.wikipedia.org/wiki/Web_app).

My bank's website today is a white elephant. It has a lot of information and functionalities, but it gets all mixed in navigation. I can do almost everything on the website that I could do in the bank agency. In terms of availability, this is a great advantage. But by the side of objectivity, excessive opportunities are harmful.

Note: I'm a client of several different banks and their websites all have these same characteristics.

I'm advocating here the transformation of enterprise applications into several Mini Apps, with very practical goals, performing very specific tasks with simplicity. The users set up and work in their browser or their desktop the most common tasks, when needed, if needed. All set in accordance with their interests, as they do in their smart phones.

Lets see other examples:

How about Microsoft Word as a "marketplace" containing a lot of mini apps, instead of one big and complex desktop application? When you only want to create, open, edit, save or print a text document, you use the main app (simple and practical as a notepad). But if you want to insert Cliparts, Wordarts, Charts, Cross References, Symbols, etc., then these functions would be in a separated mini app, with a more specific and targeted navigation, much easier to use and the most important, visible only in case you need it.

And how about your company's intranet looking like the screen of your cell phone? The HR App separated from the app for corporate events, which are separated from the contact page of the staff's team. Each one with their own navigation, their simplified interfaces and peculiarities. You no longer need to navigate through a bunch of links to view your paycheck.

The idea is that each Mini App is a whole product and a peace of a large application. Independent and autonomous. You type your bank's URL in your browser and see in the home page only the apps you chose to use. If you have a credit card but have no investments with this bank, then you see the app to access your card in a practical and simplified way. The investments links would not be visible at all times, confusing you.


Developing Mini Apps

Developing complex applications as a set of Mini Apps is a great facility for users. But the biggest advantage is the development cost.

With Mini Apps, the development team can focus more precisely on the several Minimum Viable Products that the application has, and if they are developed independently of each other, with plenty of autonomy and following the Lean Code concepts, the cost of maintaining this software may drop considerably.


The LiveSource Mini Apps

When I started developing LiveSource I was often adding new functionalities to the source code without worrying about the amount of classes and source files that were being created. In a matter of few months, the code for LiveSource has become highly complex and very expensive to maintain. Not to mention the user interface, that every new feature makes the navigation more confused and harmed.

That's when the idea to separate LiveSource into several mini apps came. The original big application was divided into several Minimum Viable Products, such as a Product Backlog app (called EasyBacklog), separated from another mini app to generate and display a status task board (called Live Task Board), another to deal with the automatic generation of documentation from the source code, and another one for dealing with software metrics.

Figure1: The LiveSource Mini Apps

Notice in the lower left corner of the picture above, links to access the various mini apps provided by the LiveSource's website. Each one has its own "world", they are different products with independent user interfaces and independent source files.

.  .  .

The independence of the Mini Apps of a big application must be total. The user interface, configuration, source code, all autonomous, separated from one another.

The autonomy of the Mini Apps automatically brings tremendous visibility to the specific characteristics of the final product, characteristics that are often overlooked when the application is only viewed as a whole, as a big soup of features.

The Lean Code

Following the wave of Lean ideas, I would like to create a new one here in this blog:
The Lean Code.

In a nutshell, Lean Code is a software project that is short, independent and extremely organized. The Lean Code can be easily maintained and its intention promptly understood by any participant in the software development process, including non-programmers.

The idea is that even a large and complex application can be composed of several independent, small, organized and easy to maintain software projects. Starting with the SOA concepts, the Lean Code goes much further adding the ability of a viable and an easy-to-read source code and the focus on the end user language inside the source code.

Maintenance is one of the highest costs of software development. Two thirds of the lifetime cost of a software involves maintenance. (See Software maintenance). It is much faster (and cheaper) to identify a problem or a feature that needs to be fixed in a Lean Code, considerably reducing the cost of software maintenance.

How many features is your source code implementing at the moment? The answer to this question is a good indication if your software project is Lean or not.

A Lean Code implements a minimal amount of features at a time. If your source has become a spaghetti, that means, it is too long and so complex that you are not able to identify the features it implements, then the case really needs a Lean refactoring.

It is also important that a Lean Code is viable. A Viable and Lean code is the one that has proven itself that has users and customers satisfied. (See the definition of Product-Market Fit).

Good follow-up to this reading would be: The Clean Code (or Uncle Bob's blog) and The Lean Startup from Eric Ries.


The Lean Code in Practice

"To trim the size of a code base and keep it small, we have to eliminate unnecessary code, employ good coding practices, and justify any new code." (The Art of Lean Software Development) 

After much research on code visibility, I realized that to develop a Lean Code you need the following topics below:

• Ubiquitous Language,
• Isolated Minimum Viable Products (or Mini Apps),
• A tool to visualize the intent of your source code.

The advantages of using the ubiquitous language in the source code are numerous. This topic alone is extremely important, and that is why a whole post was previously written for this subject:

Ubiquitous Language inside the Source Code

This post will describe in detail the important aspects of the Ubiquitous Language when developing a Lean Code.

The next item is about the MVPs. If your application has a countless amount of functionality, simply implement them all in one given mass of source code will not help in understanding and maintaining this code. Therefore the following definition:

A Lean Code should contain only one Minimum Viable Product.

When the requirements of your software begin to multiply, turn yourself to the intent of the application. Focus on your MVP. After interviewing your clients and consulting your market, if new features prove themselves as actually useful to the users (see Defining Your Mininum Viable Product), then split these new features in different MVPs and create independent software projects for them, with isolated source code. If necessary, use APIs and communications interfaces between the MVPs, but not simply develop them into a single mass of the same source code.


LiveSource and The Lean Code

Development tools are very important to assist the process of building a software. No wonder a development team always uses a number of them. However, most current development tools used by programmers, called IDEs (eg Eclipse, VisualStudio, IntelliJ, etc.), unfortunately are very technical and aren't ideal to view the intent of the source code or to be used by the non-programmers who are also part of the development team (such as stakeholders, product owners, business specialists, project managers, testers and even customers and end users).

That is why LiveSource was developed: for the intention of the source code can be filtered, viewed and understood, and so that non-programmers can participate and contribute more actively in the software development process. Learn more about the advantages of LiveSource here.

Live Source is a Web Toolkit that ensures the source code will no longer be hidden behind a complex technological lawyer, but instead, will be online translated and understood by the programmers and non-programmers of your development team. If the intent of the business is not clearly reflected in the source code, that is the way LiveSource will collaborate with the development team: openly exposing the problem.

"I see value in keeping my source code comments a bit more organized and easier to see than browsing through code.", comment from a LiveSource early adopter.

When a person (programmer or not) views the source code through the LiveSource tool, it is easily detectable if the source is sufficiently organized or not. You can see if the documentation of this code, if any, is relevant to the business domain or if it is only adding technical details (often useless) for the programmers by themselves.

Having the intentions of the business domain completely linked to the source code is a key feature of the Lean Code. The name of each file, each directory, each class, each package, each function and each variable must directly reflect the intention of its existence to the business domain. A non-programmer who reads the name of a file or a function for example, should easily understand its meaning. And then, the documentation of this code should add the business information that justifies and explains its need.

I'd like to repeat here the importance of reading the post about Ubiquitous Language inside the Source Code.

When all participants of the development process, including product owners, project managers, customers, users, etc. can actively participate in building the most important artifacts of a software, that is its source code, the dynamism of communication and accuracy of the results directly reflects on the quality of the final product generated and dramatically reduces the cost of its maintenance.

After the Definition of your Minimum Viable Product

After defining your Minimum Viable Product (see the previous post of this blog) the next steps are actually develop and validate it.

What features need to be provided for the Early Adopters start using your product?

As an example, here are the User Stories for LiveSource's Minimum Viable Product:


MVP 1:  LiveSource is a web Toolkit that loads the source code of your software and generates an easy to read version of it, understandable for the whole development team including by non-programmers.


Stories: 

• "As a User, I want to view a list of all my projects."
• "As a User, I want to view a list of all the source code files of each one of my projects."
• "As a User, I want to view an easy-to-read version of each source code file."

LiveSource is a very big and complex project, but as you can see, there is only three User Stories in the first MVP  This is exactly how a Lean development is supposed to be: start small, eliminate waste, deliver fast, etc.

Also with the User Stories list, it is important to have a draft of the user interface. Could be something very simple, in a piece of paper, or a picture of a drawing. We call that a Low Fidelity Prototype.

Figure 1: Low Fidelity Prototype for the LiveSource MVP

At this point, I am already developing using some Agile techniques. We can start planning a Sprint here, defining a Product Backlog, estimating, prioritizing, etc.

To be simple, for the first release of the MVP we don't need a login page and we don't even need a database. We will extract all the file contents from a remote repository, like Git or Subversion for example.

For now, lets include the three stories in a first Sprint and lets describe all the necessary tasks to implement these stories.

User Interface tasks:

• List all the projects available in a web page.
• When the user clicks on a project, the system shows all the files stored in the remote repository for this project.
• When the user clicks on a file, the system shows the easy-to-ready version of the source code of this file.

Server side tasks:

• Connect with the remote file repository of a particular project.
• Load a list of the files available at the remote repository of a particular project.
• Load the source content of a particular file of a particular project in the remote repository.
• Extract from the source code all the code documentation available.

I can add some Spikes to this list, for example a task to study some API's to connect with remote file repositories, or another task to study how to extract documentation from a source code. Any of these tasks could take a lot of work hours. But I will not add them to my task list right now because I already explored all these topics before when I was researching the viability of my project and they are working very well on my prototype already.

Next step is distribute the tasks over your development team. Let the programmers choose what they can implement and when they can commit themselves for a delivery.

While you are implementing your MVP, try to make it as independent as possible. When new features start to come, try to not just add them up to your MVP, instead, try to create a new MVP that are as much  independent as possible from each other.

Also, while implementing your MVP you can keep asking your early adopters for feedback, input some real data and do Usability Tests. As soon you start having feedback as better.

At the end of the implementation, you should have your early adopters already using your MVP or ready to start using it.

The main point of this post is: Don't start a new MVP while your early adopters are not already using the MVP's you have developed. There is a lot to adjust as soon as you start receiving your customers feedback, this adjustments are most of time much more important than new features.

The good time to start developing new features is when you already have 40% of your users saying that they will be "Very Disappointed" if they no longer can use your product. We call that a Product/Market Fit.

If you are not reaching your Product/Market Fit, you should start the whole customer development process again. Go back to the prototype stage and listen more to your early adopters. Find out what are the reasons they have to use or not your product, and adjust your MVP until you get Product/Market Fit.

It is really not easy to get to this point. You need to be very determined and normally takes a lot of iterations to be ready to scale. The path described here is a good starting point for you to succeed.

Defining your Minimum Viable Product

A key goal when you decide to start a new software project should be:

   "What you need to do to acquire customers."

All software has customers. Whether it is an internal software for your company, a very complicated API, a very simple mobile app, or anything else. If you have already started developing the software, but you still don't know who your customers are and what their pains are, I suggest start trying to answer these questions as soon as possible. One of the major causes of software development failure is not having anyone that wants to use it.

Another good exercise is to consider yourself as the customer number Zero of your own project. Even if you are not a direct customer, will help a lot if you try to estabilish how the product you are developing can help you back.

As an example, these are the customers of my project LiveSource:
   "Software developers (including programmers, managers, product owners and possibly you)"

There are several solutions I can offer to my customers, but I will not just assume I already know which one they are most interested in. Only after some customer interviews and prototype presentations I understood that "Improving Communication" is the subject that causes my customers' most intense reactions.

You can help LiveSource answering our online survey. Thanks!!
              http://www.surveymonkey.com/s/63GQJYS

Acquiring the first customers is an iterative process. You usually start talking with people and sketching some kind of prototype. Then you come back and survey or interview your prospective customers, then you make adjustmets in your prototype and repeat the whole process again.

In some projects, this process can be quite fast, taking only a few days and you already have a very simple prototype that causes enthusiam in your customers.

In other projects, this process may take much longer, depending on your ability to listen to your customers, how much of their pain you can share and understand, and the capacity you have to simplify complex processes.

In the case of LiveSource, I have to admit that my ability to simplify problems is lacking. I started trying to offer a variety of solutions at the same time and couldn't stop many new ideas that come to my mind every week. Don't let this happen to you ...

While refining your prototype, start searching for your Early Adopters. Try to find as soon as possible someone that charitably would actually use your product. Ideally, this person should also obtain some value back. If you can't get anyone to test your product, think how much harder it will be to achieve real customers. Keep repeting the process of interviewing customers and refine your prototype until you find your early adopters. (This post from Seth's Blog can help)

In most cases, to acquire users you need your product not only to work but also to have personality . Know more at this Minimum Viable Personality post.

The early adopters for LiveSource are some of my developer friends who have already confirmed they will help with my product. But we can't forget: family and friends are a help only in the begining, real customers are those who actually bring revenue to your company.

Before adding a bunch of features to your prototype, you need to define how your customers will use your product in the future, how your production environment is going to be.

For a large software project, define and build the production environment can cost a very big effort. However, postponing this solution is a mistake. Set how your customers are going to access your product and have a Launch Page working on this production environment. With a Launch Page, at least you can test your market, generate a contact list, validate your idea and confirm if people would register to use your product or not.

The production environment for LiveSource took me incredibly few months to be built. After a long time spent with testing and integrating the commercially available clouds, I finally own a good and flexible production environment, able to support a complex project like LiveSource, using both Amazon EC2 and Google App Engine clouds.

The most important is to begin to test your market as soon as possible. Even before, or at least at the same time you are building the prototype or the infrastructure for your product.

You can register yourself  right now for LiveSource at:
                                            http://golivesource.com

I could start adding a lot of features to this link, but to be Lean I need to detect which one has the highest value for my customers. And then simplify this functionality to the most and start getting feedback from my Early Adopters.

Doesn't matter how big and complex your product is, choose the feature that has proven the highest value to your customers and describe in one sentence the main part of this functionality. This is a good start on the definition of your Minimum Viable Product.

As an example, in LiveSource, "Improving Communication" is the subject that has greater value to my customers. So here is the definition of my Minimum Viable Product:

• LiveSource is a web Toolkit that loads the source code of your software and generates an easy to read version of it, understandable for the whole development team including by non-programmers.

I know that LiveSource goes beyond the definition above, but without any doubt, today I understand that focusing only on this very viable functionality and making it work perfectly is what helps me to get real customers as quickly and efficiently as possible.

Summarizing, before you start developing your software:

     - "Unassume" your assumptions (Unassumer.com) 

     - Survey your customers and your market (SurveyMonkey.com)
     - Identify your MVP  (Excellent Video about MVP)

     - Provide a Launch Page (LaunchRock.com)

     - Build your production environment

     - Quickly prototype
     - Measure the results
     - Acquire and Satisfy your Early Adopters 

Adding more functionalities to your MVP without the end users already successfully use the existing features can be a total waste of time and money. In most cases it is indeed what happens.

Not finished yet!!  :-)    Follow the part 2 of this blog:

After the definition of your Minimum Viable Product  

Being Agile is not easy

No wonder that many companies and people say they are Agile, but when asked if they are programming in pairs, if they are test oriented or if they work 40 hours weekly, most times the answer is "not necessarily" or "more or less" or even "no, but we develop in sprints".

Being Agile is not easy.

At least we, the Agilistas, are aware that simply not being Agile is even more difficult.

Even with the adaptable agile methodologies, as Kanban for example, be Agile means a change in behavior, paradigms and to many people, a change of principles and personality (if that is possible). A major difficulty, at least in my personal experience, is having to develop together with someone who claims to be agile because it's fashionable, but not even believes in agile values and uses any argument and excuses to justify why not doing pair programming, not refactoring, not sharing the code, not developing unit tests and, especially, not focusing on delivering something executable at the end of an iteration. Even harder than being agile is explaining to a person who thinks is being agile that he or she is not.
  (I want to quote here this other post that I found interesting: The emotional reaction to Agile adoption)

Even for someone who is actually Agile, it is extremely common skip some agile practices for indiscipline and laziness. I will not deny that it has happened to me countless times. When you are too absorbed and pressed with momentary and isolated problems, it is usual to lose perception of the global consequences of indiscipline. The problem increases considerably when the quality of work is not visible by others in the team or if you are not pair programming and there is nobody to inspect your work besides yourself.

In many cases, a tool that "forces" and "guarantees" the performance of the agile practices can greatly help a development team. I fully understand that human interaction is the most relevant factor to agile adoption, and that nothing can replace it. But I also believe that not all people have the agile values in nature, that even the agile pros can often be undisciplined and that simple reliance on individual effort is not always a success factor. An additional tool to aid human interactions (such as communication, sharing, respect, trust, ...) when an agile development team is being incipient can be a very efficient solution.



 The advantages of the LiveSource Toolkit

Watch our DEMO video: http://www.screencast-o-matic.com/watch/cX6oVdTPZ

LiveSource is a Web tool that ensures the source code will no longer be hidden behind a complex file server access, but it will always be shared by the whole development team at a click away on your web browser. And further, this code will also be understood by non-programmers. At least, if the code is not understandable, the LiveSource Toolkit will let the problem be exposed in a way that programmers will not be able to argue with their technical jargon, so incomprehensible otherwise. It is a new technology for your software, clarifying the darkness of programming into an easy to read, step by step summary of the content.

LiveSource creates a medium that helps both stakeholders and programmers to work together on code in a high-level manner, to better improve the pair programming between programmers and even non-programmers.

Figure 1. A screen shot from the LiveSource Toolkit that displays the source code and an easy to ready filter of this source code.

Excerpted from a Tic Tac Toe game software project.

(Click on image to see enlargement)

The Figure 1 above is a screen shot from the LiveSource Toolkit. Notice that all data on the left frame was extracted from the source code displayed on the right. The left frame is just a filter of domain information relevant to a stakeholder.

Once a development team starts to apply the  Ubiquitous Language within the source code, a new series of applicability for this source begin to emerge. LiveSource focuses on extracting the source code all the benefits generated by the use of ubiquitous language.


LiveSource publishes in a document’s format the true reality of a software project. What is not already implemented in the source code will be shown clearly, without having to go through parallel documentation or reporting tools like emails, bug tracking, task sheets, etc., where this reality can be easily masked by those responsible.

LiveSource also integrates user stories and tasking more tightly with codebase. If programmers insert domain information in the source code and also use ubiquitous language, turning this source code on a User Story or a Requirement is just a matter of extracting, filtering and formatting text from the code. Then, the team can automatically have a series of requirements listed as a scope view of the software.

Observe a Requirements list below extracted from the source code of a Tic Tac Toe sample project:

Figure 2. Scope View through the Requirements List (Click on image to see enlargement)

Figure 3. Source files view. (Click on image to see enlargement)

As the requirements listed above on the left is a direct view (and filtered) from the source code files listed on the right, there's no way a programmer or a project manager, or anyone else in the development team, can manipulate this data to show greater productivity than what really has taken place.

Compare Figure 2 with Figure 3, see how easier it is to read and understand the structure and meaning of the source code after the LiveSource filters.




Unit Testing

LiveSource also shows accurately the presence or absence of unit tests for a given unit of code.

Figure 4. Link between a source file and its unit testing.

(Click on image to see enlargement)

Live Task Board 

Because we are able to extract user stories straight from the source code with the use of ubiquitous language, we could create a tool that calls Live Task Board.

The Live Task Board is a dynamic and realistic view of the current status of the software. It can automatically update itself, because its content is extracted directly from the source code and not from a database of stories that have to be updated in parallel or stories written in paper on the wall that need to be physically moved by the team members daily.

If the developers stratify the software planning activities in simple as possible tasks, very minimal in its size, as minimal as a single development class, the complexity of the user stories becomes more understandable and accurately estimated.

Figure 5. The Live Task Board

(Click on image to see enlargement)

It is fully understandable the wonderful effects of a simply task board on the wall in front of the development team, especially during a Scrum Stand Up Meeting. This means an evolution compared to traditional development models, with their extremely complex and unrealistic timelines. The idea of LiveSource is not to replace the interaction moments between the team, bringing one more tool to be used by developers, but to further enhance communication, leaving the manual task of updating the artifacts to be performed by a computer. It provids much more time for the team to discuss issues related to the tasks themselves.

The team can project the Live Task Board on the wall and continue adding post-its to the projected screen. At the time a programmer is generating the source code for a specific task, the information from the post-its can be used as code documentation and thus the related task automatically returns to the Live Task Board, all electronically and much more permanent.

Viewing the source code in a filtered and clean manner, gives the programmer an immediate idea of what needs to be improved. It causes them extreme discomfort to view their work so clearly when is not done well. It is a situation that only real experience with LiveSource can demonstrate its full extent.

Now imagine the impact of a confusing code being viewed by everyone on the team. No programmer will like to be responsible for this code. And possibly will not be, since the tendency of the programmer will be to prioritize refactoring, reducing the complexity of the source code considerably.

That is why LiveSource can be considered a tool to increase software quality. Because it allows great visibility to what is actually being developed.

The idea is, with LiveSource you can not disguise when you're not being agile. Not even to yourself.

Then, don't forget to send us your comments!

LiveSource - an Agile Toolkit

View more presentations from Alline Watkins

 No Rigths Reserved. Please copy us!

Why some programmers don't like transparency

Ineffective communication is clearly the weak point of several software development projects. The causes can be diverse and the consequences catastrophic. Looking more deeply to these causes, we identified two major ramifications of the problem:
       - the interaction between the product owners and the end users and
       - the interaction between stakeholders and developers.

Communication between the owner who is paying for the development of the software and the users who actually use it has been widely studied by the Lean Development, with practical and extremely effective results for those who are actually willing to minimize the problem (Product-Market Fit, Minimum Viable Product, Lean Code, ...). No magic solution yet found, but it is understood that the work must be in conjunction with the direct participation, unrestricted and as early as possible by the end users in the software development process. Learn more about Lean Development here, or about Lean Startups here.

The other branch of the problem of communication in building software is the gap created between project developers and the stakeholders (project managers, company directors, business experts, ...). Let's bring the conversation from the lofty abstraction that is the usual context for such conversations, down to the brass tacks available to us through closer involvement with actual code.

Experience on both sides of the communication divide (as stakeholders and as developers), has led us to believe that a deeper understanding of the psychology behind such interactions contains a solution. 

Is not hard to see the huge conflict of interest that most development companies just generate within their own environment. When interests are in conflict, information came to mean a source of power, directly affecting the transparency and effectiveness of communications.
How many programmers have not heard from their managers the annoying phrase: "Why do you want to know that?"?
How many stakeholders have already faced totally fuzzy development diagrams, beginning with the "Gang of Four" and ending with no terms that can be understood?

Like it or not, developers are motivated to keep their code hidden from those they are accountable to. Their specialized technical knowledge provides a layer of protection from attack for bad technical decisions and sloppy work.

Even if a programmer is producing excellent code, but also works in an environment strictly hierarchical, unlike an Agile team, this developer is probably at the bottom of the blame chain and will still have the tendency to hide artifacts, because it is the only way to be protected in turbulent situations. A typical defense mechanism used by programmers is to use language and jargon that are deliberately obtuse to the stakeholders.

Stakeholders are typically specialized in a field other than software engineering. Code is black magic to them and they are required to invest blind faith in the technical team to build them a quality product. They can’t speak programmer language, but need deeper insight into the technical cost of what they are requesting. 

We know that transparency is key to most of the eXtreme Programming values (citing courage, communication, feedback and respect). The Live Source Toolkit gives stakeholders or any non-technical person a non-intimidating window into code and a concrete medium for communicating with developers in familiar language. We are advocating that open dialog in front of the reality of the source code brings a confidence that can't be provided anywhere else. It will be the stakeholder's responsibility to supply feedback with respect and the programmer's responsibility to maintain the courage and clarity of communication.

In summary, we are building a tool to go beyond social interaction without replacing it. We are building a medium to enable a conversation with transparency, not only a case tool.

June & Alline

 No Rights Reserved. Please copy us!

User language inside the source code - The Ubiquitous Language

"We understand each other"  (James Shore)

http://jamesshore.com/Agile-Book/ubiquitous_language.html

• Does your source code lack knowledge?
• If one of the developers on your team left work now, would others be able to make sense of it?
• Is it a multiple lined mess, impossible to understand even for the one who wrote it?

Software development is by its nature a series of translations and compromises. What the end user wants, what the customer is willing to pay for, and what is technically feasible rarely combine to form a unified set of features. A deeper understanding between technical and non-technical people is needed, in particular at the communication divide between Stakeholders and Developers.

The LiveSource Toolkit helps you to develop a domain-specific ubiquitous language inside your source code and shows you how to use your codebase as a source for your requirements and documentation, improving communication for the whole team.

"Programmers should speak the language of domain experts to avoid miscommunication, delays, and errors. To avoid mental translation between domain language and code, design your software to use the language of the domain. Reflect in code how users of the softwarethink and speak about their work. One powerful approach is to create a domain model. 

The ubiquitous language is a living language. Domain experts influence design and code and the issues discovered while coding influence domain experts. When you discover discrepancies, it's an opportunity for conversation and joint discovery. Then update your design to reflect the results."   (Ubiquitous Language in 99 words - James Shore)

End Users are Ubiquitous

Not every software project has a dedicated business analyst or a domain expert. But every software must have users. Also, every software should be written for the users.

In general, on a development team the technical language is understood only by developers, the domain language normally understood only by domain experts. But, to achieve success, the end user language should  be understood by everyone. The end user language should be the ubiquitous one.

User Language good in Code?


The whole idea behind an ubiquitous language is that it is pervasive everywhere; in all project related communication, all the way down to the technical level. The idea is to preserve the business intention in the code and have the code mirror the real world as much as possible.

Source code is a little more limited in that you have to avoid keywords on a programming-language-specific basis, but other than that, the advantages are numerous; the programmers don’t have to make the mental translation from the language of code to the language of the domain resulting in less bugs, the domain experts don’t have to read the “Gang of Four” and can more accurately describe their needs, and both programmers and domain experts should be able to understand the end user's language. Driving the design based on the domain in this manner shows how closing the gap between domain and programming language leads to better code.

Most Agilists agree that a shared (ubiquitous) language improves communication between technical and non-technical people. Ensuring a strong tie to the code reinforces the language and ensures it's thorough use.

A User Story BEFORE and AFTER Ubiquitous Language

When the ubiquitous language is already being applied in high-level documents of the project, makes it much easier for developers to identify which technical jargon should be avoided in the source code.
Notice how the two stories below may communicate the same message, even if the domain language is being directly applied to the second one.

(Excerpted from a Tic TacToe Game)

BEFORE    Move      When the user clicks on the grid,      the system shows 0 or X depending on which one is the current user.

AFTER    Player Move When the player clicks on the game grid, the game shows the symbol 0 ou X depending on which one is the current player.

A class BEFORE and AFTER Ubiquitous Language

You will probably notice that it becomes easier to understand the code when you use

domain language while programming. There is much less guessing on the programmer's

intent, eliminating a lot of confusion for the one that is going to maintain it.

(Excerpted from a Tic Tac Toe Game source code)

BEFORE      /**  * Add the string O or X to a cell in the grid. */ public class  ShowCellGrid{ public static void  displayUser (Grid grid, Cell cell) {             if (!Initialization.flag   && Initialization.gameStatus.getSequence() == null   && isEmpty(grid, cell)) {  Initialization.flag = true;  String mk= showString(Initialization.gameStatus        .getCurrentUser().getUserString());  grid.setHTML(cell.getRowIndex(), cell.getCellIndex(), mk);  Initialization.gameStatus.getStatus()[cell.getRowIndex()][cell .getCellIndex()] = Initialization.gameStatus .getCurrentUser(); GameEnd.checkEnd(Initialization.gameStatus, cell.getRowIndex(), cell.getCellIndex());        } (...) }

AFTER    /** * Performs a move in the game. */ public class  PlayerMove { /** * When the player clicks in a cell, the game draws an O or a X on the     *  game grid depending on which player's turn it is. */ public static void   makeMove  (GameGrid gameGrid, Cell cell) {         if (!GameInitialization.waitingMoveFlag && GameInitialization.currentGameStatus.getSequenceWinner()  == null && isCellEmpty(gameGrid, cell)) { GameInitialization.waitingMoveFlag = true; String marker = showPlayerIcon(GameInitialization. currentGameStatus.getCurrentPlayer().getPlayerIcon()); gameGrid.setHTML(cell.getRowIndex(), cell.getCellIndex(), marker); GameInitialization.currentGameStatus.getGameMoves() [cell.getRowIndex()][cell.getCellIndex()] =  GameInitialization.currentGameStatus.getCurrentPlayer(); CheckWinner.checkForWinner(GameInitialization. currentGameStatus,cell.getRowIndex(), cell.getCellIndex());         } (...) }

Now, which one below would a Stakeholder better understand?

The contents of both tables below were extracted from the classes above.
Small changes in this matter has a huge impact on the code's general knowledge.

What we demonstrate here is that, once developers begin to introduce Ubiquitous Language 

within their source code, a lot of possibilities like filtering and searching becomes possible 

and useful to others who do not necessarily understand the technical terms.

(Excerpted from a Tic Tac Toe Game source code)

BEFORE    Show Cell Grid    Add the String O or X to a cell in the grid. Display User        Is Empty

AFTER    Player Move    Performs a move in the game. Make Move        When the player clicks in a cell, the game draws an O or a X on the game grid depending on which player's turn it is. Is Cell Empty        The Player can select a cell only if it wasn't already selected yet.

Using Ubiquitous Language in source code may seem simple, but it's not. In fact it implies a big paradigm shift for programmers who are accustomed to use their technical terms back and forth, as examples "EntityBeans","AssyncronousCalls", "DTO's ", etc...

Replacing these terms (which often not even other programmers can easily understand) and using words that are more self-explanatory in a Stakeholder's perspective, demand time and a lot of refactoring by programmers. It will not be in a day for code to become ubiquitous. A gradual and continuous progress is to be expected.

And speaking of self-explanatory words, the ideal nomenclature to use in a code is one that, when you are explaining the software to someone, it doesn't require saying another word beyond the proper nomenclature itself. For example, a variable should be called "Connection" or "DatabaseConnection"? A function should be called "IsNull" or "IsEmailEmpty"?

 No Rights Reserved. Please copy us!