Dylan posted a good blog post at a ridiculous time of night last night discussing software architecture, his role in it and more. Firstly, it’s really good to see these kinds of blog posts appearing – Ephox has gotten really slack at blogging and I think that’s a shame because we have a lot of good stuff to say. Actually publishing things makes you actually think it through and it allows people to build on those ideas and improve them. It’s always hard to find the time and energy to blog, but it’s worth it.

I also think there were some really good points in Dylan’s post.  Firstly and perhaps most importantly:

Now, I’m not a software architect by title – that title implies a position of authority or seniority. But, the work practices I employ; the way I approach my work; the aspects of my job I focus on; the things I concern myself with; are those of a software architect. I’m starting to think that it’s not about authority or seniority – its simply a specialisation – like UI design, or software process, or deep-technical knowledge, or management. Ephox doesn’t have and hopefully never will have people with the title “Software Architect”. We work as a team to develop high quality software and one of the key aspects of high quality software is that it’s well architected. If it’s not, you can’t maintain that quality and you can develop improvements anywhere near as fast. It’s important for all the engineers to care about how our products develop, from UI design, to software architecture to quality control, we as a team need to step up and make that happen.

That said, it’s important to remember that the whole business is a team too and we need to be doing what’s best for the business, not just what’s best for the software architecture. That means making trade offs, you can’t keep striving for the perfect architecture because you need to ship sometime and no matter how long you work you’ll never get the perfect architecture. However, it’s a trade off and that implies balance, if you ignore architecture you pay a price and ultimately it’s bad for the business overall. Engineering is essentially the study of trade offs so this shouldn’t come as a surprise.

Smashing code seems to be another subject of debate on the role of the architect. Does the architect continue to cut code, or are they only concerned with higher aspects? There’s no doubt about this in my mind – software architects have to code, code regularly and code well. You have to know the details of the software because the original design never makes it to actual production. If you’re going to design the next version, you need to know what design actually became and why so that you can both learn from the design errors that were made and better account for reality in your designs.

That’s a large part of why I never want to see a title of Software Architect at Ephox – ivory towers and purely theoretical approaches just push more problems on to the people who actually do code. Great engineers are at least reasonable generalists, even if they have specialist expertise on top. You don’t have to know everything about everything, but you should at least know enough to get by, and most importantly know your limitations so you can ask for help when it’s needed.

I think the political aspects are the biggest challenge for my chosen career path. Influencing people, choosing your battles, recognising and compensating for your own biases, inspiring, selling designs, leading and guiding are quite difficult soft skills to develop. I really see the “iron fist” architect as someone basically using intensity and authority to compensate for a lack of these skills – this was definitely prevalent with the new architect in my previous job. Sometimes I do use intensity to win debates, but I don’t like it, and it is something I will work on. Intensity is still a valid and useful tool, but there are other techniques available. People skills are the most common stumbling block for engineers, not because engineers are inherently socially inept – that’s mostly a myth, but because the importance of people skills only becomes obvious later in an engineering career.  If you’re in sales, marketing, HR, management, medicine, administration and most other jobs, people skills become an obvious requirement very early because from the very beginning of your career you have to deal with people outside your profession. Engineers are often left as a sheltered part of the engineering team when they first start out and only interact with their direct manager and other engineers.

Ephox helps avoid this in two key ways.  Firstly our engineers help out in support so they have to learn how to keep a client happy, even when the client happens to pissed off because the software’s not working. Thankfully most of our clients never get to the pissed off stage, but support is rarely a good time to meet people, yet it’s one of the best opportunities to impress them.

Secondly, Ephox has a very flat structure. It’s quite easy for even new engineers to see that if the want to step up, take on a challenge and improve things that they can. While we’re no Apache foundation, there’s a definite amount of meritocracy in Ephox.  If you go about doing great work, taking initiative and making things better you’ll find that it’s not only recognized and appreciated but followed by giving you real authority to own that area of the business. Of course you can overstep your bounds and get yourself into trouble, but there are opportunities and with the right consultative approach it’s usually pretty easy to avoid stepping on toes.

Dylan, what I really, really like about this part of your post is that you’ve actually identified skills you want to improve. I really hope everyone at Ephox has done that, even if they haven’t posted it on their blog. For me, I’m largely working on the same kinds of people skills that Dylan identified and have been for a while now.

I learnt a lot from the types of arguments Dylan mentioned as well. I knew about them before, but what I think is really useful is to know when you’re using each of them and other persuasive tactics so that you can use them more intelligently. I suspect there’s merit in engineers taking courses on persuasive writing and speeches to learn these skills – even if, and perhaps especially if, they are finding they “win” arguments quite often. Being better at persuasion may not increase the amount you get your way, but it will likely get to that point faster and hopefully get there via consensus more often rather than just strength of passion or authority.

However, the way I see it, the software itself has needs. There is merit in improving, maintaining, massaging, refactoring software simply to satisfy the software’s needs. It’s not just so that the software can meet its client’s needs. The software itself needs to be healthy, purely for the sake of it. If you think of software as a living organism, this is the approach of a mother or carer. Rather than making the software healthy in order for it to succeed, you make the software healthy for the sake of it, and this will help it will succeed as a byproduct. To me, this attitude is useful for an architect. I think you need to be careful with this line of thought.  In one sense it’s important for an engineering team to think like this because it helps avoid short term thinking and discarding architecture because there are short term gains to be gotten – a very common problem businesses fall into.  On the other hand, this argument will fall completely flat outside of the engineering team. Businesses live and die based on the sales they make, not the architecture of their software. A business simply can’t afford to develop great architecture just for the software’s sake – it needs to focus on delivering shareholder value because that’s ultimately all that matters in business.

The good news is that healthy software gives some really critical benefits that do provide shareholder value. Any business that ignores that faces peril, and not just long term peril. There are a lot of ways that the health of your software affects the business value, but the two more important and easily explained are that unhealthy software increases the cost of sale and it increases the cost of development.

Poor quality software has a longer sales cycle and requires more involvement from the sales and support team. That means a higher cost of sale and directly affects the short term viability of the business. This is the key reason why software quality matters so much in an economic downturn like we’re currently in.  Sales cycles are extending all by themselves as business push out expenses, so anything we can do to control that cycle is critical.  Indirectly it also affects word of mouth, but that’s far harder to quantify and is a generally more long term effect.

Software with poor internal quality may work perfectly for clients but it still has a major impact on the cost of development.  The higher the internal quality of software, the cheaper it will be to develop new features and respond to customer needs. That directly affects expenses and very quickly flows on to competitive advantage in sales and increases the addressable market both of which have a large impact on revenue.

Bottom line, it’s great that engineers want to create high quality (internal and external) software just for the sake of it. That’s what engineers should be passionate about. Reality and those pesky people skills mean you need to justify that with tangible business benefits if you expect to get paid for doing it though. Unfortunately, reality will also mean that you have to make trade offs that will require sacrifices to product quality, but you have to be well informed to make those trade offs properly and that means stepping outside of just being an engineer.