Organize by Architecture

Most companies start out making one product. Then they add another, and another, and soon chaos ensues as the team is overwhelmed. They start splitting people into more teams, each with managers, each handling one or more products, and each reporting to another manager. Hey, it's only natural and it sort of makes sense.

A tree structure evolves, one that we have all seen countless times before throughout our careers (Often hailed as the amazing result of the latest re-organization):





Now the question is... Is this the best we can do as an organization?

Really?

What if instead your organization was organized by Software Architecture? What if each team was responsible for just a part of big picture, their part, their module? You may say that they already are, but I want you to ask yourself if each team performs these tasks:

1. Analyze and design their own code?
2. Manage incoming requirements, specifically for their code?
   
3. Test their own code before releasing to other teams?
4. Manage their own bugs?
5. Know which other team they are receiving software from?
6. Make their own release plans?
7. Make their own releases, planned out with release notes and features?

Do you know when team X will deliver their next version of their code, who they will deliver to, which features are included (a feature being a feature for that code), how it was tested, and which bugs there are?

Most likely, you may have team responsible for parts of the code, but requirements comes through a central process, testing is done by a separate team on entire products, releases are done 'as needed', or through a central repository, and updates to any part of the code are done, well, whenever some little part maybe complete.

The result? Organized chaos. Each team will release each little bug-fix, each little feature, in random intervals, and as testing for the next product commences, a truckload of big nasty bugs pops up.

Yes, even with Agile, this can happen.

Organize by Architecture

There is a better way. I know, I tried it when I worked at Nokia Mobile Phones (I was the Chief Software Architect for the CDMA Business unit in San Diego).

Organize your organization the same as your software architecture. Treat each team as a separate unit, and let them plan their releases, architect their solutions, test their code, and deliver to other modules. Doing so is part of the Software Product Line paradigm, and it will give organizations with many products and large code bases a way to improve their delivery quality and times. If done correctly (And Nokia did not always do everything correctly).

In my next posts, I'll touch on how this works, and what such an organization may look like. I'll also write about some of the pitfalls I've seen, and my own suggestions on how to avoid them.

Social Management

First there was the Plan. Created by the Manager, it will pass all reviews. It will be shown to management, who in the face of such beauty and wisdom will nod its approval. It will be shared with the team, who like lambs for slaughter will march to its beat. Hailed as the solution to all ailments, it will sit on the wall, overseeing the work being done, and slowly, surely, fade into oblivion and obscurity.

For a plan without a life is not a plan at all. It is a static schedule.

To run a successful project, we must acknowledge that change is coming. While we may not want it or ask for it, change is the way of the world, and dealing with it is inevitable if you are to succeed. All projects will experience changes, and they better be prepared for it. Risk identified, contingency plans in place, and even then the unknown unknowns will hit you occasionally like a brick wall.

If you can create a successful project, you have also created a dynamic project management model. Your project will be delivered on time, and if not on the originally scheduled time, then on a time that is known at a prior milestone. More than that, your customers are aware of this, and understands what happened.

But what about your team?

With a dynamic project, you need a way to keep your team informed of changes. And if you're really serious about project management, you want your team to not only know about the changes, but to suggest some of their own. You need Project Collaboration. Because your team are the most important part of your project, and their combined knowledge and skills are greater than that of a single manager.

You need to apply the power of social networking to your projects. Social networking in the terms of project management, or as I call it: Social Management. A radical change from the old style of a manager controlling his team, Social Management instead lets the team run the team. Logistically, a project manager should be in place to be the point-of-contact, but his role can be minimized to creating the project plan outline. After that, Social Management takes over, as the team starts adding tasks, changing tasks, adding dependencies and optimizing.

Will it work? I don't know. For now, it's a thought that as far as I know has not been tried to the full extent. We're moving in this direction with Project Collaboration, SCRUM and other methodologies. Open Source Projects are run partly in this way (and seems to thrive). Will it work in a corporate setting, and will it work better than traditional Project Management? I don't know, but perhaps someday someone will try. Let me know. I'm curious.

Dangerous Coding Errors

Today I read of the 25 most dangerous coding errors revealed. Really, if you are a half-way decent coder these shouldn't come as much of a surprise to you, yet some of these are marvelously generic.

CWE-682: Incorrect Calculation

This is so generic that it's hard to say it's dangerous. It depends quite a lot on WHAT is being calculated.

CWE-330:Use of Insufficiently Random Values

Again, depends on the use of those random values. Although obviously, some cryptographic use is implied.

