Simple is hard. You can see it everywhere.
I worked with many programmers and most of them were able to produce working code. But only the code of the superstars was easily readable and looked simple although it did complicated things.
If someone works in a sort of complicated field (who doesn’t these days), it is very easy for them to confuse you within the first ten seconds of his explanation of their job. Although it is quite hard to understand these complicated things, it is much more difficult to explain them simply.
Flempo is mostly about people assigning tasks to each other. The idea seemed simple: You distribute people in teams and let the teams assign tasks to each other. The two teams represent a provider-customer relationship. Great. Now it turned out to be very confusing when implemented. If you want to assign tasks within one team, you need to set it as its customer or provider. When someone from a provider’s team wants to assign a task to someone for the customer’s team, it is not possible until you create the relationship in the other direction. (And you have to communicate this need to the users somehow). When setting up the relationship in the first place, you need to think which party is which. And so on. Although this was a very powerful and flexible concept, in practice it was too complicated to follow.
OK so the second step was making the relationship bidirectional. Instead of customers and providers, you just had partner teams. Partner teams could assign tasks to each other. Better. The need to create a team a partner of itself was still here, however. Now I didn’t mention that you can actually configure the attributes a task can have when created for certain team-team relationship. This is very powerful: you might require a deadline from someone, while only an affected component from someone else. However, when creating a task, this creates the need to explicitely state as a member of which team you are creating this task. Because if you create a task for the team C, it might have different attributes depending on whether you’re a member of A or B. This made the new task form confusing. Also, if you send a message to the team’s e-mail address, it creates a task for that team. Very neat. But which would be the team you created this task on behalf of? Unless forced to put something cryptic in the subject, no one knew.
Final step (at least for now): each task belongs to only one team. There is no two parties relationship, tasks can be assigned only by people within one team. This is enough for a project-oriented teams, but not so great for customer-provider relationships (people from both parties need to be in the same team “Providing services for C”), but reduces the complexity so much, that it was worthy of the change. I’ll need to come up with something that will support this kind of relationship better. But it needs to be.. yeah simple. And simple is what.. yeah hard.
