Architecture Interview Questions

I've written about architecture topics in the past, especially relating to the role of "Architect" in Digital TV Systems & Software projects. Though I'm no architect myself, although I could very well have become an architect if I chose to maintain on the purely technical path; I still have to be across the technical disciplines at the high level, when it comes to program or project managing large-scale technical projects. 

When I start or join a new project, one of the first things (apart from familiarizing myself with the product spec) I do is to seek out the architects, looking for any technical information in the form of design,

(document/wiki/etc) that scopes the high level system design or architecture that we're trying to implement & deliver. 

Failing that, having found no clearly defined architect role, I would go about setting up this role as a matter of urgency. No architect means no technical ownership, means flaky interfaces, chaotic system integration points, and a very bumpy project ride lays ahead!

In the past I have worked very closely with many great architects, both as an engineer as well as manager, that I've learnt from this experience enough to know what to look for when seeking out architects. If a project requires it, I do get involved with the interviewing architects, system integration managers, project managers and other roles. 

I thought I'd share a list of some of the questions I generally tend to ask when interviewing for the role of Architect in a Software/Systems project - hope you find it useful. If you read my other posts on architecture, you will get to understand I have a more holistic expectations from architects, rather than just answering this list of ~100 questions!

Agile team goals - straw man...

Over the past few years, going back since 2004, when I first started working in an agile-like fashion to present day, I've seen companies and teams transform their development practices, maintaining a strong desire to continuously improve from past experiences. I've seen such transformations driven top-down (where senior management saw inefficiencies with existing processes, accepted a step change was needed to survive growth challenges and thus set about a strategy to implement new processes). I've also experienced the change coming from within the team themselves, experimenting at first (in the background), proving the value added to not only the local team, but to the wider organisation as a whole (although it wasn't easy, it is generally harder to influence bottom-up).

In order to derive some success from these transformational initiatives, there is usually a person who takes on the role of catalyst or driver, maintaining a clear vision of the goal and desired outcome - keeping people together, constantly reinforcing the message, always constant reminding. Generally this person is energetic, evangelic and carries enough of an aura for people to just believe & follow, the mark of a true leader. This is also made possible by having a team that has been through the mill, have battle-scars to show for it, and are really sincere in adopting the new strategy.

But what do you do, when you have a relatively young development organisation, cobbled together from various parts of the world, all differing skill levels & competencies, and when the leadership is lacking (incoherent) such that no one in the department has ever delivered a project successfully using Agile/Scrum before, have never really seen the development, people & cultural transformation required to realise the change from start-finish, and not have had the patience & privilege to live the agile journey of a few years??

What do you do when a team of aspiring young engineers that are just starting out on delivering formidable, real world-class products for the first time, who have been used to the heavy-handed old school project management styles of yesteryear -- suddenly fall in love with the premise of Agile -- but unfortunately lack the depth and breadth of understanding the real challenges of software engineering (product development, not proof-of-concepts)??

In the business of Set-Top-Box software product development, this is the software that provides your TV services like Personal Video Recording, Video On Demand, Linear TV, Electronic Program Guide, etc. A mixture of hardware design, low-level drivers, middleware operating system & high level user interface. Technologies are Java, Flash, HTML5, C/C++, embedded environment. This space is becoming highly competitive, how do such software providers remain competitive??

The answer generally touted is "We're adopting Lean/Agile/Scrum - we deliver fast, work with a rapidly changing market, flexible & practical" principles for product delivery -- but in reality ain't that easy - Agile adoption is a journey of at least three years, including time for experimentation & failure - it doesn't happen overnight. Some foundations need to be in place, principles that become the substrate for the future - a team without these foundations is operating in chaos, or as they say "Paying lip service to Agile"...

In this post I provide a straw man around goals that a development team could strive for in their quest for Agile. Just as they teach you in business school, that you need to have a plan guided by a mission, vision, strategy & plan of action -- so too can a development team ground themselves around goals that are SMART (Specific, Measurable, Attainable, Realistic, Timely). Moreover, if a team can latch onto some Real, Tangible, Concrete, Credible messages, these can be quite powerful in galvanising the teams around a singular purpose:

• Straw-man goals to drive Agile Development
• Sample Software Development Team Charter

Review: The Deadline

I came across a review I wrote for Amazon sometime back 2010:

The Deadline : A Novel About Project Management is a novel attempt at describing life as a practising project manager in the software development industry. Choosing fiction as a means for distilling this experience was the right call, since many books on software project management talk about mostly the process, but less so on the fundamental human experiences.

This book attempts just that, a perspective on the people elements, and it doesn't do too bad a job either: It tells the story of a Mr. Tompkins who takes on the job of managing an army of software engineers, to create and deliver 6 software products from scratch, limitless resources. So he sets off creating an experiment: create 3 project teams for each product, each with the same goal of delivering the product by an artificial deadline (that was later made real by a tyrant manager bringing the deadline many months forward) and set about observing the progress of each team, thereby understanding the implications of their actions - in an effort to understand the secrets behind real world processes...