All in all, this list seems fairly complete, but now what? Anyone who have made these mistakes in the first place, probably won't know, and probably won't go fix them because of the list. This is why you, and every organization, needs software architects. Any decent software architect knows about these issues, have probably seen them before, and know how to find them and fix them.

Software Product Lines

Several years ago, I gave a presentation at the SPLC2 conference in San Diego on Software product Lines (SPL). The conference was hosted by the Software Engineering Institute at Carnegie Mellon, who have championed the ideas of Software Product Lines for some years now, and are making great progress maturing their formal descriptions.

While I worked at Nokia, I experienced first hand how software product lines may work in highly complex environments (Nokia was inducted in the SEI Product Line Hall of Fame in 2000 during SPLC1).

Software Product Lines enables companies like Nokia to develop very large software deliverables, based on a 'factory' line model of development. For Nokia, different teams deliver different part of the software, which are then combined and built into final deliverables by product programs. Each software line, develops a well defined part of the product. If compared to a car, you could say that one line develop the wheels, while another develop the engine.

The product programs pick the 'wheels' and 'engine', and put together most of the car with components delivered from a number of software lines. They then apply the 'paint' to the car, in terms of product specific configurations such as number of keys on the phone, specific ringtones, background, colors, number of phonebook entries, etc.

A mobile phone has many thousands variability points, but by using software lines, these can be kept under control, and released in well-defined 'bundles' at regular intervals.

I've co-authored a research article that examines the Nokia Software Product Lines in more detail.

One of the drawbacks of Software Product Lines however is the speed with which software can be developed. Because components of lines are delivered to many products, each deliverable can easily end up being defined years ahead of delivery. This means that organizations can become very rigid in their product deliverables, and unable to quickly add new features.

Where an organization with just product lines quickly can add features to a product, an organization with software product lines becomes limited by the concentration of knowledge to each line, and the inability of product programs to develop complicated features that span multiple lines. Furthermore, duplicate work is often done because each software line manager (or guardian), often will refuse to take back changes made outside his line.

It doesn't have to be this way. If a system is put in place where software product lines can become more flexible, a process for 'adding' new external features back to existing product lines can be put in place. With a strict review process in place, this can enable external software developers (external to the product line) a way to add software back which can be utilized by the entire organization.

Great, affordable web design.

Our new website at KaDonk was designed by the great team at Groupo Digital in Argentina. Since it was very affordable, and they were timely and great to work with, I just wanted to give them a plug.

Contact Angie and say hi.

Our slideshows and quotes are created by ourselves using JQuery (Awesome JavaScript library!!).

Being a Software Architect

Wikipedia's description of a Software Architect is pretty good, but in my opinion a great software architect also performs these duties:

• Mentor software developers to see the broader picture.
• Acts as a go-to person for technical decisions.
• Documents the architecture and sub-architecture of modules, so individual teams and developers get a clear understanding of how their software has to be organized.
• Reviews processes and code modules.
• Define the structure of API's and interfaces.
• Performs front-end requirement management duties. This is especially true for architects working with Software Product Lines.
• Often reviews 3rd party code and other companies in case or partnering or acquisitions.

What is your definition of a Software Architect? Let me know in the comments.

10 Tips for Project Collaboration

1. Why collaborate at all?

You spent days, weeks, months or even years finding the best candidates for your team. They are bright, smart and want to succeed. Using their combined experience will provide a serious boost to your own management abilities. It is said that two brains are better than one, but we believe five, ten or twenty brains are even better. If you engage your team, they will feel empowered to do their job better. Project collaboration will engage and empower your team.

2. Collaborating is not the same as sharing

So you've decided to start collaborating with your team. Great. But now what? First of all, remember that collaboration is not the same as simply sharing. If all you do is go to a meeting to present your project plan, you won't see much feedback outside of that meeting. To truly collaborate and engage your team, it must be a continuous and perpetual process.

3. Be open to suggestions

Whenever we share something, a presentation or a project plan, we are vulnerable to critique. That is human nature. Before you can collaborate, you must try and set your personal feelings aside and concentrate on the greater good: A project delivered on time. The nature of collaboration is that everyone works together toward a common goal. The very essence of collaboration is to work together to eliminate errors, catch mistakes and to reach the best possible outcome. So don't be afraid to show your work and embrace the feedback you get. It will help you improve for the next project.

4. How to collaborate?

