After reading “Who needs an architect”
In fact this essay is an assignment of the course software engineering.
Who needs an architect? Well, I think I’m not in a position to answer this question, because I barely know anything about the notion “architect” until the last lesson. However, I’ll try to discuss something in this article that related to my past experience.
I’ve developmented a GIS application for a teacher in China. I worked with 3 other students, and I am the “team leader”. As a team leader, I tried to draw a big picture of what our product will be, and I partitioned it to 3 different parts: interface, database support, and GIS engine support. I undertook the interface work myself, because I know that is the entity which actually defines requirements for the other 2 and also plays a key role in integration. This proved to be the most important decision I made to maintain our project from failure. I made a lot of bad decisions later, but by undertaking this crucial part of the project I could always be aware of current problem in the project at first. Also it ensured my control of the situation. But these advantages came with a price: sometimes it’s like that I’m doing everything myself.
In fact I tried to discussed with the team members and come out with some consents on the overall design. But I found they are not very motivated on this. They preferred that I give them a task and they will just do it. Anyway, I went on and formulated this partition into the definition of interfaces(we use c#). Perhaps from this point I unconsciously put myself on the position of Architect Reloadus. Anyway, I felt good about what I’d done. I even came up with a very optimistic time schedule, anticipating that we’ll build the big structure within a week. This blind optimism further reduced the leeway I reserved for change.
I promised to give the outline version of the interface to others in 3 days so that they could test their classes on it. We had a meeting and went on separately to write codes. However, soon I discovered that I was very lacking in the field of GIS(although the teacher brought somebody to give us a lesson). And more than that, I found that HTML and java script are not as easy as I thought, not to mention ASP.NET. At last I had to admit it would take me another week to learn about these development tools. And since I didn’t accomplish my own task, I didn’t ask others about their progress because I tought I was in no position to push them. Later I found this a big mistake in that I stopped communication when things went bad. In fact later I found all others encountered difficulty when it came to real implementation. About a week later the GIS engine part was completed, because its interface was proved to be OK, and the guy working on this was indeed smart and experienced. But still he told me that it was too difficult for him to implement some of the methods in the interface. However, The database part turned out to be a disaster.
At first I thought it a good idea to encapsulate all the database operation into one class. But the guys working database found that all sample codes in the Internet call database inside ASP.NET web pages. In those examples web pages and database are well integrated. In fact later I found that there will be too many misc trivial tasks in the database class if we completely encapsulate all the database operations in it. Naturally, they soon found their knowledge lacking in multi-thread access of database, and later they realized that there were too many required operations that were hard to clearly communicate all the requirements and also awkward to implement. At first they began to hack on this bravely(May be too bravely that they began to do things in stupid ways. Because they didn’t want to waste time in the “ceremonial” designing.), and later when the work became intractable, they stopped and gave me a collection of barely working code and trash.By that time, I found it extremely difficult to have the team motivated. In the article the Author talks about contain complexity by reducing irreversibility, but I really want to know how to easily change to another design after the interface is proved to be wrongly defined. Maybe if I had made some preparations in advance it could be possible, but I really want to know how to do this. The only thing I could do was to remedy the trouble in my ASP.NET web pages. But the initial design was inevitably torn apart. I fought along for several night and days. Than the database guys came back to me and decided to solve the problem with the experience we’d gained so far. At last we came out with a barely working system, which I felt very disgusting. And all of us felt exhausted.
Before I read the essay of “Who needs an Architect”, I always thought that the main problem I had in this practice was that I hadn’t planned well. Should I be experienced enough to correctly design the database interface, to propose a more feasible time schedule taking the learning curve of members into consideration, things can be different. However, my intuition told me that it’s too hard to plan everything well at the beginning, which made me very frustrated. After reading “Who needs an Architect”, I would gladly embrace the author’s notion that an architect can’t and shouldn’t be so perfect that he designs everything well enough at the beginning. Software development is like an exploration to an unknown region. You may point your destination on the map but you never know where it is and how to reach it after you have reached it. The architect is the captain who marches with the team. He constantly evaluates what’s ahead of the team, and makes adjustments to the orientation. Also he constantly evaluates the environment the team is in, and creatively adopts the most adaptive way of marching. He reviews the status of team members from time to time. Then he gives proper instructions to individuals, or formulates policies, or changes the deployment of human resources, so that team members can handle their work capably and effectively. He makes and reinforces important decisions, but also he communicates with his men and listens. He may make mistakes himself but he never gives up learning from experience. All leaders do things like this, why shouldn’t an architect be the same?
- Uncategorized | Time: 11:01 am (UTC+8)


Good points. Actually I think that support the spiral model for software development (http://en.wikipedia.org/wiki/Spiral_model), aginst your top-down/bottom-up model in the final project.
It is very bad that back in China, for EE people, we didn’t learn much on software. It is a big loophole in the curriculum and should be fixed as soon as possible.
Finally, recommend the book “Design Pattern” again. It will help you to be a better architect
Comment by Da — August 29, 2006 @ 8:16 pm