Whilst this book does get my recommendation, it must be noted that this was written and published over 10 years ago - which makes much of the experiments seem a bit out-dated and irrelevant. The shrink wrapped software industry age has passed on, which is why I feel the book has missed out on exploring modern practises seen with open source development, off-shoring, outsourcing; large scale distributed development, test driven development, agile, etc - with real world demanding customers, where companies are driven by competition, so hard that there is really no time for proper planning, estimating, playing around with models and predictions is a luxury rather than necessity - the deadline is really about winning new business and keeping your customers happy; and your competitors at bay; delivering software that is of acceptable quality to your customer, stressing less on established processes like CMM level 3/4/5 (depends on the industry of course), etc.

This book is considered  a work of fiction but it does contain real world references for follow-up reading. One such interesting reference is the topic of modelling your hunch-base, using for example, iThink a systems thinking tool that allows you to model business processes, using parameters for tuning and testing output of various scenarios. This, along with archaeological project data mining for metrics, will provide invaluable resource to a team when considering new projects.

If you're an experienced software manager however, then most of the encounters will not be new to you. It feels like there should be a sequel to this book, updated to support and test out current theories, offering more detailed explanations of each experiment, which is lacking here. One gets the overall idea that the project management laboratory is an interesting topic, but there is so much more to play with rather than just over staffing and design philosophy...

All in all, I am nevertheless pleased I read it and would definitely recommend to anyone involved in software projects.

2013 Update: Although times have changed since DeMarco & Lister's experiences, much of the essence with the challenges of Software Projects nevertheless remain relevant today. For those of you not familiar with DeMarco, I strongly recommend you follow-up on their works - I've read & own all of these - highly recommended, I learnt quite a bit from these, further amplifying my passion & respect for the Software Engineering Profession:

Summer Reading List over December

Since returning home* to South Africa in June 2011, life has been really pretty damn hectic, they say relocating your family & household contents is one of the most stressful things you can do in life - added to that, working with a new company presented itself with a massive culture shock. So I had my hands full with handling not only work but also family transitioning to the new life. Not to mention I quit my permanent job and ventured into consulting territory. This transformation has set me back someways: in particular, my reading list fell on the back burner, and it's only now that I'm starting to rev it up again. Another reason for not maintaining my reading as I used to in UK, is that South Africa is way behind in the online shopping space, the deals I used to get on Amazon were so great in terms of price (not to mention service!), that when I pick up books from the shelves in stores here in SA, or even online (Kalahari), I often cringe at the price tags (definitely cheaper in UK, wait). I still haven't made the leap to the Kindle yet which is the sensible thing to do (although the Pound/Rate exchange rate is crazy!), I was an early adopter a few years back, but I really wasn't impressed at the time - so still prefer my hardbound copies! I do have my eye on the Kindle Fire HDX though...

Here's a snippet of the handful of books piled on my bedside table for reading over the South African summer break:

Nissan Motors Production Line and Software Systems Development

This week I was invited by @Farid from Crossbolt to tour the Nissan Production Line in Pretoria, to see first-hand the Lean / Kanban / Kaizen production model in action: Cars come off the line every four minutes (cycle time), Zero defects straight-through rate.

I jumped at the opportunity without hesitation. Although I've ran software projects as a factory-line model before, I had never actually been in a real car production factory before. Fareed had decided to take his IT Operations team on this tour, after doing the theoretical knowledge-share on Lean.

He felt it would make more sense for his team to witness first hand the theory in action, where the metaphors can be easily visualised and applied to an IT Ops / Systems Integration space. Not a bad idea...

This post is just a brief dump of my personal take-aways from the visit. I will try to expand on them in later posts once I've let the ideas play around my head for a while to morph into shape. Despite what some people might say: Software is a creative art, it can't be rushed and boxed into a production line, when it comes to pushing out consumer production software, I beg to differ: there are indeed many parallels from the manufacturing sector (which is seriously way more mature than software development) that can be drawn upon and applied to software teams - incidentally this is the roots of Scrum / Lean anyway - just taking the same concepts and applying it to software teams...

There's plenty of info on Kaizen / Kanban / Lean / Poka Yoke / Scrum - I won't go into detail here. For context though, the line we visited was a multi-model line. This means that the line produces more than one type of vehicle in a continuous flow. Any team on the line could be working on a different model at the same time. Some car production lines specialise in just one model, but this line builds at least four different models. Because the flow is continuous, a car comes off the production line every four minutes, like clockwork. The team working on the line therefore, are cross-functional and cross-skilled. 

Take-aways: