What to Consider when Starting a Software Project Why Projects are not as Successful as they can be? Choosing the right software development consultants Should you hire Computer Science Majors as Programmers? Choosing the Right Database The Pitfalls of Forward Planning Choosing the Right Programming Language Report Driven Design Problem Solving My Problem is Your Problem: Problem Solving in Application Architecture

Copyright Paragon Corporation ( October 06, 2006)

Choosing your problems Many people take the false premise that problems are things that are dumped on your lap and that you have no choice about them. This perhaps is one of the most dangerous premises taken because it reduces your options by narrowing your vision. For example if you have a piece of software that has a part that doesn't work, You really have a couple of problems to choose from How do I fix this software?

How do I replace this with something that works?

How do I live with this defect?



Destroy your Blind Zones In addition to not recognizing that you can choose your problems, people often have blind zones that cloud their vision of problem options and solutions. Before you can even make an earnest effort of selecting from a choice of problems and solutions, you need to first eradicate some of these blind zones.



Below are a couple of blind zones that come to mind Sunk thinking: I spent a million dollars on this or spent a lot of time on this. I have to salvage my investment.

Mob mentality: Everyone else I know uses this and everyone must be right. No one ever got fired for recommending Oracle.

Marketing hypnosis: The sales said it was better than the last that I just got to have it and it would solve all my problems.

Aligning with the wrong group: Their client list is long and impressive. If it works for IBM, its got to work for me.

Too much money: We should get the best that money can buy and the most expensive is always the best. When all projects have the same problem, resources can be plentiful When all projects have a common problem, resources from all projects can be pooled to solve the common problem. A problem does not get harder the more people that need the problem solved, but it does get harder and more difficult the more people trying to solve it in a vacuum or with competing agendas. Align your problem domains One way to ensure that all your projects have the same problems is to align your problem domains. There are many ways to do that of course and here we list just a few. Many companies choose to go the single product route and sell that to many customers or use it for all their projects. When someone discovers a bug in the software, then 8 times out of 10, it is a problem that all the users will have. Fixing the bug fixes it for all users.

Ensure all your building blocks are the same: Use the same language for all your applications, same OS, the same widgets, and the same database but assemble them differently to achieve different goals.

Standards: There are many standards that exist in the software industry for this very purpose. For example we have Ansi-SQL to make all relational databases look similar so that an application can support various brands of databases relatively easily and DBA knowledge is more transferrable. We've got web services - WSDL to make discovering and generation of stub-classes simple. We've got W3C standards for HTML and webforms so that regardless of what language you choose to develop your web application as long as you produce compliant html, most browsers will consume it happily. Standards Compliance By far, I think the most powerful of the above is standards compliance, but it is unfortunately the most difficult to get going and to succeed. Why is it so much more powerful than the other 2. For a couple of reasons. You can more easily swap out building blocks or software that does the same thing. Your database vendor pisses you off one day - get another. You need a database that works on your palmtop, get one.

You have greater control as to how you dice out your problem domains, because you have a wider option of blocks to choose from.

If there is one piece of software that works better for one group than another in the company, that's okay because it interoperates with the rest of your infrastructure. People hate it when the boss says "Eat this oatmeal and live with it" and are much happier with "Choose from these various flavors of cereal" Standards are great but hard to execute for a couple of reasons Everyone wants to do it their way; You get a group of members of different companies or different departments in a room, and they will want to control the standard by making the standard what they are doing because they have invested a lot of time in what they are doing.

Commercial software vendors have a love-hate relationship with standards. They want it to fail because it levels the playing ground. They want it to succeed because it levels the playing ground. Leveling the playing ground in one way is beneficial for commercial software vendors because it means complimentary software can better work with them. For a company that controls the particular market, it is often bad - because all the complimentary software is already cow-towing to them. They don't need the food-chain leveled. They do want some standards to succeed because it opens the gateway up for not yet born technologies that can more easily play with them. Of course they want other complimentary standards to succeed, not the ones that directly affect their market, but the ones that affect their main competitors market; unless they can control the standard.

People are resistant to change and can't imagine doing things differently. Again this is a problem with all the above. This is a problem not just for standards.

There is a tendency to try to solve too much with a standard which makes a standard impossible to implement. You have to decide on a subset of a domain of problems the standard will solve and decide what is not worth solving for this round. This requires a high level of communication and coordination.

