8.30
code
course
gym
course
code
gym
Cat:
- Uncategorized | Time: 12:39 am (UTC+8) No Comments »
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. 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?
