Who is an architect?

While the question ‘Who or what is an architect?’ could be popular nowadays, the important for a project and for an organization is the act of architecting, the continuous care of all-encompassing properties that give the illusion of simplicity to customers and end-users. That is what is important. That is an essential ingredient for project’s success.

Discussing the establishment of a single individual as the prima-donna decision-maker is foolish, is more about that “taking the form but not the substance” unwise behavior typical of overenthusiastic and blind advocacy of the youth (see: Discussing uncomfortable questions).

Some people believe an architect does not need to get dirty with technical details but also believe they must be in charge of important technical decisions, at the same time. I think doing so is to keep this guy in a position of incompetence.

I think architect is a collective role, not an individual. if we think —on one side— of an architect as a role, not as an individual, whose key aim is to describe an abstract, coherent and conceptually integrated system clearly to all the team and, if we think —on the other side— of a developer as a role, not as an individual, whose key aim is to provide feedback about the technical feasibility for each architectural decision, then both roles could be fulfilled by the same professional or group of professionals (like a team in charge of accurately delivering the right system into the hands of customers and end-users).

What do we –really– mean by 'coding'?

Suppose a young member of the developer role in your next project team approaches to you (member of the architect role in the same project) and said: —I will be coding as part of my role in our project and I am looking for further understanding of how my work will be related to actual business value. Could you –as seasoned software professional– please share your insights with me?

What would be your answer?

1. Young subordinate: your main task —as a necessary evil— will be mechanical and repetitive because all intellectual and engaging artwork will be exclusively done by me and my peers; please be prepared to eagerly follow our direct commands and to strictly follow our plans, doing whatever required extra effort in order to hit established milestones on time. Your association with business value is that and the same of the cheap labor force in well established economies of scale, that is, the execution of industrialized tasks by expendable and interchangeable human resources. You know, it is the real world and nothing can be done about it. No problem at all, it’s my pleasure to clarify.

2. Young peer: first of all let me thank you for the opportunity to share my perspective on such an important question of yours; second, let me please clarify that coding is –actually– another name for a design activity which is part of a continuous flux of learning experiences shared by all members of the team. You, along with the rest of project team members, will be doing software design which is a cooperative endeavor to tackle the complexity coming from a number of dimensions like people, process, product and technology; we need all your intellectual power, critical thinking and energy to keep a balanced mix of problem-solving, creativity and tactical execution as the project unfolds. Join us, we are about to review current business priorities with the customer...

3. Please excuse me but I’m really not the right person to answer your question because I’m not in a position that has exposure to such level of fine-grained details so I don’t know what you are going to be doing and how that is related with business value.

4. Next possible answer...

Now, please assume that you are fully aware of a secondary purpose for the approaching developer in your project, who also is a senior researcher, to report back to general scientific community a current, actual, reliable and justified characterization of the ‘coding’ activity.

Please re-read the proposed answers and re-think your own answer so far but now with this new perspective in mind.

Would you change your answer? Which would it be now? Why?

What the role of an architect really wants to be?

After re-reading sections about architecture in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, Jr. I am wondering if what the role of a nowadays architect really wants to be is that of the old notion of data processing analyst.

The key deliverable from data processing analysts was written functional specifications; the best of those analysts described an abstract, coherent and conceptually integrated system —yet to be implemented— and all their description was from the standpoint of the business and end-user. Later (and sometimes), the senior developers took the functional specification and delivered a technical specification of how the system’s internals would be “constructed” and then —in all waterfallish fashion and most often than not— the “dime-a-dozen coders” took the technical specification and “built” the system. It all made sense. It was all wrong (see Writing 2 here).

Data processing analysts did not “code”; very, very far from doing that. Isn’t what many are saying about architects?

Many years, colossal amounts of human effort and vast amounts of money have been wasted for our industry to learn that waterfall and sequential thinking —like the one described a paragraph ago— for the realization of complex computing systems just don’t work for most of the situations. Why would we want to bring back the notion of data processing analysts? Which could possibly be the advantages of doing that?

