Sunday, August 30, 2009

Architectural Agreement

Every software architect/engineer should know and understand you can't have it all. Whatever your stakeholder, manager says that, "we need high speed, high performance, more usability, more flexible, more secure application." don't accept. There is no application which has all.
As a software engineer or architecture, you should really understand your customer's needs. If customer demands a 100 meter length truck with features like carrying 500 tons and high speed. It's almost impossible. Think in one second, if it's possible, can you imagine cost and effectiveness and time which is required to finish. No doubt, it would be failure project.


I will tell you a true story in history. There is a war between Sweden and Poland in 1620. The king of Sweeden wanted to build a ship called the Vasa. Because, this was is really costly war and he wanted to end quickly. But the ship was not an ordinary ship. It was to be more than 200 feet long, have the ability to transport 300 troops safely across the waters into Poland and carry 64 guns on two gun on decks. Time was of the essence and money was limited. The ship architect was not experienced to build this kind of big ship. He never designed before. But he accepted this task. After finishing to build the ship, vasa, the big day came. The ship sailed into the harbor and immediately sank less than 2km into her maiden voyage.

The ship architect tried to fulfill all of the king's requirements. Finally, the project was failure.

Ship architect behavior is similar to software architect-engineer. As a software leader, engineer or architect, you should avoid accept all requirements. You may think, "i have to satisfy my customer." That's correct. But if you accept all wishes, you creates unstable application it would be failure project after releasing. You should warn your customer, and try to understand what customer really needs.

Friday, August 14, 2009

AJAX - Asynchronous JavaScript and XML

I won't explain what is ajax. I'm confused nowadays. Keep reading, why i'm puzzled.

Ajax stands for "Asynchronous JavaScript and XML". As you see, you retrieve data from server using JavaScript asynchronously, the data returned from server is XML.

What if i retrieve data formed as JSON, can i say that i use Ajax?

Thursday, August 13, 2009

Define Terms and Rules

Think about that, a new project will be started or a new development team will be created. No mather what will happen. If you are leader of team or project, you should define some terms and rules "with team members". One person shouldn't decide every details.

Each developer, engineer, designer and project manager has own style. It's so common, there is no wrong with that. Each person involved in any project has different skills, experiences. If they are free to apply their own style in same project, ultimately, it will be fail, no doubt. That's the big question how do we prevent unavoidable failure? Keep reading.



Team members including manager, leader, customers anyone who is in project has to talk same "project language". Communication between team members is really more important than choosing technology to be used. If there is a lack communication, there are lots of missunderstanding and it causes big issues which are technical, cost, deadline etc. In my opinion communication is a key pillar of project. For good communication, some terms and rules should be defined before starting project. Look at these example:

Example 1:
There is an object to contains record, stored procedure, functions etc. inside it. In MS SQL enviroment it's called "database" while in MySQL it's called "schema".

Example 2:
If one object is not initialized in .NET Enviroment, developer who uses vb.net says, "nothing", while developer who uses C# says "null". VB.NET developers say "function", C# developers say "method".

You may think they are unimportant points, but misunderstanding may cause big issues.

Also, some technical rules should be written, such as "naming convention". In same project, same naming convention rules should be used. Hungarian, pascal, camel case etc. . More than one naming convention can be used in same project. For instance, hungarian convention can be used for local variables, for public variables pascal case can be used or camel case can be used for parameters.

Another example can be "words" written in project proposal or concept. These terms written below can be identified:

  • Customer ; which person is called customer?
  • User; which person is called user?
  • Name,-surname or first name-last name; which one is choosen?
  • Postcode or zipcode; which one is used?
  • Which term is used "authorization" or "roles"?
These list can be expanded in respect of your needs. It's not possible to identify all items in one meeting session. It can be boring. During development process, it's always possible to define these terms which are not defined.