We usually can't just somehow "collaborate" and expect a great outcome. In terms of project management, it makes sense to have the manager be the ultimate authority. After all, the outcome of any project will affect your company's bottom line, and the manager has upper management to whom to report In reality, most people will find their own time to "collaborate,", for example browse a project plan, make a suggestion, etc. Often, we have ideas while eating or watching TV. It is important that you work with your team so that everyone can make suggestions at any time using the latest available information.

Use LiveProject to ensure team members have access to up-to-date data on which to base their input. There is nothing worse than making suggestions only to find they are obsolete because you were not informed of the latest developments.

5. Collaboration has to be done in a sincere spirit. Tell people what to expect.

"A fool with a tool is still a fool," a former manager once told me. Rolling out a new collaboration tool on your team and expecting them to start collaborating probably won't work. You need to let them know what your expectations are and how you will handle feedback. Be open and inclusive, and let them know that their opinions and input really matter. Ask them to help you create the best plan possible, and ensure them that all their suggestions will be taken into consideration. Reinforce this message frequently. When you start receiving changes to your plan, discuss each of them individually. Not all team members feel comfortable discussing their suggestions with everyone present.

6. Reject suggestions with an explanation.

When you reject someone's suggestion, make sure to explain exactly why. It may be discouraging to some to have a suggestion rejected. By continuously encouraging more suggestions and clearly explaining the rejected ones, you ensure that your team stays involved in the process.

7. Give Credit when due

From time to time, someone on your team will make a suggestion to a project plan that is essential. It could be a missed test case, a new identified risk or simply a large missing task. Make sure to give them credit for their input so they feel appreciated and influential. Only by positively reinforcing the process will your team grow to be a collaborating juggernaut.

8. Let time work its magic

There are times when a few team members don't appear to be contributing much. This can be attributed to many factors, such as:

• They were not properly recognized at their previous jobs, and therefore were discouraged.
• They may not feel comfortable making suggestions for fear of looking dumb even though they are not.
• They don't like to make suggestions that others can see.

To begin with, start praising the employees that make good suggestion, and keep encouraging the others. One way to include shy team members is to talk to them one-on-one. Ask their opinion. Often you will get their feedback that way. Then encourage them to use the tool to make their suggestions, and follow-up with praise. Soon they will be making suggestions all the time, as they get comfortable with the process.

9. Take all suggestions seriously

Never make jokes about a suggestion, no matter how small or unsuitable. Take all suggestions seriously and give a serious answer as to why it won't work. Chances are that the person who made the suggestion is inexperienced or really thought it was great. By explaining in detail what is wrong, you help your team grow without discouraging future feedback.

10. Collaboration is a continuous process

As you move toward full collaboration, your team dynamics may change. Some team members will take a more active role, as they learn how to make good suggestions. Consider making them mentors of other team members or delegating sub projects to them to handle. The key to success is to continuously embrace new ideas and change your process to better allow your team to grow.

Read more on how LiveProject can help you collaborate, and start collaborating today!.

7 Tips for exceeding at work as a Software Developer

Tips to Exceed at Work

If there was something I never learned in college, it was how to succeed in the workplace. I may have learned many technical skills, but I never took a class in how to make an impact in business or how to exceed expectations. These are skills that are learned the hard way; in the trenches. This article will give 7 ways for new employees to succeed at their new jobs.

1. First job, now what?

Fresh out of school you get hired to your first job. Congratulations, now what? First, you got hired because you are smart and because your manager thinks you will be an asset to the company. It's up to you to prove him or her right. The most important thing you learned in school is how to learn. The key to succeeding in business is to be able to learn new things quickly. Any job you will have over the next 50 years will require some kind of training. As you grow more experienced, the nature of this training will change, but you will always have to learn something. The faster you can learn the skills for your new position, the faster you can focus on becoming a productive team member. So spend some time during the first month to study the company's processes, product portfolio, standards, and get familiar with them. The time spent will easily repay itself later when you Excel at your job knowledge.

2. Training

Rarely is a new hire ready to work on Day 1. Almost all jobs today require some level of training. Coming from school, you are probably a bit fed up with learning and eager to start work. Remember, each company and each position will require new skills, and training is the fastest way to get there. In my own experience, there are several ways to get job training:

• Mandatory training
• Optional training
• Voluntary training
• Mentoring

The mandatory training can be tedious -- proper workplace behavior and ISO-9002 processes come to mind -- but get through it.

Optional training usually involves classes your employer has available, but for which you have to sign up. Carefully evaluate which ones you need and suggest to your manager how these may help your work. Take the initiative and investigate each class. Don't take them just to say you have. Take them if they can truly help you get better.