Now, if we think —on one side— of an architect as a role, not as an individual, whose key aim is to describe an abstract, coherent and conceptually integrated system clearly to all the team and, if we think —on the other side— of a developer as a role, not as an individual, whose key aim is to provide feedback about the technical feasibility for each architectural decision, then both roles could be fulfilled by the same professional or group of professionals (like a team in charge of accurately delivering the right system into the hands of customers and end-users).

What is the role of an architect? Sorry, I don’t get it, architect *is* already a role, not an individual. Should an architect design? Yes, the mere essence of architecting if that of describing —from the standpoint of the business and end-user— an abstract, coherent and conceptually integrated system that solves the business problem.

Should an architect code?

For those interested, the role of an architect is –also- being discussed in MSDN, here. My first reply next:

The answer depends on what do you mean by “architect” (noun) and also by “code” (verb).

What seasoned designers talk about when discussing architecture is so all-encompassing and important for the final outcome that makes me wonder why a project team member wouldn’t need to fully master the actual concretization of such concepts at all levels? I suspect the answer is related to the sad state of practice in many organizations due to the faulty belief that the main task in writing software is a mechanical and repetitive task that can be industrialized with expendable and interchangeable human ‘resources’.

See: Discussing uncomfortable questions

Pursuing a clear definition of a concept like architecture is good because the related thinking-researching cycles give opportunity to reach sound conclusions (by ‘sound’ I mean -inferences with scientific properties like provisional and falsifiable). I have not yet found a satisfactory definition for what architecture in computing really means, far less a definition of what the role of an architect could possibly be. By now, the proposal by Frederick Brooks, Jr. for the concept of architecture is arguably the most sensible definition I have found:

“Computer architecture, like other architecture, is the art of determining the needs of the user and then designing to meet those needs as effectively as possible” –Oxford English Dictionary

Why? Because it explicitly includes three key concepts: art, user needs, and design.

A discussion about the design concept would be in order to answer the question: “Should an architect code?”

So, if by code, do you mean executing a mechanical and repetitive task that can be industrialized? Then the answer is ‘no’ (and also ‘no’ for any self-respecting software professional by the way).

On the other hand, if by code, do you mean the act of expressing design intentions and the execution of models to corroborate hypothesized ideas with contextual data? Then the answer is ‘yes’ (and also ‘yes’ for any self-respecting software professional by the way).

Next, I quote a thinker whose name I don’t know (if the author is listening, see: What type of person should design software? ).

"There are certainly people who think more about high level structure than they do about low level details. This is a valuable talent, and not one that should be scoffed at or discounted. Unfortunately, in some circles, it has become popular for people with these talents to divorce themselves from code. The term "architect" takes on an aura of authority and power, whereas a coder is deemed a lowly laborer, a dime-a-dozen worker bee.

In reality, while the difference in talent is real, the polarization into different roles with different authorities is harmful. Those folks who are good at modeling and architecture must still remain grounded in code. For their skills to remain relevant and useful, they have to keep in touch with the medium they are trying to create structures for. Likewise, the programmer who divorces himself from concerns of architecture harms himself and his team by abdicating responsibility for something he is in an intimate position to control. There is a way for these two talents to work well and closely together, but they have to put forth the effort to understand each other."

More notes about the practice of architecture:

Software architecture is much more than structure

Architecture is not about scalability, not even about user, it is all about usage

Discussing uncomfortable questions

For those with critical thinking habits, let’s cogitate about this:

If day after day goes by with nobody discussing uncomfortable questions like these, won't the good people of my country be guilty of making things worse?” —Donald E. Knuth

Could this type of questions be translated to the lesser sphere of software development and the quality of what we deliver to customers and end-users?

Let’s think, for example:

Could it be possible that the notion of division of labor in industrial settings just does not deliver the same benefits in software development?

I have seen and heard that many so-called ‘software architects’ lack the ability to write shippable software by themselves (with their own hands) and that they are taking key architectural decisions based on hypothesized ideas not actually corroborated with the results from execution of models. After taking architectural decisions this way follow the expenditure of vast amounts of human effort and financial resources to carry out a given project only to find out —most often than not— that most or all of that expenditure have been wasted. Serious postmortem analysis could revel that part of the root cause are those architectural decisions taken prematurely. Why should software consumers accept increasing levels of ineptitude in software development teams?

