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 !