Voluntary training is training you do on your own. Buy a book on C++ or Web site development. Often your company will pay for these if you ask, but you must be prepared to pay for it yourself. In my experience, reading a book is a lot more efficient than taking an expensive training class. Classes have to go as slow as the slowest participant, and that can be tedious and repetitive. Read a book on your own time, and take notes.

Mentoring can be a great help, but we are not all so lucky as to have good mentors. So find one. Pick a person in the company you respect, someone who is knowledgeable and has some time. Then ask him or her if they would mind helping you out with some questions. Don't waste their time. Take them to lunch and discuss how they solved their worst problems. A mentor can quickly put you on the right track looking for information, and can be great for building your network.

3. Networking

The power of networking cannot be underestimated. Make friends in your company, in management, engineering, sales, marketing, finance, shipping, IT, etc.

Talk to people, but try not to waste their time. Get to know them during lunch breaks and meetings. The more people you know, the more contacts you have. Every contact you have is a potential solution for your next problem. And if they aren't the solution you are looking for, they might know someone who is. Most meetings start with a few minutes of idle chat until everyone has arrived. Spend it to get to know your colleagues better.

4. Never leave anyone waiting

One of my top priorities when I worked in a corporate environment was the rule: "Try your best not have anyone waiting for you." Whenever you wait for someone, you may get annoyed. The same applies to others. By making sure all your actions are done on time, all your e-mails are answered and you arrive at meetings on time, you are making sure that no one can ever claim you as the bottleneck. Not only does this look good when you have to face your manager, but others will think of you as a great co-worker.

Don’t be afraid to go beyond the call of duty when helping others. If someone asks you where a document is, don't just tell the person he or she can find the answer in process ABC-5, send a link. If you have to review a document, do it as soon as possible, not at the last second. You have to do it anyway, so why not be the first to reply?

5. Dealing with challenging colleagues

Sooner or later you will come across a colleague who is challenging.

Here is what you can do:

• Try minimizing your exposure to the person, but don't let it impact work. Work comes first.
• If the person is actively incompetent, document it. If your manager ever asks you, you will need documentation for your complaints.
• Sometimes, the best approach is to be honest. Tell the person that you are having some issues with his or her behavior and you would like to work it out. Talk privately, over lunch perhaps, and see if there is something that can be worked out.

There is no one-size-fits-all solution to this type of problem, so play it by ear and be discreet. You may have to simply get used to it.

6. Exceeding expectations

Your manager expects you to do your job and that should always be your top priority: Get it done on time. At the end of the day there are deadlines to meet.

The way to exceed expectations is by doing high-quality work and going beyond the call-of-duty. Perhaps this is best illustrated with a few examples:

• The job you performed is very repetitive and requires training to learn. To succeed, document the process and explain each step. Not only will this document be handy for the next person, but you can easily find a replacement and move on to something more fun or challenging. To succeed even more, find a way to automate the job in the future. Now your manager has to find something else for you to do, and if you are prepared you could make some suggestions.
• The job you are doing is slow because of the processes you have to follow. To succeed, analyze the process and make a list of suggestions on how to improve it. Make sure you understand the purpose of the process and discuss your changes with the process owner. Processes should always be dynamic and most companies encourage improvements. When you meet with your manager, point out how your suggestions helped save time. Note: Always follow company processes; they are there for a reason.
• You are writing a document. To succeed, find and use company templates if they exist. If not, try and make your document so useful, it could function as a template for similar work. Suggest changes to existing templates when they don't work. And remember, a template is exactly that: a template. Don't use sections that are not required, but be prepared to defend your choices. To succeed even more, actively push for a review if needed or find other similar documents and learn from them. Ask your mentor for input.
• You are reviewing someone else's document. To succeed, suggest changes, but remember it is not your document. It's OK if your suggestions are rejected. Suggest a list of abbreviations if it doesn't exist and populate it. Compare it to other similar documents to see if anything is missing. To succeed even more, try to catch the things that are NOT included. Think about the document and try to find information that is missing, rather than focusing on the information already there.

7. Do's and don'ts

• Don't send E-mails to the entire company, unless there is a valid reason to do so.
• Don't “reply to all” in e-mails unless there is a genuine need for everyone to know your response. If you are providing any feedback that could be construed as negative to the sender, it is usually better to reply to the sender only.
• Do praise others for good work. Be sure to thank people when they help you. If you find a great document, send a thank-you note to the creator letting him or her know it helped you. This is also a good way to build your network.
• Don't take credit for other people's work. Your manager will not like it when he or she finds out and your colleague will be discouraged. By giving credit where it is due, your perceived integrity will improve.
• Don't ignore problems that are not yours. Help others solve them or bring them up at meetings. Be sure to offer at least one solution to solve them. It may not be the right one, but it shows your spirit of being involved positively.