Could it be that software development industry has got wrong the practice of architecture?

Could it be that software development industry has got wrong the very essence and purpose of modeling (in reference to modeling as in engineering disciplines)?

Has the “taking the form but not the substance” behavior gone too far among us members of software development industry?

What kind of work could be expected from developers and their managers if their view of software development is based on the belief that the main task is a mechanical and repetitive task that can be industrialized with expendable and interchangeable human ‘resources’?

If day after day goes by with nobody discussing uncomfortable questions like these, won't the good people of our software development industry be guilty of making things worse?

Update on what is software development -art or science- debate

This is an update on my internal inquiry: What is software development, art or science?

Not surprisingly, the act of programming digital computers is both, art and science. Now I know. Actually, the simple question “what is software development, art or science?” is a malformed or ill-formulated question because it presupposes the subject matter can be or an art or a science as a whole.

Software development is art because the essence of the root meaning of art includes the notion of skill, dexterity, ability. That is to say, in order to practice software development there is need of –unavoidable- certain skill set.

Software development is science because the essence of the root meaning of science includes the notion of reliable knowledge. That is to say, in order to practice software development there is need of –unavoidable- reliable knowledge.

In both —art and science— we, as guild of professionals, need to improve badly.

For further reading, read Computer programming as an art by Donald E. Knuth.

Belief and behavior

A belief is —for practical purposes— something that we thought is true. The incredulity or disbelief is a case of belief where we thought of a belief to be false. To doubt about something means to keep the related true-false judgment in suspended or pending state. To ignore is to have a complete absence of that judgment. To know something or to acquire knowledge is the outcome of a process that serves as basis for a special belief, one that is properly justified.

A religious belief is part of just one more type of belief within the extensive spectrum of belief types any given person could uphold. In current sociology of software development, many people uphold beliefs very similar in nature as religious beliefs, e.g., "X will remove all our problems" or "This important project will succeed because we have adopted X"; where X is any fashionable trend or buzzword blindly followed.

Most of the time, the conduct of a person can be explained in terms of the beliefs this person upholds in the occurrence context of the behavior in question. The context can include social aspects like office, school, home, church, etc. Our beliefs have great power to influence our behavior and while our beliefs remain our behavior will do so.

The correlation between the chosen conduct and its consequences (costs and benefits) encompasses the fuel that feeds the process to improve our beliefs, and therefore, our behavior. This correlation is not the only input for an improvement process, it is only one that is usually more affordable in comparison with other inputs as can be a tragic or catastrophic personal experience, also it can be the increase in conscience because of the understanding of a justified true belief about the same subject matter.

A key question is then: Which process have you chosen for the improvement of your beliefs?

The "What's coming after X?" question

What could be say about the question: What's coming after X?
Where X could be:

• Object-orientation

• Software engineering best findings

• Agile development

The context for the question:

• Asked by blind advocates of X

• Usually young people (mental youth mainly)

• Looking for the next sensational fad

The question remains me about the question "What is coming after object-oriented programming?" to an object-object oriented practitioner and author and his reply: "Our industry needs to understand object-orientation in the first place before thinking in what is next". Or the question "Which mayor techniques do you see coming in the horizon of software engineering" to Dr. David Parnas and his reply "The mayor techniques for software engineering have been already here and for a long time, but have not been fully understood".

Learning items in software development

A subjectively created list of books about software development grouped in the following categories:

Category I: Practitioners sharing their hard-won and thoughtful experiences.

Category II: Foundational knowledge.

Category I: Practitioners sharing their hard-won and thoughtful experiences

Agile Principles, Patterns, and Practices in C# by Robert C. Martin, Micah Martin

The Art of Agile Development by James Shore, Shane Warden

Implementation Patternsby Kent Beck

Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck and Cynthia Andres

Object Solutions: Managing the Object-Oriented Project by Grady Booch

