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 !