Do take all this advice, but know that each situation is unique, and there may be better ways to get noticed in a company. I hope this can be a starting point.

Hello World Revisited

So, you have to write a new software application. It's called Hello World. When it runs, it prints out "hello world". What do you do?

As previously discussed in my article "How to move beyond requirements", it is essential as a Software Architect that you constantly follow my mantra of "Think crazy, act sanely". However, what can you practically do to keep your software nimble?

As any software developer first starting out, you probably have written one or more "hello world" programs in your time. I use it as a glorified example of a simple initial requirement that later grows. Imagine that the customer wants other texts to be written, maybe wants the text to be dynamic, and possible wants it printed on a printer instead of a screen.

Here are your options for making "hello world" future proof:

1. Put the text "hello world" in a global definition. If it ever changes, you only need to change it one place.
2. Have your program read "hello world" from the command line. Now anyone can change the text without even recompiling.
3. When reading from the command line, write the text to a file, so next time the program runs it can check the previous text and print it again if no new text is offered.
   
4. Add an input parameter that default to "screen" so the user can specify where to print the text to, like "printer".
   
5. Add another input parameter that could specify the color to print.
6. Prompt the user to enter all these questions on the very first run, then store them to a file, and use them for subsequent runs
7. Prompt the user only if a special command line parameter is added.
8. etc. ad nauseum.

It quickly becomes obvious that you can add a LOT of things to just this simple little program in anticipation of future changes. Some of you might be asking why? Why add all this when the user haven't asked for it?

The purpose of adding these features is that it is faster to do from the beginning. You can architect the changes into the program from the start. It may take 5% longer for development to think about them, and 10% longer to implement and test. But re-writing the program 6 times as new requirements trickle in will take 100% longer. At least !

As a Software Architect, you must weigh the immediate cost of spending some up-front quality time thinking, versus spending a lot more time later re-architecting.

Now, let's consider a real-life example.

In 1996, I was tasked with writing the "Menu Server" for Nokia's Series 40 phones. This server was to handle anything in the menu system for all S40 products. At the time, the S40 User Interface (UI) was text-based with only lists of menus. You are probably thinking this sounds fairly easy, so let me give you a little list of considerations that I had to take into account, a list of features the Menu Server had to support at the time I was writing it.

• Support for hundreds of languages, including Arabic and Chinese.
• Support for sub-menus
• Menu-indicator showing the location in the menu to the user (like 3-1-4)
• Help, after 15 seconds help is shown.
• 4-5 different layout of the menu, like single items, items with a sub-text (like phone book), etc.
• Menu can be activated from various places, to it must support 'jumping' to a menu item
• Sometimes, pressing 'back' goes two levels back instead of one.
  
• Support for variable keys. Each S40 phone can have different ways of navigating the menu.
• Scrollbar
• Header showing highlighted menu
• Wrap-around scrolling on some menu's, but not on others
• Some menu items has extra functionality, in which case a text would be shown on a special function key
• Etc.

As my first task developing the Menu Server, I decided to write a requirements documents with all of these. There were literally hundred of little things it had to do. The document helped me focus, and group the requirements into logical groupings.

After this was done, I did a brainstorm. I literally came up with more requirements, thinking about how phones might develop in the future. For example, I considered:

• Different fonts and colors
• Graphics would come (at the time only text phones was available for S40).
  
• Different Screen sizes would bring new layouts
• Timeouts would change
• Help texts would change
• Navigation options would change
• We may get touch-screens eventually

Based on these very broad concepts of the market and technology, I came up with a list of features that I needed to build into the Menu Server, although none of these were initially required:

• Support for Icons
• Support for dynamic layouts
• 4-way scrolling
• Dynamic event handling (would handle eventually touch-screens)
• Support for colors
• Configurable timeouts
• etc.

I had a bunch more, but they were so far out I had to let them go.

As you can imagine, developing the Menu Server suddenly became a very different effort than originally envisioned. I had to make everything dynamic. For the Nokia OS, this meant that the entire menu system became configurable. Every menu, and all of its behaviour became configurable, which meant that the extra functionality really was a matter of configuration, rather than coding.