Organizational Patterns of Agile Software Development by James O. Coplien, Neil B. Harrison

Agile and Iterative Development: A Manager's Guide by Craig Larman

Agile Software Development: The Cooperative Game by Alistair Cockburn

Agile Software Development With Scrum by Mike Beedle, Ken Schwaber

The Enterprise and Scrum by Ken Schwaber

The Craft of Software Testing: Subsystems Testing Including Object-Based and Object-Oriented Testing by Brian Marick

Test-Driven Development: A Practical Guide by David Astels

Concurrent Programming on Windows Vista: Architecture, Principles, and Patterns by Joe Duffy

Multi-Paradigm Design for C++ by James O. Coplien

Working Effectively With Legacy Code by Michael Feathers

Windows Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition by Mark Russinovitch, David A. Solomon

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

 Agile Project Management: Creating Innovative Products by Jim Highsmith

Agile Estimating and Planning by Mike Cohn

Software Pioneers by Manfred Broy (Editor), Ernst Denert (Editor)

I. M. Wright's Hard Code by Eric Brechner 

Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, David Thomas

Software Craftmanship: The New Imperativeby Pete McBreen

Category II: Foundational knowledge

Software design by David Budgen

Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design by Lucy A.D. Lockwood, Larry L. Constantine

Sketching User Experiences: Getting the Design Right and the Right Design by Bill Buxton

Object-Oriented Analysis and Design with Applications (3rd Edition) by Grady Booch

Practical Guide to Structured Systems Design (2nd Edition) by Meilir Page-Jones (Author)

Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design by Edward Yourdon

Structured Analysis and System Specification by Tom Demarco and P. J. Plauger

Structure and Interpretation of Computer Programs - 2nd Edition by Harold Abelson, Gerald Jay Sussman

Instructor's Manual t/a Structure and Interpretation of Computer Programs - 2nd Edition by Julie Sussman

Computer Science: An Overview (9th Edition) by J. Glenn Brookshear

Generative Programming: Methods, Tools, and Applications by Krzysztof Czarnecki, Ulrich Eisenecker

Foundations of Empirical Software Engineering: The Legacy of Victor R. Basili by Barry Boehm

Message to the whole body of management teams in software industry

To all management teams in our industry:

Please consider doing more of this: Increasing the minimum level of knowledge and modern actual practice required from software development sales personnel in order to negotiate projects with customers/users. Most of current sales personnel have notions, beliefs and premises no longer valid in the software development high-tech market in general. For example, that “analysis” or “design” or “programming” are separated stages in the software development process; they are not stages, they are concurrent activities. And many more decayed beliefs which could seriously decrease the chances for those projects to reach better business results and better customer satisfaction.

Software design skill and implementation details

Software design skill includes a tendency or habit to know the details about the raw materials our software compositions are made of. The more details you know, the higher the probability of successful designs.

Encapsulation by means of information hiding is intended for software components; that is, a software component should know only the absolutely necessary about others software components and should assume only what is part of their public interface. In other words, rules of dependency management. But information hiding is not necessarily intended for designers.

.NET Framework = CLR + BCL
where:
CLR = The .NET execution engine or Common Language Runtime
BCL = Base class libraries

The more you know about CLR and BCL, the better; not only the public interface but the internals. Reflector is a great design tool for any software targeting .NET environment.

Visual Studio IDE now provides a way to debug into some BCL classes, and this is also a good design feature.

Stepping into base class libraries of .NET Framework while debugging

Here are some pieces of information about stepping into base class libraries of .NET Framework while debugging:

• Configuring Visual Studio to Debug .NET Framework Source Code by Shawn Burke

• Debugging into the .NET Framework Source by James Kovacs

Is there any argument against beautiful code?

Beauty is in the eyes of the beholder. That is right, that’s why is very important to note who is watching and what is being observed. An assessment about golf playing by Tiger Woods could be more acceptable than one by Albert Einstein no matter how good the latest was in his field of study.

