Questions for Simon

[K. Tsang]

Welcome Simon.

Your book "Software Architecture for Developers" looks like a great book.
Is there a discussion or comparison to the other levels or types of architecture (eg application architecture, solution architecture, enterprise architecture etc) in your book?

In today's world, there are many forms of managing/designing/developing a project (eg agile, iterative, test-driven, user-centered etc), do you see a trend in the near future that any one of these will dominate? Or a combination of these will be used?

How would you compare the roles of an "architect" and a "manager"? Or what is your view point on these 2 roles? Should these roles be separate person in a project?

Thanks and congrats on your book.

[Simon Brown]

K. Tsang wrote:Welcome Simon.

Your book "Software Architecture for Developers" looks like a great book.
Is there a discussion or comparison to the other levels or types of architecture (eg application architecture, solution architecture, enterprise architecture etc) in your book?

Thanks K. Yes, the book actually starts out with a quick definition of software architecture in relation to application architecture and enterprise architecture -> https://leanpub.com/software-architecture-for-developers/read#what-is-software-architecture

K. Tsang wrote:
In today's world, there are many forms of managing/designing/developing a project (eg agile, iterative, test-driven, user-centered etc), do you see a trend in the near future that any one of these will dominate? Or a combination of these will be used?

I've spoken to hundreds of software developers over the past couple of years and the one thing they have in common is that they all approach the software development process in a different way! Some are still using very traditional waterfall approaches, some are adopting agile and some are just hacking! I think that the industry will eventually become more akin to engineering, but this isn't going to happen in the near future.

K. Tsang wrote:
How would you compare the roles of an "architect" and a "manager"? Or what is your view point on these 2 roles? Should these roles be separate person in a project?

Thanks and congrats on your book.

If by "manager" you mean project manager, then yes. I have seen both roles undertaken by a single person (these are often called "technical project managers") but they typically fail to do either role well. Your mileage may vary though. I prefer having separate people undertaking the roles and then there's a really nice separation of responsibilities. The architect looks after the technical delivery/risks and the project manager looks after the budget/timescale/team stuff.

[K. Tsang]

Thanks Simon for your answers and the link. It was a nice read.

I also went through the "codethearchitecture" site and I like what I see with the presentations.

For the architect vs manager role thing, I agree with what you say. Yet from my work history anyway these 2 roles tend to be the same person.

[K. Tsang]

Hi Simon

Having looked through your site, I noticed a presentation "broadening the T". My understanding is the horizontal is breadth and the vertical is depth.

Another question based on this is to become a software architect (or another other architect), how technical (depth) does one need and in how many topics? Eg programming xyz, design pattern, framework abc, app server pqr, etc There are so many products or technologies one can delve on. And at the same time, one can't be expert at everything.

On the contrary, for the breath, being aware of such and such technology but not knowing what its purpose or benefit would be like not knowing it at all. But when one start researching/learning it the depth mode may take over. How much is enough for breath?

[Junilu Lacar]

Simon Brown wrote:I think that the industry will eventually become more akin to engineering, but this isn't going to happen in the near future.

You'd think it would, given that computers and computing are very mathematical and exact. Hardware definitely falls under the umbrella of engineering but software is a very different beast. If I were to categorize it, I would throw software development in with the literary and performance arts. We developers are authors (hence, the @author Javadoc tag). We tell stories: the stories of how the computer behaves. Ever notice how well-written programs actually tell you "what" they do vs "how" they do it? In other words, the code reveals its intent and hides implementation detail. Like some of the best movies, the best programs make their users go "Wow, that was awesome, but how did they do it!?" On the flipside, like bad movies, bad software leaves its users disappointed and unsatisfied.

Developing software is very much like producing a movie or a play. First, someone has to come up with an idea and write it down as a script or screenplay. Then there's the "production" part of the effort, where you have to bring the work to life on a stage, the big screen, or make it available for general consumption such as newsstands or bookstores. For software, the production effort culminates on the production servers, or Amazon EC2, or the Apple Store, or the Google Play Store. David Hussman, a regular on the No Fluff Just Stuff Symposium circuit, has or used to have a presentation where he draws the analogy between producing software and producing a work of art such as a music album, a play, or a movie. This view of software development is not uncommon, as shown by the Software Craftsmanship movement.

[Simon Brown]

K. Tsang wrote:Another question based on this is to become a software architect (or another other architect), how technical (depth) does one need and in how many topics? Eg programming xyz, design pattern, framework abc, app server pqr, etc There are so many products or technologies one can delve on. And at the same time, one can't be expert at everything.