When I was done, the menu supported almost all of these extra features. I couldn't test them all the way, because I didn't have the hardware to, but 3 years later, when Nokia introduced 4-way scrolling in the main menu, using icons, I got an e-mail from the center in UK. They had flipped the switch, and turned it on, and it worked. I probably spent a month extra thinking of all this, and writing the extra code. But three years later, another person had taken over, and he would have had to re-architect the entire Menu Server has I not done it.

With very little 'relatively speaking' effort on my part, I was able to save time in long run. Lots of time, for by now most of these features are in use.

Was there any drawbacks? Yes. The Menu configuration became rather big an complicated. Partly as a consequence of the Nokia S40 UI Architecture, which did not allow for anything more fancy than tables. Was it worth it? Definitely.

So remember... Think Crazy, Act Sanely.

A little more effort up front, will save you a lot of effort later.

How to move beyond requirements.

Software developers create code based on requirements, which usually are a subset of features. This is great for getting work done, but if we look at it in a broader sense, it can also be very limiting.

Consider this example:

A client has hired your company to write a new application for them. The application is really snazzy, and by simply running it, it will print "Hello World" for all to see. As a developer, it is your responsibility to code this application. What do you do?

I know, silly example, but you can replace the actual requirement for any that makes sense to you. Most developers at this point, would sit down and crank out an application that when run would write "Hello World" in perhaps a window or a command-prompt. For arguments sake, say it would take them half an hour.

As the developer is almost done, the client returns, now asking for a change. The application should write "Goodbye world" (The financial crisis hit them hard). Again, for arguments sake, the developer spends 15 minutes changing the application to write "Goodbye World".

Quickly upon delivery, the client returns again. He wants it shown in red. Again, the developer spends 15 minutes updating the application. After 10 minutes another change... The application should be able to print anything. Another 30 minutes of work.

After much back and forth, the developer and your company has spent 2 hours, and the client is finally happy.

Now, consider this: How long would it have taken to write the final application, had you know all these requirements up front? While this varies from product to product, it is safe to say it would have been a LOT faster had we known all the final requirements from the start. Maybe half the time.

It's time to put on our Software Architecture hat:

1. We didn't know all the requirements up front you may say?
   Yes, but we also never asked. As a software architect, it is your responsibility to ask, ask, ask until as much as you can is learned and uncovered. Understand you must, why the requirements are what they are.
2. Ah, but even if we asked, the client may not have known what they wanted you say?
   True, and often this is the case. However, that is not a reason not to think. That's right, I said think. With a minimum of effort, you can probably predict the next 75% of features a customer will ask for. Color the text, make it variable, etc.
3. No way, how can I possibly know what my client want next?
   Because you are smart. You know the system, you know the technical subject area, you know the market. Guess. Brainstorm. Talk to your colleagues. Get together and think !

I call this "Think Crazy, act sanely".

When you have to implement a requirement, think about what is next. How can you make it flexible, extensible, modular and configurable. How can you prepare the code to get additions later? How can you enable the software to be easily expandable?

Well, stay tuned, more on this in later postings...

Happy new year, and remember to think !

Architecting with Requirements - A story from my past.

I love Software Architecture.

The essence of Software Architecture is to distill the requirements to the system. Often a developer think that a requirement is absolute: "Our software must do this. To the letter." However, when you dig a little deeper, most requirements are quite flexible. Remember that a requirement comes from a customer, and very often ends up being written by the customer based on his interpretation of your system.

Vivo, a Brazilian operator, had a set of requirements for Nokia that specified how the UI of their mobile phone should look and behave when in idle. For Nokia, these requirements were very hard to implement as written, years or man-hours work. The requirements were sent to Nokia in form of a large document. The document was interpreted by a Customer Representative that 'understood' Vivo's requirements. He entered them into a database where various teams could comment and respond to them. Eventually, they reached a Project Manager that decided to implement them, after which point they went to a Software Lead, who made sure his team got them and coded them.

By the time a developer got these requirements, it was too late. Un-winding the history was impossible, and frequently Nokia spent insane amounts of time not only managing this, but trying to figure out what Vivo really meant in the first place.

As one of my tasks while working as the Chief Software Architect for Nokia (CDMA products), I was sent to Vivo to discuss these requirements. The development teams were stuck, the work was overwhelming, the product would be delayed.

I met with Vivo's lead UI/Marketing person, Raquel, who was responsible for writing the original requirements. As we started discussing, I began asking questions along the lines of "So why do you want this? What is your purpose of asking for that?" Each time Raquel would answer honestly, describing what Vivo was hopnig to ultimately achieve with the feature (Drive revenue, make it easier for users to find and buy content, etc). When we came to the requirements that were hard for us to do, I suggested alternative ways of doing them. Often just a little tweak, but enough that Nokia could easily implement it, instead of making major changes. And Raquel accepted. She was thrilled that we could do it all of a sudden. The phone could be done on time.

In this scenario, what were the essential issues?

1. The requirements were written with pre-conceived knowledge of our UI
2. The requirements lost their original context when processed through Nokia's DB
3. The core reason for each requirement was 'lost in translation'.

My point is... As a Software Architect, sometimes your main purpose is to understand WHY requirements are what they are. Use that to suggest alternative solutions that still fullfill the need, and always... always ask for purpose!

Surveys

Finally we're getting some help in the S&M Department (No, it's Sales and Marketing). A very experienced friend of a friend, Bob, has agreed to help us start understanding our customers, and tap into their view of LiveProject.

This has also prompted me to due some major e-mail list shuffles, which I must admit is tough when you have had 85,000+ people sign up. E-mails just don't fit so well in Excel anymore.

So after much ado about nothing, I finally had to give in and write a bit of a 'tool' for MailChimp. Their new API guy, Jesse, has been helping me with their .NET Beta library, which has saved me oodles of time.

Now, we are surveying all our customers, and learning a heck of a lot. Should any one of you read this (highly unlikely given my 3 hits per day on this blog or so), then THANKS !

Getting to Page 1 on Google

"Content is King" they say. So, in the spirit of content, I decided to add our entire help-page system (Which is already made up of *.htm pages) to our website.

We would increase our relevant content quite significantly, and allow customer to browser our help pages online. A win-win proposition.

In reality though, this proved to be more work than what I initially estimated. Our help pages are built using the HTML Help Workshop, and my first task was to clean each individual page of all header and body tags. Each page would simply have to start with a h1 tag.

• This format still works in the HELP file, which is great !
  
• This allows us to embed the help files directly into ASPX pages with a simple wrapper and include statement:

Now, any change to a help file can be updated on our web page by just adding the file directly to our web directory.

Now, the problem was that IIS was configured to open *.htm as web pages. So, a quick reconfigure later, and the include works (and we have no other htm pages anyway).

My last problem is that each *.htm file includes links to other *.htm files. But each htm file is embedded in an ASPX page, so the links don't work.

Using a URL rewriter, I simply setup a rule to re-direct any requests for *.htm files to the corresponding *.aspx page. Nice!! I love URL re-writing!!

Google even managed to index the pages, which is great, BUT google fails miserably when reading the title tag. For some reason each title becomes an "unknown page", most likely due to the redirect.

While finding the ultimate destination correctly, google seems to 'use' the 'missing page' it get's from the URL redirect header (Or something to that effect), so now I have to find and resolve that issue.

Getting to Page 1 on Google

After many month of optimizing our website (Best damn project collaboration tool around), I have finally gotten a good solid idea of how to optimize for google. Let me say, it's surprisingly easy, and bound to get harder. As sites starts competing, the keyword-shuffle can begin.

So, Lesson 1 in my own story of getting to page 1 on google (and altavista, live, ask.com, etc)

1. Use the same keyword on the title, header 1, bold in body text, and lightly strewn around the pages. Don't overdo it (Like I have on some pages). If you can, make sure the keyword is part of your domain name. If that's impossible, then make it part of your page name (Like Great Cookies):

BEST: www.greatcookies.com/Fantastic.html
GOOD: www.bambionice.com/GreatCookies.html

Remember to use image ALT and TITLE tags, they are great for keywords, as are the TITLE tag of your links.

URL Rewriting and Google Website Optimizer

I've begun discovering the power of URL rewriting. As our KaDonk website is growing furiously, URL rewriting is the only good method of fixing old pages that have been removed.

This becomes particularly true after having run several Google Website Optimizer tests. The Google website optimizer are great, but when using A/B pages, let's say on registration.aspx, you inevitably end up with registration1.aspx, registration2.aspx, etc... These pages are just temporary for using while the experiments are running.

Once the experiment ends though, users may have links to these pages, and search engines may have indexed them.

So I installed a freeware URL rewriter, and now all I have to do is redirect the temporary pages to the main one after each experiment. Simple, and clean.

Another benefit I recently discovered was when we added our entire library of help files to our website. These are the same pages that are included in our F1 Help inside LiveProject. Internally, they all reference eacher using *.htm links. But our pages are in ASP.NET, so references would basicallyshow the raw files instead of my encapsulator .aspx files.

URL rewriting to the rescue. Each reference to a .htm file is automatically redirected to an .aspx file of the correct name. Literally with one line of configuration all the links in our embedded help files works.

It looks something like this:



May I add this is insanely cool !!

Redirecting domain.com to www.domain.com through global.asax

OK this was a tricky one to solve, redirecting kadonk.com to www.kadonk.com using ASP.NET in C#. The solution came from lots of browsing, and many sources, and looks like this in global.asax (replace 'domain' with your own domain of course):

void Application_BeginRequest(object sender, EventArgs e)
{

// Don't do nothing while in test mode !
if (!Request.Url.Host.Equals("localhost")
&& !Request.Url.Host.ToString().Contains("www.domain.com")
&& Request.Url.Host.ToString().Contains("domain.com"))
{
string Result = string.Concat(
"http://",
Request.Url.Authority.Replace("domain.com", "www.domain.com"),
HttpContext.Current.Response.ApplyAppPathModifier(Request.Path),
Request.Url.Query);

HttpContext.Current.Response.Redirect(Result, true);
}
}

This will redirect kadonk.com to www.kadonk.com, but not any other domains we have, and it won't touch localhost (which may be funky). It will preserve Session variables and query strings, and should generally be nice and safe. You will note that I hardcoded "http://". I will fix that later to retain the protocol, but in any case I am using Matt Sollars GREAT WebpageSecurity package for SSL redirects!

Customer Forum by Invision Power Services, IP.Board

After much reading, searching and questioning, I finally settled on a user Forum from Invision Power Services called IP.Board. It's quite flexible, and Invision Power offers fairly cheap hosting for the size of board we're looking at.

It supports, amongst a lot of other features, Sub domains (forum.kadonk.com), although the setup required a few tickets to Invision. However their support seems impeccable, and I received answers and fixes between 1 minute and 2 hours at the most. It feels good to have such responsive service, so we're excited to be launching our new forum with them.

Check it out: http://forum.kadonk.com

Great source of PM Information

A while back I discovered PMFORUM. They have a bunch of Project Management articles, look in the 'library' section. They also do a pretty good job of collecting news and events from the PM World. I wrote an article for them about Agile Project Management, which can be found here:
December issue of PM World Today
Article by Anders Heie in PM Forum

Great site for Marketing !

A friend of mine recently pointed me to marketingsherpa, and having just embarked upon the perilous journey of marketing kadonk, I must say I am impressed.

marketingsherpa often have recent articles available for free for 7 days, and their blog contains an astonishing amount of tips and tricks.

Currently, we're in the process up fine-tuning our Google Adwords campaigns, and I've discovered it's quite a science... When I'm done I shall post what I've learned here.

The Fake reviews at microsoftprojectviewer.com

It is no secret that I am the President of KaDonk, Inc. As such, I am looking for other competitors, reviews, and blogs that are concerned with Project Management.

Today I came across an interesting one, microsoftprojectviewer.com. At first glance, this very basic webpage seems like a great place to compare project viewers, and get a recommendation on which one is best... However, after reading a little more, it seems to be rather doubtful this is anything else than a great promotion for Steelray. Let's analyze it a little deeper.

1. Obviously, Steelray is the highest ranked viewer.

This is fine if course, if the website is truly impartial. However it is also the only review with positive mention of... well, anything. All other reviews mention "doubtful legal territory", "unnecessarily complex, " or "doesn't feel finished." One of the other reviews even mention Steelray positively. Hardly fair. Read them and see yourself.

2. The reviews have many facts wrong, for instance, Seavus IS in fact a Microsoft partner (as far as I can see on the Microsoft partner sites). The UI comments are clearly off (I've tried several of these viewers myself, and they're pretty good). In fact, Seavus is a CLEAR winner over Steelray any day, which is clear for anyone who tries the two.

3. The fake form for contacting the non-existing editor of this seemingly objective 3rd party evaluation site always fails with a note about an empty "comment" field. It is almost as if no comments are wanted.

And of course the nail in the coffin:
4. The Domain microsoftprojectviewer.com is registered to Brian Leach at GoDaddy.com. Interestingly enough, Steelray.com is also registered to Brian Leach. Coincidence?

Now, don't get me wrong. I don't mind that you blow your own horn, or try to sell your own product. But presenting what looks like a 'fair' review, which is obviously nothing that a scam, that I don't like.

I've tried a number of free viewers, and compared them to ours (LiveProject). I urge you to make your own comparisons !

Brian, come on, take that scam down, it's embarrasing.