Consumers of technology in general may not care about the internal design as long as the operational interface gives them kind of illusion of simplicity and effectiveness. Many –if not most– high-tech products are black boxes. In the case of consumers of software technology, the product is the in-memory runtime image of the loaded/JITed executable machine code —as proposed by Szyperski, Murer & Gruntz and others— whereas the executable code in persistent media is the specification for the assemblage of such a product. This assembly specification is consumed by the lowest level software factory in current Turing model computing machines: the loader (or CLR’s IHostAssemblyManager).

So, which is the role of, say, source text written in Microsoft Visual C^# user interface (syntax)? Answer: the blueprint of a high-tech software product*; more specifically, its design specification.

Clearly, consumers of software may not care about the attributes of the design specification for the technology they consume. But, what about the producers of such technology? Those that care not just about one single run but the sustainable evolution of a family of multi-version complex technologies? Should they care about the relationship between the attributes of their design specifications? Should they care about that quality or combination of qualities which charms the intellectual or moral faculties, through inherent grace, or fitness to a desired end**?

I have observed that beautiful design —as implied above— adds value faster than it adds cost. So, I agree with what Joel Spolsky said in his post Hitting the High Notes.

As often is the case within corporate groups of humans, the answers to former questions are entirely personal and no matter how much coercion or illusion of control the management personnel think they apply to development teams, the net effect in the quality of software products remains in the hands of the writers of, say, source text written in Microsoft Visual C^# user interface (syntax).

*Please note that the properties of software products only match very, very few properties of products made of atoms and calling them ‘products’ actually is misleading, as proposed by Armour and others.

**That is to say: beauty as defined by the Oxford English Dicctionary

Time-bound and context-bound code

Where the name ‘code’ for a computer program’s source text comes from? What does it mean to say “here is the code for that computer program”?

Following are some associations for the word ‘code’:

As a noun:

1. a coding system used for transmitting messages requiring brevity or secrecy

2. the symbolic arrangement of data or instructions in a computer program or the set of such instructions

3. a set of rules or principles or laws

As a verb:

4. convert ordinary language into code

5. attach a code to

The mainstream association when talking about a computer programming language like Microsoft Visual C^# is b). Nevertheless, what many people actually do when writing computer programs is a). Somehow, they have believed that the source text of a computer program must be cryptic and full of assumptions related to certain social context that extend beyond the semantics of the programming language.

For example, a name like ‘dgv’ for a variable which type has the name ‘DataGridView’. Somebody could need the code —that is the logic behind the mapping— in order to get ‘DataGridView’ from ‘dgv’; even if this somebody is the same programmer six months later. A curious thing is how obvious or how smart the code behind can get to be for her at the moment of writing the code. It is amazing how a seemingly smart thing like this code behind could become so unwise with the past of time or viewed from a different social context than the original.

Team efficiency and division of labor

The concept of paradigm as described by Thomas S. Kuhn is quite profound, I have seen object-oriented software design authors quote him when illustrating the difference between other methods of software design. Yet, it is an illustration taken from another context and we software people should take care not to misinterpret it. (As we have done for example, with the concept of architecture as I have noted on several of my previous posts).

A paradigm is made of assumptions with deep roots inside our minds. I like to identify assumptions of this kind, controvert and open it to question, proposing arguments for and against; one could gain good learning experiences in doing so. As I often said: “How good it feels be wrong and become aware of that”.

For example, I have been looking for a deeper understanding of the assumptions behind the typical notions about division of labor and work efficiency in general and how those assumptions are related with us in software development, the following has gave me more food for thought:

“Our intuition, having been tuned by the concept of the division of labor in manufacturing-like processes, is that the more stories we work on in parallel, the more efficient we are being. Agile proves otherwise for knowledge-based work. Try it - the team will work more efficiently with less parallelism, even if a few individuals do not. If you are familiar with the concepts of "Lean", work-in-progress is waste until it is completed to the point where it has business value, so we should minimize work-in-progress rather than maximize it.” —Steven Gordon

More on Lean Development:
Lean Software Development: An Agile Toolkit
Implementing Lean Software Development: From Concept to Cash

Happy reading.