Monday, July 30, 2012

on site architect for a construction project

Imagining you are the onsite architect for a construction project.
When you found the construction company cutting cost by lower the mixing ratio for the concrete or choosing lower cost material or lower the usage of certain material, or reduce the waiting time for the concrete to dry, but you realize that you do not have veto power and all you can do is “lead by influence”, will you be comfortable to be responsible for the quality of the building ?



Tuesday, July 24, 2012

achieve your goal by letting it go

In Christianity, there is something like "seek His glory; the rest will be given to you". I would like to parallel phrase‎ it in software development "Seek quality, the rest will be given to you". those who sacrifice quality for the interest of time will lose both.  However, good quality does not necessarily mean cost more time, or over engineering. It means all of design decisions, architectural decisions or programming decisions are well thought for and based of requirements or best practices.

Good project management + Good architectural design + good engineering process = good software product.  Once a good architectural design is in place, mindset of the project management is the key to its success.

Thursday, July 19, 2012

The chef determines how good the banquet can be

A chef would not present a dish if he is not comfort with the cooking of the dish;
An architect would not include an architectural structure in his design if he is not knowledgeable on the architectural structure;
A project manager would not endorse any SDLC process, if he is not comfortable
A programmer would not adventure with certain programming technic if he is not familiar with the technic.


Unless you are in the driver seat, you only can influence the decision making; you are not the decision maker no matter how good you are in these technical areas.     




Wednesday, July 18, 2012

Tailor Ed and his 3 sons - Continue

6 months passed. 3 brother’s busy working on the suit. They busy designing the tailor machine, using the tailor machine, busy sewing using the sewing machine….  The team spent lots of late nights and working weekends.


One day, I chat with Bobby about his project; I was told the new suit is “same crap different suit”. “We left the sewing team mostly the same in terms of skill, training, communication, etc. and leadership hasn't gotten any wiser, so the output shouldn't be expected to be much better than before”. Bobby agreed with me on the statement “if we continue let the project go like that, we would end up at the same boat as we had” by saying “yep, that's where we're headed.“


Link






Naming is the source of most confusion

If you take the source code of working software and rename all the variables, methods, properties, classes to something meaningless (something like A1, A2, B1 B2 and so on) and rebuild it, you will find it works as it did before. To the compiler, the naming makes no difference.


However, to programmers it makes a huge different. It would be a nightmare to work on the source code with meaningless identifies.  


Martin Fowler was quoted in book of “Microsoft .NET: Architecting Applications for the Enterprise”, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” I would like to follow-up by saying “when it comes to readability of the code, naming is the source of most confusion and only the program that can be understood by human can be accepted as commercial software.”

Monday, July 16, 2012

Make handymen to build a house

A home builder is hiring some more workers for his new construction project. A few handymen, applied for the job.
When he interviews the candidates, he asks the following questions:


1)      Do you know how to use hammer?
2)      Do you know how to use saw?
3)      Do you know how to use measurement tape?
4)      Do you know how to use power tools?


When he gets positive answers, he hired them.


Not long after the project started, he realized the project is not doing well, the wall is not straight, and the floor is not level…


A software company is hiring some software programmers for an enterprise commercial system. A few non-professional programmers came to apply for the job.


When he interviews the candidates, he asks the following questions:
1)      Do you know how to write VB.Net program?
2)      Do you know how to write SQL/Server Stored procedure?
3)      Have you created sql server tables and views?


When it gets positive answers, the company hired them.


Not long after the project started, he realized the project is not doing well, the design of the system is convoluted, the code is difficult to read and full of bugs, when one bug is fixed 3 other bugs are produced, the performance of the system is terrible, the project is way behind schedule…


The commonality between above 2 scenarios is the decision maker mistakenly confused tools over skills.


Lots of people know how to use a specific language write, but not all of them can write beautiful novel or a scientific paper; lots of people know how to play piano, but not all of them can play beautiful music like pianist ; lots of people know how to use these tools a professional home builder uses, but not all of them have the skills to build a single family house; lots of people knows how to write .Net code,  and design database tables, but not all of them are qualify to design / develop commercial standard enterprise software system. It is the skillset differentiate professionals from non-professionals not the tool.










Thursday, July 12, 2012

when you have a hammer in your hand, everything looks like nail to you

A few years ago, when I joined a company as the Application Development Manager, I found some specific technologies were widely used there. “Open query from SQL server to access Oracle database data” is a typical case.  They use open query in SQL/Sever to update, insert and of course, get data in Oracle database. In the way, this is the standard way for them to access Oracle database, even when there is no need to integrate data from SQL/Server database.


First of all, it is difficult to maintain, when you issue a select statement in SQL/Server, it is hard to imagine that in fact you are updating some data in Oracle.
Secondly, it created some point of failure unnecessarily. If SQL Server is dead, your application will not be available, even if there is no need to access SQL/Server data.
Thirdly, the power of PL/SQL is not unleashed.
Finally, the performance of the application is comprised. All data need to go through 2 hops back and forth.


With that, I started to implement a new architecture for these applications.


With the new architecture, I had stored procedures in the form of packages created directly in Oracle database and had a DAO Layer developed to access Oracle database calling these stored procedures via Database Application Block.


It was a big success. Slowly, this new architecture had been accepted as a standard way of accessing Oracle database. “Open Query” from via SQL/Server database been slowly faced out…


One day, I had lunch with one of the developers.  During the lunch, when we talk about technologies, he said “Peter, when you have a hammer in your hand, everything looks like nail to you.”


Yes, that’s it! If in your tool box, hammer is the only tool you have, you will try to use it as long as it works. it does not matter if hammer is the best tool for the job or not.

As an architect, in order to design a system with all best practices, you need to enrich your tool box. First you need to know all kind of tools available in the market well, and then you need to know when to use what tool. Use a specific tool for the sake of using it is one of the infamous antipatterns. Use a specific tool because that is the only tool you are comfort with is equally bad.