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!!).