On the contrary, for the breath, being aware of such and such technology but not knowing what its purpose or benefit would be like not knowing it at all. But when one start researching/learning it the depth mode may take over. How much is enough for breath?

This is an interesting question. Architects need to know something about the technology that they are using to design something. So if you wanted to design a Java EE solution, you need to know about Java EE. The danger, of course, is that as your depth of knowledge increases, you become a "Java EE architect" rather than just an "architect". I actually don't think this is bad, provided that you have an open mind and an awareness that there are other solutions out there, some of which might not be Java and some of which might be better. This is the breadth part of the "T". Ever heard the saying, "if all you have is a hammer, everything looks like a nail"? I've seen a team who specialise in Microsoft SharePoint and pretty much all of their solutions are SharePoint-based, despite SharePoint clearly not being the right solution in many cases. It's all about choosing the right solution, and sometimes you have to admit that somebody else might be better suited to providing the answers. As you said, we can't know everything.

[Junilu Lacar]

This goes back to the heart of a principle-based practice. When you have a good understanding of design/architectural principles, you have a solid base (the horizontal part of the "T") from which you can learn a specific stack of technologies deeply (the vertical part of the "T"). A foundation based on principles makes it easier to leverage previous knowledge and experience in one technology stack to gain knowledge and experience in another technology stack because while the details may be different, I have found that almost everything can usually be linked back to a fundamental principle.

Another way to look at it is to invert the "T". When you do that, the real picture of your breadth-vs-depth starts to look like a bar graph that is (ideally) shaped like a bell curve. The middle bar is the tallest and represents the stack that you're most familiar with. The shorter bars to either side of that represent the stacks that you are progressively less familiar with. The X-axis, of course, is the principle-based foundation that ties all the knowledge about the different stacks together. I think I'm lucky in the sense that I have quite a number of bars in my "graph": Agile, Scrum, XP, Java, JEE, OOP, TDD, BDD, DDD, Aikido, Volleyball, Football to name a few. The last three in that list may seem oddly out of place but because (I like to think that) I have a good principle-based foundation, I can draw analogies from these and apply them to learning and understanding more about the others and vice versa.

Edit: I think this is why books like Simon's are important to read because they help add to and solidify the foundation on which you can build out more "stacks".

[Comal Rajagopalaratnam Muthukumar]

Simon Brown wrote:

K. Tsang wrote:Another question based on this is to become a software architect (or another other architect), how technical (depth) does one need and in how many topics? Eg programming xyz, design pattern, framework abc, app server pqr, etc There are so many products or technologies one can delve on. And at the same time, one can't be expert at everything.

On the contrary, for the breath, being aware of such and such technology but not knowing what its purpose or benefit would be like not knowing it at all. But when one start researching/learning it the depth mode may take over. How much is enough for breath?

This is an interesting question. Architects need to know something about the technology that they are using to design something. So if you wanted to design a Java EE solution, you need to know about Java EE. The danger, of course, is that as your depth of knowledge increases, you become a "Java EE architect" rather than just an "architect". I actually don't think this is bad, provided that you have an open mind and an awareness that there are other solutions out there, some of which might not be Java and some of which might be better. This is the breadth part of the "T". Ever heard the saying, "if all you have is a hammer, everything looks like a nail"? I've seen a team who specialise in Microsoft SharePoint and pretty much all of their solutions are SharePoint-based, despite SharePoint clearly not being the right solution in many cases. It's all about choosing the right solution, and sometimes you have to admit that somebody else might be better suited to providing the answers. As you said, we can't know everything.

Hi,
"If you have a lemon make a lemanade" is an old proverbe of Dale Carnegie .The latest is As under:- synchronising the discussion

If someone asks my age , &supose i told it also,then the so called programmer does expand my age too.Please forward your delightfull feed back on this after executing a smal java coded prg .


As
CRMK

import element.*;

public class AgeInput
{
    public static void main(String args[])
    {
        ConsoleWindow c = new ConsoleWindow();
        c.out.println("How old are you?");
        double ageInYears = c.input.readDouble();

        c.out.println("I can't believe you're "+ageInYears
                      +" years old!");
        c.out.println("(That makes you about "+(ageInYears*365.25)
                      +" days old!)");
    }
}
/*
How old are you?
38
I can't believe you're 38.0 years old!
(That makes you about 13879.5 days old!)
*/