Home > Architect, Architecture > Architect: Solutions and Leadership

Architect: Solutions and Leadership


One of the teams I know had some problem with file storage implementation in their project. The problem was very clear: they need some kind of algorithm that helps the user to upload and store some files in a physical location in the server. However there are few constraints in this requirement. After landing in the screen the user may choose to modify the screen and therefore he comes to EDIT mode. Only in this mode the user will be able to upload a file – a file as new one or a file that replaces the old one. The user may cancel the EDIT mode and go back to VIEW mode. Here comes the problem. When the user clicks cancel and comes back to VIEW mode, the new files uploaded by him during this short session VIEW-EDIT-VIEW must be deleted from the server. The files he replaced must be reverted back.

The developers had used datasets to persist data (files) between postbacks. So when the user clicks cancel the un-committed data can easily be discarded. They have used cache too. Cache behaves weirdly at times. For this kind of storage one must never use cache. Cache must be used to cache the application data and not user specific data. Since this is out of our topic we will deal with this later.

Since the cache started to behave weirdly, as a quick solution, one of them had changed the implementation from Cache to Session. At least session does not behave weirdly. This solution clearly would downgrade performance if the number of user increases and each one of them tries to upload file and might lead to crash.

Of course developers knew this. So after that test release, the developers called on a meeting with their architect and asked for a new solution. The architect was very furious at first when he heared that the developers had used Session to store the file. Then he proposed a solution.

Just store the file name in session and save the actual file only when the user clicks SAVE when he is in EDIT mode. Use javascript to read the file from the client machine. Doh! And when the developers asked for another solution; the architect didn’t have one. He was saying that is the only possible way.

Javascript requires special permission to read the file from client machine. Even though this application is only for intranet users, still this would require a change in user browser settting which will subsequently create a hole in company’s security policy. Developers rejected the solution just like that.

Here the architect said “As far as I know that is the only possible way”. For every problem in the world there are surely more than one solution.If the architect does not know other solutions then he must look for them.

An architect is a leader. He must earn the respect of his fellow programmers. If he didn’t earn the respect, the developers will lose confidence in him and will continuously reject his solutions. When the developers reject architect’s solution then it is a career-limiting thing not for the programmers but for the architect. The architect has to sell his ideas – to the development team and to other stake holders or he must give “sellable” ideas.

Advertisements
Categories: Architect, Architecture
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: