The problem here is that the [Software Management Formulas] incorporate a number of flawed assumptions. The first of these assumptions is that programmers are fungible. The SMFs assume all programmers will contribute roughly the same amount to a project and that all programmers are interchangeable.

I think the root of problem is that upper management types don’t understand what goes into software development. They assume that programming is a rote task, like assembling cars on an assembly line or typists transcribing memos. I used to work for a guy who could not understand why we couldn’t just go faster.

The problem is that software development isn’t a rote task, it is a creative task. Writing software is nothing like putting the wheels on a car, but it is hard for people who aren’t in the trenches to see that.

(Via James Robertson.)

He follows up this month with an article titled “Rewriting Software, Part 2” wherein he makes the following observation:

If you are a writer, or have ever taken a writing class, you’ve probably come across John R. Trimble’s assertion that ‘all writing is rewriting.’ Isn’t it funny that software is something developers write yet fear rewriting?”

I am not a professional writer, but I do have some interests in the area. I think the kind of “rewriting” that Trimble is referring to is more like editing and tweaking than throwing the whole manuscript out and starting over from scratch. From what I understand of writing you start out with a draft that sucks and gradually massage it into something that you can call finished.

This type of rewriting is closer to the agile approach of creating the simplest thing that could possibly work and then building on that foundation. What happened with Firefox and CDBaby are “big bang” rewrites where the developers abandoned a working codebase and started over from scratch. In the case of Firefox it worked out OK in the end, but things were touch and go for a while. It didn’t work out at all for CDBaby.²

Adam follows the previous quote with this:

There’s a deep seated prejudice in this industry against taking a working piece of software and tinkering with it, except when it involves fixing a bug or adding a feature. It doesn’t matter if we’re talking about some small-scale refactoring, rewriting an entire project from scratch, or something in between.

I think it is a mistake to lump refactoring, minor rewrites and big bang rewrites into one category. Refactoring and agile methods for evolving a codebase are gaining acceptance while successful big bang rewrites are the exception and not the rule. What this shows is that if you feel that you need to rewrite a piece of software you are more likely to be successful if you do the rewrite in smaller iterations. Also, if you feel the need to make architectural changes or to switch to a different technology you will be better off if you do one at a time.

Here’s the thing, I haven’t succeeded in building one of these great companies. My business partner and I are still working on the formula that works for us but we figure we are in the same position that a lot of people are in: we have some great software ideas and want to bring them to market. To that end I found a rather lengthy article at inc.com which dissected the failure of Friendster - once a competitor to MySpace.

There were many lessons/reminders for those of us that have the objectives described above and I thought I would share what I took away. I wonder if anyone might have any comments on some of these ideas or battle scars to share from the perspective of building a software business in today’s environment.

1 - Make sure your software can keep up with the demands of the users

This can mean a lot of things. In Friendster’s case this meant that the software was not written to scale with load or features. I find this particularly interesting because in my experience there is a tendency for some to insist on perfection before release - not only in design but in feature set. On the other extreme is the tendency to just make it work at any cost. The first will guarantee that you never go live because the software will never be perfect. The “make it work” extreme, as proven by Friendster, makes it much more difficult to react once in the reactionary stage of production. Now, the article points out internal conflicts and the company’s failure to address the software problems once identified. Which brings me to the next point.

2 - Think hard about using Venture Capital

For some it’s the allure of having lots of money to throw at a problem. For others, it may just seem like the only way they can stop what they are currently doing, pay the bills, and focus on their business full-time. Whatever the case may be, bringing on VC funding too early proved catastrophic for Friendster as it has for so many others before them.

To use their numbers, 2 hits out of 20 tries are successful. Jonathan Abrams, the founder of Friendster, feels as though most people get VC funding too early. The organization often hasn’t really been established and the product hasn’t matured enough. Assuming the best case, smart and savvy VC execs are brought in to manage the effort and guide the company to extreme profitability. In Friendster’s case, as for many others, an eye on profits from people with little concern for the product rendered the company unable to address the problems associated with number 1 above.

3 - Continue to keep an eye on your Market

While invention can be the mother of necessity, if you originally set out to solve a problem it is a good idea to stay in contact with the market at all times. Monitoring that the problem(s) exist or that the right solution hasn’t changed, is really the only way to continue to provide the level of satisfaction that allowed you to connect to your market in the first place. According to the article, conflicting ideas inside Friendster and a misguided focus led to a distancing from their users as their patterns and interests shifted out from underneath them and right into the laps of MySpace.

This clearly isn’t the only way to do things or an inclusive list of everything one should do. However, you can really plug these 3 ideas into the respective buckets of Business Development, Product Development, and Marketing. I suppose that if you don’t get those right you probably do have problems.

Forward-thinking entrepreneurs are making strides in promising areas—from nanotech to biotech to semiconductors. Will any of them build the next Microsoft?

My first thought was “who would want to be the next Microsoft?” The article holds up Microsoft as a gold standard for successful companies and Bill Gates as the quintessential entrepreneur. Certainly Microsoft is a successful company and Mr. Gates has earned a significant amount of money from his business venture. However, I don’t think Microsoft is the right role model for today’s entrepreneurs. Microsoft got where it is today by building a monopoly and aggressively defending it. There are many areas where Microsoft’s behavior was detrimental to the industry as a whole.

I am not going to rehash Microsoft’s behavior over the last decade or so, but I am going to point out that Microsoft is poised for an inevitable decline. Having dominated the markets for PC desktop operating systems, web browsers and office productivity software the company reached the pinnacle of its influence. The markets that Microsoft has historically dominated are completely saturated and all of its money cannot buy success in other markets. I think there are better role models.

One would seem to be Apple. The company was an early innovator and then fell on hard times. With analysts regularly sounding the company’s death knell they have seen an incredibly resurgence since the return of Steve Jobs. Now Apple is doing well in its traditional markets and is making bold moves into other markets with its iPod and the recently announced iPhone. Apple will never dominate the PC desktop market like Microsoft has, but that is OK. In fact, it is good. The company has identified a profitable niche and exploited it to good effect.

Google is another company that seems to fit the bill as an entrepreneurial role model much better than Microsoft. Before Google’s AdSense program analysts were decrying the end of web advertising. But, I think that there are even better role models available. For example, companies like 37 Signals and OmniGroup are never going to dominate the industry for anything, but they are very successful by almost any measure. They are proof that it is possible to create software that users love and have fun in the process. You don’t have to be a billion dollar company with 90% market share to be successful.

A dissatisfied Basecamper wrote to us that “Real project management requires the determination of the critical path.” I thought that sounded zen…but I had no idea what it meant. Ryan said it reminded him of a bit from Tufte’s latest book: “it’s about how sentences like the above numb you to responsibility…”project management” doesn’t require things…people require things…so who requires it?…and the “critical path” to where? etc…or “a decision was reached between parties.” — who made the decision? who’s responsible? etc.”

Hang around any business with more than about 10 people and you hear responsibility-numbing senetences like this all the time. One of my favorites is “Safety is everyone’s responsibility”. Really? More often than not, the effect of a statement like this is to absolve individuals of any real culpability. The responsibility is spread so thin that no one individual feels bound by it.

This is a difficult problem for the interviewer. If he goes back and tells his boss that “this guy isn’t going to work out but I don’t know why” his opinion is likely to be ignored. It is no less a problem for the candidate who would like to believe that if he answers all of the questions right he will get the job. Nevertheless, it is very difficult to get objective evidence of a person’s technical abilities during a reasonable interview process.

And this really goes to the heart of the problem. The decision making process is almost entirely intuitive and yet we persist in believing that we can obtain an objective answer if we come at the problem from a different angle. Steve thinks that there is a better interview process out there that we haven’t found yet. I don’t think that is the case. I think that we found it but don’t like the implications.

I think the best interview process is to let your best hacker chat with a candidate for 30 minutes to an hour. It doesn’t really matter what they talk about, just that they spend the time interacting. At the end of the interview if the hacker is excited about the candidate hire them without delay. If the hacker seems neutral then put the candidate’s resume in the “maybe” pile. However, if the hacker shows any reservations then the candidate is probably not a good fit. You will probably have a few bad results, but will come out ahead in the long run.

