Software Architecture, the US, Outsourcing, and R&D

The U.S. Is Outsourcing Away Its Competitive Edge is an interesting article. I'm not a business person (yet!) so I won't comment on the core message of the article. But this argument resonated on me:

“In many cases, R&D and manufacturing are tightly intertwined. Unless you know how to manufacture a product, you often cannot design it. And, to understand how to manufacture it, you have to have manufacturing competencies and experience. The notion that you can design a product in the serene world of the R&D laboratory without any knowledge of the rough and tumble world of production is ridiculous”

— The U.S. Is Outsourcing Away Its Competitive Edge, Harvard Business Review

I drew the obvious connection with that in our field is called as ”Software Architecture“ which, while reasonable in theory, ends up in practice with a bunch of Architecture astronauts: People who stop thinking on the real problems and solve abstract issues using whatever high-level “design language” they think is the equivalent to what the real architects draw.

For these folks, coding is too boring. And you know, they already did their share of coding and finally got away from that. Which tells me that they never liked coding too much, by the way.

So the solution is to "outsource" coding to the more junior coworkers. Which is were I draw the parallel with the article which talks about the US and their massive outsourcing of technology production while still wanting to keep the edge on R&D. Which sounds like a problem.

If you think that coding is sometimes boring (and I can agree about that!) and you feel tempted to take an software architect role which is being sell as the position in which you will still do the entertaining part of the work (the one in which your brain gets some exercise) while leaving the rest to something else, think about that again. It will probably work at first (since your experience with real coding is still fresh) but it won't work at long term. You can't tell people how to code and what to code if you stopped coding and solving real problems a while ago.

Not to mention than “coding” with diagrams is boooring, improductive and and almost useless anyway.

So I'm on the camp which thinks that the right answer is the technical leader, not the architect. One who will need experience, for sure. But who won't throw away that experience by completely change his role! He will still code and test and make releases and make mistakes (which is when he will continue building experience!)

“Experience is what you get when you don't get what you want”

— Dan Stanford

And this in turn takes me to the agile camp. Not only because I agree with the core principles like people-over-processes. But because I think that the whole parallel with civil engineering made by the traditionalist and waterfall-ish model is dead wrong. Civil engineering need to plan a lot because changing a building on the fly isn't exactly easy. But we not only can change our systems on the fly, but people expect to be able to change them.

We don't need architects who aren't up to get their hands dirty and participate in the coding process. Because, in the software-engineering-as-civil-engineering parallel, the real equivalent of what the civil architects do is the code, not the diagrams.

Which brings us back to something I mentioned before in passing: Coding can be boring, tedious sometimes. In my view, the appropriate solution is to change to a better language that let you write code which is closer to a description of the underlying design. DSLs and that sort of stuff.

And yeah, diagrams can be a useful tool in the thinking process (and even better tools as high-level, introductory views of the systems), but stating that they are the design/specification is admitting defeat.

This is also why I think that agile practices are somewhat dependent on programming languages. They can't be completely separated like a set of practices that you can use regardless of what you are using to build whatever you are building. But I'm digressing to a different topic, and this is enough for today.

My final advice, however, is that if you like to program but find it increasingly boring and the offered “solution” by your current company is to become an architect, counter by offering the real solutions. Or move to a better company, if that doesn't work.