"project management" entries

When computers were small and programs short, writing programs for them was pretty much a solo enterprise. But as computers became more powerful, and importantly, interconnected, you started to see software development in teams, and with teams came the most unfortunate of byproducts, management.

In a modern software development project, there are in fact a lot of contributors who have nothing to do with actually generating code. You have a product owner, determining exactly what functions the software should enable. You may have user experience designers, who are turning those requirements into a cohesive and logical look and feel. You have UI designers, creating graphical assets and fleshing out the U/X designers. There are strictly overhead roles such as managers of different flavors (including scrum-masters, who are really just a specific breed of manager). There are the developers themselves, who may include team leads. And then there are the folks with the mysterious title of Architect. But just what do they do?

In my depressingly long career as a software engineer (the career isn’t depressing; the length of it is), I have seen no title as subject to variable interpretation as Architect. I’ve seen architects that were essentially the MVPs of the project, and I’ve seen ones that are speed-bumps on the road of life. Why they are placed onto projects, and how they are used, can drastically influence the overall happiness and productivity of a team.

Let’s begin our look at the role of architects with the most negative example. There exists a class of companies that have architects Because They’re Supposed To. In this kind of environment, architects can gum up the works in a number of ways. First, these tend to be the people who Read Things in Magazines (or online). They tend to be in love with concepts like elegance and abstraction (which are good in moderation), and to some extent try to justify their existence by making things more complex. They rarely code.

Let’s call this subspecies of architect the Formalists. You can tell them by the fact that they have more books on UML and Patterns on their bookshelves than on languages and operating systems. The Formalists believe in form over function. As an example of the kind of poison they can spread in a project, I once had an architect explaining to me that my clean, compact and well-tested Java code was unacceptable, because I did not implement a single Pattern in it. I added a Singleton (which neither helped nor hurt the code), and he became happy.

The Formalist frequently kills the enthusiasm of the developers with mandates that drastically increase the workload of the developer for little to no benefit. Formalists are the polar opposites of the agile process, because they will insist on building in levels of complexity far in advance of a proven need for the extensibility provided. If you have a simple application laden with Enterprise Service Buses and Factories, a Formalist probably had their hand in the design.

Let me be clear, when used correctly, architects are awesome. Let’s label the group of good architects the Pragmatists. The primary phenotype of a good architect is that they know how to code, and code well. Beyond that, a good architect serves a crucial role in the definition of the product requirements, not just drawing boxes at 30,000 feet.

To understand this role, you have to look at the lifecycle of a successful product. After the basic product requirements have been laid out, but before developers start to implement, there’s an important step that many teams miss. Someone, and by someone I mean a good architect, needs to flesh out the requirements into a sufficiently detailed set of high-level tasks. It is in vogue these days to do this during the “grooming” portion of the scrum process, but it really needs to happen much earlier, and by someone looking at the entire product and how this particular task fits into the overall picture. The architect needs to answer questions such as:

• Do the U/X, UI, and development requirements really cover the end user requirements (i.e., gap analysis)?
• Is this task being designed and developed in a consistent fashion to the remainder of the application (and, where appropriate, the way software is developed at the company in general)?
• Is the design flexible enough to allow future enhancements?
• Does the application implement appropriate levels of security and meet required performance standards?

Read more…