Often times people whip out grandiose standards without a proof of concept and that is just hard to digest. A standard is most successful when it is born from a reference implementation.

People fear that if you have standards, then everything is the same. Creativity is stifled. Standards are a lot easier to achieve than they were say ten years ago. The increased visibility with internet, email, blogging, and electronic media makes everyone's playing cards face up and information travels quickly like bees carrying pollen. Communication and coordination has reached an unprecedented level. It is quickly turning from a game of who has the most money to broadcast their message to a game of whose message is compelling enough to be carried by others. Where is the Creativity in Standards Compliance? Standards compliance reduces competition on the interface level, but allows battling on the fringes. To understand what that means - take two people. For all intensive purposes, they walk and run the same, but one walks and runs faster. The one that runs slower can fit in a small car and consumes less food, while the one that runs faster requires a larger car to stretch out his legs and 10 steaks a day. Standards may tell you what interfaces you must support, but there is often where it stops. Anything not defined in the standard is free-game. In fact anything that is free-game, if it is compelling enough eventually finds itself in future standards. Standards try to take care of the 70-80 percent need and leave out the 20-30 percent. With that said, if there are two ways of doing the same thing, of fairly equal or good enough speed, and one way is standards compliant, and one is not - do it the standards compliant way, because it will be much easier to swap out technology with another more appropriate technology. Align your Agendas: Competing agendas and the WIN-WIN Proposition A problem that all of the above share is that of agreement and competing agendas. All the above require a mandate or for the group to decide on the best possible course for all. This is very difficult when what is good for one is not perceived as good for another. It is important to align your agendas in such a manner that all parties feel like they are getting something and losing little. Everyone is trying to maximize their piece of the pie with little regard of how their behavior reduces the overall size of the pie. This is the "Prisoner's Dilemma". So how can the greater good win out over the suboptimal win of the individual participant? One way that comes to mind is to state the game differently to each participant such that the sum of the sociological behaviors of the one would be the optimal for all. To demonstrate - we'll take a slight twist to the standard Prisoner's Dilemma game. In this particular version you have 3 participants 2 Bank Robbers: Prisoner A and Prisoner B

A good friend of both bank robbers - Friend C The stakes are the usual If A betrays and B stays silent then A goes free and B serves 10 years

If B betrays and A stays silent then B goes free and A serves 10 years

If both stay silent then they both serve 6 months

If both betray then both serve 2 years Now Friend C likes both robbers and is trusted by both. He wants to achieve the overall optimal solution. His challenge is to get both to be silent even though both will have to serve jail sentences. So to do this he tells both of his friends a little story: "I've been snooping on the cops and they don't know if either of you are guilty, but they do know that you two were together at the time of the crime and that the robbery was performed by two people. If you implicate the other you will be implicating yourself." The pie looks different from where you are standing "I've been snooping on the cops and they don't know if either of you are guilty, but they do know that you two were together at the time of the crime and that the robbery was performed by two people. If you implicate the other you will be implicating yourself." One of the problems with the Prisoner's Dilemma solutions is that they often assume that the spoils of war look the same to everyone, when in fact that is often far from the truth. To demonstrate, let's assume we have the same stakes as stated above, but with a slight twist. Friend C is trusted by both and likes both. He knows that A would die if he were to spend 6 months in jail and B would not be great, but he has got lots of friends in the big cell that can sneak him treats and what-not. Assessing the situation, he concludes that the optimal solution is for A to betray and B to stay silent. A is a nice guy and would normally stay silent. B is an all for myself kind of guy and will most likely betray. C's challenge is to get A to betray and B to stay silent. He does the following: To A he says - "You know B is going to betray you and say you did it all. It will be his word against yours."

To B he says - "I've been snooping on the cops and they don't know if either of you are guilty, but they do know that you two were together at the time of the crime and that the robbery was performed by two people. If you implicate A you will be implicating yourself." The point to get across here is that the actual payoff matrix of a game is different for everyone and that a solution that doesn't take this into consideration is suboptimal. You can witness this in general social behavior. Some people value money most, some people fame, some people knowledge, some people recognition in a specific area, and some just want to eat ice cream in a corner somewhere and be left alone. Successful Project Management Regardless of what options you choose above, there are a couple of key factors that lead to successful implementation. A great Leader One of the most important factors of a successful project is a leader who leads with an invisible hand. As in our last 2 examples, the prisoners had no idea that they were being manipulated because they trusted their friend. The most important factor of a successful project is a good leader and one that leads with an invisible hand. Below are a couple of factors that make a good leader: Be able to win trust

Be able to see a starting point and filter out the noise

Must have the interest of all involved

Not afraid to make sacrifices

Be able to weigh the options based on the social dynamics of the group, the technological state of the world, and decide the optimal strategy for each group that will achieve the optimal strategy for all

Be able to think in multiple planes and visualize the thread that ties them all together

State the problem for each group so that the group finds the problem interesting and that the group's optimal strategy is the optimal for all. Note: a leader, while often a single person and usually starting as a single person, need not be. It can be a group who can see where their problems intersect and visualize how cooperating can float the whole boat. Also as stated, a leader need only see the starting point, not the ending point. The reality of it is that for most interesting projects, there is never an end, so stop looking for it. Competition and Cooperation Competition is the need that in any given game that there is a side that wins more than the other, whether that be measured in money, fame, or trophies. The key is more. No one needs to lose they just can't all win the same. Competition makes otherwise boring problems interesting. Competition is a driving force for problem solving in both a good and a bad way. Without the thought that we are competing, we would be less driven to achieve. Having different groups trying different approaches to a problem often produces the best set of solutions for various environments, therefore competition should not be discouraged. Take the example of the Human Genome project. Competition drove people to work faster to beat the other team and the Human Genome project as a result completed before its scheduled completion. People have battles that they are more passionate about than others and spoils that they cherish more than others. This makes them tackle the same problem with different eyes. In a nutshell, people visualize the pie differently and find certain games more interesting. Competition can also be dangerous because it often causes labor to be divided in a win-lose proposition. In order to mitigate the destructive side of competition while taking advantage of the productive side, the spoils of war must be fashioned such that individuals win that piece which is most precious to them and lose that which they care less about. Competition is between sides and sides are amorphous structures broken down by time, ideology, race, socio-economic strata, space, etc. In one game you can be competing with one person and in the next that person is in your team. Often times you are competing against yourself to see if you can do better than you did in the past. The sides we choose are all dependent on how we visualize our payout structure and sometimes we don't know which side will give us a better payout structure. All complex games are the non-linear sum of simpler sub games. I say non-linear because the outcomes of some of these games effect the outcomes of other sub games. For example if you kill off a competitor in one game and that competitor could be beneficial in another more important game, you have reduced your chances of winning the overall game. Your best strategy may be to lose this round to increase your chances of the next. In that super-game whose side are you on? The sides are fluid.

Further Reading The Cathedral and the Bazaar A position paper by Eric Raymond that tries to dissect what made Linux so successful by comparing its style of architecture which he calls Bazaar with the more commonly used model for building large systems called Cathedral. In it he proposes a lot of interesting theories about what makes people work on opensource projects and what made Linus Tovalds an effective leader. Team Compensation A partly fictional piece, by Mary Poppendieck, that describes all the problems with performance based employee evaluation systems and other approaches for dealing out rewards. Microsoft Business Solutions Convergence 2006: Innovation through Business Applications Talk with Bill Gates where he describes his vision of the world and how the impact of software and technology will impact business, health and education. The Human Genome Project & the Private Sector: A Working Partnership Article that demonstrates how competition between the private sector (lead by Craig Venter) and public sector (NIH) helped the Human Genome Project realize its goals. Wikipedia: Prisoner's Dilemma Summary of what prisoner's dilemma is and work that has been done in that area. Wikipedia: Competition Summary of what competition is and its presence in industry, biology, and economics. Hardboiled Economics An interesting commentary on hard-boiled economics. Sense of justice discovered in the brain Details how a part of the dorsolateral prefrontal cortex has been implicated in the human behavior of judgement and fairness and how this overrides self-interest. Sizing up Oracle's open source tactics Commentary on how Oracle is tackling the opensource growing initiative. Update: Microsoft, JBoss link up Microsoft and JBoss, competing on one front and cooperating on another. Hidden Talents: Are You a Connector? Interesting blog post on the traits that make a good people connector. One who can socially match peoples problems with solution providers.

Del.icio.us | Reddit | Digg | BlinkList | Furl Spurl | Simpy