A life comited to learning

Category: Agile

Startup Business Models

Most of the startups start by doing some sort of viability studies to asses if the adventure is worth to take. I wrote extensive material on this, but is in Portuguese. If it happens you can read Portuguese or can translate it, here it is.

From these analyses the startup founders may have some elements to start designing a business model.

One of these elements is the competitor list. They can use competitors to reverse engineering a business model.

About business model transparency, for example, Buffer is the best I known in keeping transparency about their business model. See it here. There is also something interesting about Buffer and other companies that want to maintain a transparency culture, and they are using Bare Metrics to achieve that beacuse they use Stripe as they payments partner. For the Buffer example, click here to see their Bare Metrics Dashboard

Of course, this transparency depends on the company culture and not all startups are willing to do this, or is not a priority or even possible. However, having a business model well defined is important for every stakeholder (product manager, developers, customer experience, growth team, etc). 

Having the business model shared amongst the stakeholders is important to maintain focus and provide guidance how to run the business. It helps also communicate KPIs between teams. Every person must contribute to some part of the business and people like to see how they are adding value to the business. In my experience I worked with teams of developers that had no clue about the business model. This can hinder the startup because not everyone is working according to the same blueprint.

I like the concept of the Business Canvas as introduced by Alexander Osterwalder.

Screen Shot 2016-05-17 at 11.16.00

….so would be great to see the business model canvas to understand all the startup business. Ideally, it would hang out this on a wall, as I like the visual management approach.

Business Model Canvas on the wall

I own that book since 2013, because I was learning about business models. Interesting to see the startup scene here in London using these techniques. Forward Partners, for example, help entrepreneurs understand their business by doing a Business Model Canvas as a first thing. I understand, because is a really simple way to design and visualize a business.

Business Model Generation book

Bottom line, why I would like to see a business model for the startups I work for?

  • They help everyone to understand the business and create KPIs for the activities, revenue stream, etc that will definitely help making better decisions and improve communication.
  • It shows that the founders have gone through the work of defining their business and are committed to it, by sharing the business model.
  • For the development teams, having a clear view on the business model, help them to independently decide what is best for the business.
  • If something changes on the business model (as isn’t written in stone), everyone will be aware about it, thus contributing to better communication

Please, let me know if there is something I could help here.

Continue Reading
Continue Reading
Continue Reading

How to improve productivity when developing JEE based web applications

The title of this post was stolen from Stackoverflow, from this discussion:


I really like and agree with this point:

Being “the enterprise stack”, it is often used to create boring, ugly, “good enough” applications and, in general, enterprises tend not to attract great developers who love programming, and think and care about what they do. The quality of software in the enterprise world is not great.

There are exceptions, of course, but mainly from what I’ve seen from the past 10 years, this is, sadly, true. Why?

Continue Reading

Programmer testing

Recently I’ve researched a little about programmer testing, which resulted in a slide set that I’m now sharing with you. These slides are the basis for a training, which included a lot of exercises, as I like to do.

It includes some information about:

  • Agile testing
  • Test driven development
  • Unit testing with JUnit
  • Test doubles and Mockito
  • Code coverage

If you have any feedback or question, please let me know by leaving a comment or send me an email.

Continue Reading

Fluent interfaces while trying to make sense of Prototype Pattern

Sometimes I don’t have great opportunities to apply some nice concepts, but I have some time to learn them.

While trying to make some sense of the Prototype Pattern, I was doing some experiments and I needed, of course, the tests to prove my experiments.

It was when coding the tests, trying to define the client interface (not user interface :)), that to my mind came this article from Martin Fowler: Fluent Interface.

Well, what it matters are these two points:

  • Making your tests first helps you, a lot, to define not only the behavior, but also importantly, the client API.
  • Using Fluent Interface with a Builder, it’s a great way to send our message to the objects implementing the API.

Example of using a fluent interface:

package eu.jpereira.trainings.designpatterns.creational.prototype;

import static org.junit.Assert.*;

import java.util.List;
import java.util.Properties;

import org.junit.Test;

import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CannotHaveZeroPartsException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CouldNotCloneLastObjectException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.NeedToPackLastVehicleException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.VehicleDoesNotHavePartsException;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Shell;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Tire;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Vehicle;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.VehiclePartEnumeration;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.VehiclePartPropertiesEnumeration;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Window;
 * @author jpereira

public class ClientTest {