I think that the argument about UI inconsistency is really a red herring. The real problem isn’t that a user interface may be inconsistent with Windows, it is that the interface is difficult to use. When applications are easy to use nobody complains about the interface being inconsistent. There are a few basic rules that all applications are expected to follow, but beyond that users just want something that does not require a lot of time to figure out. Sometimes consistency is part of overall usability; however, just being consistent with Windows (or Mac OS) does not guarantee that an application will be easy to use. Emerson once remarked that “a foolish consistency is the hobgoblin of little minds.” Development teams are better served spending their time making the interface clear and easy to use than making it consistent with Windows.

The UML Can’t Solve Problems

It is not uncommon to see companies who are looking for Java developers to ask for UML experience. In many cases this is appropriate as the UML is well suited for describing OO designs. Most developers these days should be able to at least read UML class diagrams. The problem is that some companies confuse the solution (OO design) with the method (UML).

Consider the following requirement from a job ad for a Java architect: “Proficient in the application of UML to real world problems.” You cannot really apply the UML to real world problems since the UML is not a solution but a tool for describing solutions. What the ad should have asked for is proficiency in using the UML to describe real world problems and their solutions.

The confusion between the result and the method of achieving the result is also apparent with software development methodologies. Many organizations take on the task of “implementing the RUP” without stopping to think about what benefits this will bring for them. Their business goal becomes “implement process” when it should be “reduce cost” or “reduce time to market.” In the case of the UML, organizations are saying they want UML when what they really want is the ability to design OO solutions and to be able to communicate those solutions to the rest of the team.

The UML Can’t Make Good Designers

Knowing UML does not make someone a good OO designer. To use an analogy, the idea that knowing the UML makes one a good designer is a bit like suggesting that knowing the English language makes one a good playwright. While a strong knowledge of the English language is required if you are going to write plays in English, there is also a creative component and other talents that are necessary. Of course, one need not even know English if they are going to write plays in another language, but the other skills are still necessary. The same can be said of OO application design. While knowledge of the UML can be beneficial, and may even be required depending on the circumstances, it is not even close to being enough.

Yet it seems that many organizations are relying on UML knowledge to cover gaps in overall design experience. There is a hope that the use of the UML will compensate for a lack of design skills. While learning the UML “vocabulary” for expressing system design may help an architect to improve their overall design skills, those skills must already exist.

The UML Can’t Write Your Code For You

Code generation tools notwithstanding, you cannot build an application with pictures. Code generation may be helpful as a time saver, depending on the circumstances, but the core logic still needs to be written by a developer. What makes the UML so useful is that it is a very high level notation, meaning that it can easily represent very abstract concepts. That same feature makes it very difficult to generate more than class skeletons from UML diagrams. While the UML is useful for design and documentation, it still requires actual code to implement the design.

Conclusion

The UML is a very useful and powerful tool. Like any other tool different people judge its usefulness differently, but most can agree that there is a place in every architect’s toolbox for the UML. However, the UML can be misused, and the results are not likely to be pleasing. Therefor, it is in everyone’s best interest, from developers to managers, to understand what the UML can and cannot do for them.

It is often equally challenging to solidify the design of a user interface and get buy-in from all stakeholders. There is usually someone who is responsible for seeing that business objectives are met. Then there is someone responsible for deciding technical feasibility and another that is responsible for scheduling and budgeting. And of course there should be someone representing the users. If software is being developed for internal use, then a representative from the users’ area or department will fill that role. If the software is being developed for outside customers a representative from marketing or sales is often appointed to act on the users’ behalf.

In either case this often presents problems that give most developers nausea. Unfortunately, anyone responsible for the design of an interface must deal with this directly because this person is likely the most important person with which to have a good rapport. These user representatives tend to get heavily involved with the user interface design. If you do not make friends with this person you will dread every meeting with this person - and there are plenty of meetings in this process. User reps can be a great source of information and input on design considerations. Depending on a designer’s level of understanding of the business domain, a user rep will often know of previous failed design attempts and of successful scenarios. Listen to them and learn from them. We should never assume we know more than these valuable resources.

An understanding of good user interface design eludes most people. And most couldn’t tell a good design if it hit them. The one true test, however, of quality is in the users’ feedback. It is important that we designers use this to our advantage. Using the iterative design and testing techniques that we talk about later will allow us to quickly prevent bad designs being realized late in the development and also help provide fuel for your design goals even when strong opinions would like to maintain otherwise. A word of caution that we all want to remember is that it will happen more than once when user feedback proves the user rep correct and the designer wrong. It is ok to be wrong but I hear crow is rather distasteful.