	 * Integration Test
	 * @throws CouldNotCloneLastObjectException
	 * @throws CannotHaveZeroPartsException
	 * @throws NeedToPackLastVehicleException
	 * @throws VehicleDoesNotHavePartsException
	public void testCreateBUS() throws CouldNotCloneLastObjectException, CannotHaveZeroPartsException, NeedToPackLastVehicleException, VehicleDoesNotHavePartsException {
		Client client = new Client();
		//create a bus car
		//Create props for tire
		Properties tiresProps = new Properties();

		//Create props for shell
		Properties shellProps = new Properties();

		Properties windowProps = new Properties();

		//client.createVehicle().with(new Tires()).times(4).
		Vehicle vehicle = client.vehicleBuilder().createVehicle().with(new Tire(tiresProps)).times(3).with(new Window(windowProps)).times(8).with(new Shell(shellProps)).times(1).packIt();
		//Get all windows
		List<VehiclePart> parts = vehicle.getParts(VehiclePartEnumeration.WINDOW);
		assertEquals(8, parts.size());

A hypothetical Builder implementation with a fluent interface:

package eu.jpereira.trainings.designpatterns.creational.prototype;

import java.util.ArrayList;
import java.util.List;

import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CouldNotCloneLastObjectException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.CannotHaveZeroPartsException;
import eu.jpereira.trainings.designpatterns.creational.prototype.exception.NeedToPackLastVehicleException;
import eu.jpereira.trainings.designpatterns.creational.prototype.model.Vehicle;

 * @author jpereira
public class SimpleVehicleBuilder implements VehicleBuilder {

	private List<VehiclePart> vehicleParts;
	public SimpleVehicleBuilder() {
		this.vehicleParts = createNewPartsBag();
	public VehicleBuilder createVehicle() throws NeedToPackLastVehicleException{
		//Just check this is allways the first call on the builder
		if (vehicleParts.size()!= 0) {
			throw new NeedToPackLastVehicleException();
		return this;

	public VehicleBuilder with(VehiclePart part) {
		return this;

	public VehicleBuilder times(int times) throws CouldNotCloneLastObjectException, CannotHaveZeroPartsException {
		if (times==0) {
			throw new CannotHaveZeroPartsException();
		//get the last one and clone it xtimes 
		if ( this.vehicleParts.size()>0) {
			VehiclePart lastObject = this.vehicleParts.get(this.vehicleParts.size()-1);
			//add it xtimes
			for (int i=0; i< times-1; i++) {
				//new object
				try {
				} catch (CloneNotSupportedException e) {
					//Could not clone it. Wrap exception
					throw new CouldNotCloneLastObjectException(e);
		return this;

	public Vehicle packIt() {
		Vehicle vehicle = new Vehicle(); 
		//clear this reference for the chicle parts.
		this.vehicleParts = createNewPartsBag();
		return vehicle;
	//Can be overriden by subclasses
	protected List<VehiclePart> createNewPartsBag() {
		return new ArrayList<VehiclePart>();


That’s it

Continue Reading

You do not understand, yet, why do you need tests!

Why do I need tests in my software project? Keep bugs away? Yes! Keep quality high? Maybe. Can you define quality?

I see that people often justify the demand for a high test coverage with their desire to have quality in software projects, however they’re only seeing a part of the quality, the bugs visible to the customer. Quality, that word alone, can be very subjective, meaning different things to different people. Of course, having a bug free software means a high quality software, but if I have a bug free software and cannot add new features or improve existing ones, is this software a high quality software?

Now that we’re all doing “agile development” (right? at least you may think you’re doing, because you have daily meetings, review, sprints, etc), everyone should bear in mind one of the critical purposes of tests.

Big up-front designs do not work anymore, never worked for that matter (you soon loose integrity between the code and the design in the papers). We’re no able to make decisions based on the unknown (though some people may think they can), so we leave every decision to the last possible moment, until we have all, or most, information needed to make a reasonable decision.

One fundamental aspect of agile development is that you evolve your system as you go, you do it in iterations and every iteration is focusing only on what is needed to deliver the features you committed for that iteration. Your system will evolve, iteration after iteration.

With this evolution of your system, you will also evolve your architecture and design. You will not add database support on the first iteration if you don’t need a database, right? It’s waste. Right? So, from iteration to iteration your architecture and design will evolve, based on the features you have to develop and those you have developed. This is what evolutionary architecture and deign looks like, according to Martin Fowler.

But, how do you evolve your design and architecture? One of the key practices to do that is refactoring. Refactoring, again using Fowler’s knowledge, is “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the changes of introducing bugs.”

Refactoring is one of the key practice of any project using any kind of agile development methodology, backed by testing and continuous integration. There is no way you can refactor your code if you do not have a safety net, i.e., if you don’t have something that keep you away from breaking existing functionality. This is a key point of tests, to allow you to evolve your system design and architecture.. Of course these test must be automated, needless to say that.

Continue Reading

Yeahh, I’m building it with enterprise ready technologies… who cares?

If you have an web product idea and want to test it, i.e. put it in front of your users, what it’s the most critical aspect to consider first? I usually get my head into a conflict, because I’m used to work with the so-called “enterprise ready technologies”, namely JEE. My mind if formatted to think about all aspects that a good enterprise product should have. I start giving more attention to a set of quality attributes like performance, usability, reusability, testability, portability, modifiability, etc, etc, and give less attention to one critical aspect, if I want to get a product in front of the users fast: productivity.

So, I start looking to what is out there that is enterprise ready, like EJBs, JSF, Hibernate, JBoss, Tomcat, whatever, and start getting the pieces together…. out there in the world there was some a guy with the same product idea, but considered first the productivity aspect of the equation and started to materialize the idea with, let’s say, Ruby on Rails…. guess who’s the winner?

I’m not against the use of JEE, of course, I just think that in some cases it does not make sense. I also have this false argument in my mind: What if I start building it with PHP and then hit a performance problem with my 1Million users? Well, If I ever had one million users, I’ll be happy to deal with these performance issues 🙂

Continue Reading

Ahh, a responsabilidade…

Na semana passada estive presente numa formação onde se tocaram em temas bastante interessantes. Um dos temas abordados e que me chamou a atenção foi o “Modelo de Responsabilidade“.

O “Modelo de Responsabilidade” tenta descrever como nós, humanos,  geralmente nos comportamos face aos problemas que encontramos diariamente. Acho que este modelo descreve algo que nasce conosco, as atitudes e sentimentos que foram cultivados durante milhões de anos de evolução.

Continue Reading

Porque é que eu gosto das metodologias ágeis para desenvolvimento de Software?

Nesta história a equipa estava a trabalhar no lançamento de um produto para o mercado. O projecto já dura à um ano e é gerido com técnicas “tradicionais”* de desenvolvimento de software. Uma das iniciativas (ou sub-projecto, ou projecto no contexto de um programa) inclui um site,  um blog e um perfil no Facebook, no Twitter e no Youtube, onde se irá anunciar o grande lançamento do produto para o mercado.

Um mês antes do grande lançamento a equipa responsável pela comunicação pergunta ao desenvolvimento: “Quando é que o produto vai estar pronto? Precisamos de uma data para comunicar ao público o grande lançamento”.

A equipa de desenvolvimento respondeu qualquer coisa como: “Já está 85% feito.”

Com uma contas, o gestor de projecto prevê que dentro de um mês o produto estará pronto para o mercado. E foi com esse pressuposto que a equipa de comunicação anunciou a data do lançamento “imprevisível” do grande lançamento no site, no blog, no Facebook, no Twitter e no Youtube.

Mas será que aconteceu o pior?

No dia de lançamento (segundo as expectativas da equipa de comunicação), a equipa de desenvolvimento diz que não é possível lançar o produto hoje.

Infelizmente para a equipa, a data de lançamento calhou a uma Sexta-Feira, quando já todos andavam atacados com o stress pre-release. Depois do problema escalado, a direcção da empresa pede gentilmente que se esforcem ao máximo durante o fim de semana para lançar o produto na próxima Segunda-Feira. Até lhes ofereceu recompensas financeiras.

O produto é lançado na Segunda-Feira, mas apesar do incentivo financeiro,  a equipa perdeu muita motivação com este acontecimento. O overtime e sensação de “falha” é sempre um desmotivador e não há dinheiro que “mexa” nessa psicologia.

Agora, porque é que eu gosto das metodologias ágeis para desenvolvimento de software? Não vou aqui falar de tudo, é claro, mas apenas de um ponto que acho importante no contexto desta história tão comum.

Disciplina nas entregas (e tudo que o processo traz de borla)

  • A trabalhar com iterações que produzem Software “utilizável”  e com um conjunto de funcionalidades conhecidas, a equipa ganharia disciplina nas datas de entrega (Com uma gestão apropriada da equipa).
  • Se as iterações tivessem duração de 3 semanas e a equipa confiasse que necessitava de uma iteração para atingir um conjunto de funcionalidades, que somadas às produzidas nas iterações anteriores igualavam as funcionalidades mínimas para lançar o produto, então a equipa de comunicação poderia estar confiante ao anunciar a data do grande lançamento

Será este ponto importante para repensar algumas metodologias de desenvolvimento de Software? Ou assumimos a postura da  negação: “Ahh, podia ser pior se tivéssemos marcado um evento com a comunicação social e grandes investidores.”?  🙂

* Refiro-me aqui às técnicas que apenas são reconhecidas como boas práticas dentro da empresa um por um grupo restrito de empresas. 🙂

Continue Reading