According to the page, there are disadvantages of RPC style architecture (with my updates and remark):

• The major disadvantage is that there’s little room for code reuse. This is because the code for marshaling and unmarshaling, and the code for network communication is buried in the client and server applications. (Generally solved by standard based interoperability)
• RPC isn’t language independent, and the client and the server must employ the same programming language. (See above)
• There’s also very tight coupling between the applications. The reason is that because the calls are synchronous, the client application must wait for the server to complete the procedure before it can proceed further. Also, it’s possible to overcome this problem by using multithreading; however, it introduces another level of programming complexity that has inherent risks in terms of garbage collection.
• The integration of the client and server is point to point and, therefore, isn’t suitable when a number of applications need to be integrated.
• RPC is also not suitable if a large number of remote calls are involved. This is because of the synchronous nature of the call, which doesn’t allow the client to proceed before the server completes its work .
• (RPC pretends to be just like local calls, which can fool developers if they ignore the differences in performance and availability)

• RPC encapsulate the functionalities of legacy systems and existing complex logic
• RPC call is very easy to make – just like other procedure calls (which is a leaky abstraction and should be a disadvantage)

The other excellent quote from the same SOA patterns book -

you need to plan for SOA like highway intersections are planned; detours need to be created to enable business to continue while the new system is being developed

Excellent advice from people in the trench …

Innovation at Google

Every company/human has innovation potential. How to translate ‘innovation potential’ to reality?

Top/Down vs. Entrepreneur Innovation

Extreme ideas to facilitate innovation

http://www.pretotyping.org/the-pretotyping-manifesto-1

The Pretotyping Manifesto*

• innovators beat ideas
• pretotypes beat productypes
• building beats talking
• simplicity beats features
• now beats later
• commitment beats committees
• data beats opinions
• don’t finish what you’ve started
• failure is an option
• scarcity bring clarity
• the more the messier
• reinvent the wheel
• play with fire

Idea may generate 1B once realized, but idea alone does not worth anything.

Edison – try on one idea, test, test, test, .. try next idea

The real value is in innovators.

Ideas live in thought-land. People can pile up ideas on top of other ideas. Ideas in thought-land worth very little.

• WebVan idea (false positive, everybody says yes, but fails to see the problem)
• Twitter (false negative, everybody says meh, but turns out to be huge win)
• Window CE (Group think, because BillG says so)

The focus should be ‘building the right IT, instead of building IT right’

Example of pretotyping (how to validate idea cheaply and fail soon)

http://media.computer.org/sponsored/extras/cn/0411/DemocraticInnovationAtGoogleSlides.pdf

http://patrickcopeland.org/papers/EntrepreneurialInnovationGoogle.pdf

That is the culture of Ruby on Rails. I am not talking about the technology of Ruby/Rails, I am talking about the culture of Ruby/Rails community. Of course the culture is built upon the technology, but another important factor is the people in the community.

Let’s start with the experience of the technology. Stuffs like this post just make me so very happy. It is like my son figures out a way to create Lego machine gun. It is so awesome. I don’t know how this experience can be possible in .NET and the learning process is actually not very easy, but the sheer joy of finally figure it out and make it work is just pure heavenly.

And the fact that the above blog post exists is the ‘culture’ part of the equation.

I was listening to ‘Delivering Happiness’ again. In the book, Tony talked about culture and why it is so important for business. I also read the blog post about what ASP.NET MVC can learn from Rails. Then, I realized it is culture that makes Rails more exciting for techies.

Yes, ASP.NET MVC can add dynamic/meta programming and all the bells and whistles, but techies still will feel hesitate to come and built on it. You know, it might be a great platform, easy to work with, … etc, but if no other techies are using it, not many techies will start using it. Even if some techies start using it, if ‘any’ politics or corporate stuff try to interfere with the direction, techies will just pack and leave.

So, more techie-exciting and more awesome community culture around, that is what I think make Ruby/Rails so popular among techies …

Physical environment will affect your body and then affect your effectiveness in thinking. Here are the things I do to help me feel right to work long hours in front of computer.

- Comfortable Chairs

- Big Table

- Big Display

- Good Keyboard (I use Microsoft Ergonomic keyboard)

- Good Mouse (I use the wow-pen for natural postion)

- Learn to use keyboard as much as you can (navigation, shell command, VIM, … etc)

- Drink a lot of water

- Regular Exercise

So, I bought a Mac Book Pro last year. It’s an expensive machine. But, I know I will not really know Ruby on Rails if I don’t make the plunge. I could have used Linux, but I know I will have better experience with Mac than having to struggle through the compatibility problems with running Linux on PC. Anyway, I got a Mac, running Windows as VM if I need to do any Windows work.

Then I started learning Linux command. That is where the drop of productivity start getting me. I am a proficient PC user. I can do things on PC that I have no idea how to do in terminal. There is no other way. You just have to start from the basics, learning the basic commands like ‘ls’, ‘cd’, ‘cp’ and so on. Google is your best friend. Chances are you are not the only person with the same problem - you just have to google to find it.

Then I started learning VIM. I am reasonably good at typing and I enjoy Resharper with keyboard shortcuts. By switching to VIM, I have to start learning all the modes and commands. These video tutorials helped me a lot during my VIM learning.

In summary, the biggest hurdle I have to work out during the switch is the ‘perceived’ lost of productivity. For me, I choose to do this alone, so it is harder than having a local expert that can help you out along the way. I don’t have a person to validate my learning. I have to accept the fact that I might go dard for a while. Especially, the more proficient you are with PC, the greater the productivity loss will be. In the end, only time and faith can help you get through the hurdle.

We all have fear when we face uncertainty and we have doubts about the possibility of success – especially when the stake is high and we dread the possible bad outcome but cannot see the benefit of taking the challenge.

Software developers have fears too. They are afraid of losing job, failed projects, bad reputation among fellow developers, blame from team members, … etc. Fear makes us behave cautiously. Unfortunately, fear also makes us not to try.

I had a chance discussing with another team member about the possibility of refactoring an existing code base into something that I think will be better for the future. First of all, the discussion quickly switched to the debate of whether the new design will be better. Unfortunately, this is a very fussy and never settled debate among software developers. Finally, we sort of agreed that the new design will be better. So then, we started discussing whether the new design’s benefit will outweigh the added cost of rewroking on some code. Again, another area of contention. Also, the discussion involved the discussion of time-value. Should we wait until project is done and come back to rework on the foundation, or should we rework not and run the risk of not finishing the project on time.

Now, this kind of debate or discussion is never scientific nor logical. Just as that you cannot measure productivity, you cannot measure the value of a sound design too. The rule of thumb is to put ‘Quality First.’ But people also seem to agree that some kind of trade-off or technical debt is unavoidable.

The other thing that is always playing an important role is the emotional factor. We don’t like change because of the FUD involved in any change. It really takes years of experience to make one feel comfortable to see challenges beyond FUD. It also take strong leadership (not only from manager but also from peers) to help the team overcome the emotional factor.

In my experience, I think the emotional factor plays the more important role than the logical factors.

So, system’s requirements, which are values to the users and stakeholders, can be expressed as system’s list of features.

So far so good. System’s users and stakeholders have a set of values (things that they think will make them happy), and they express it as requirements of the system. And, software developers translate these requirements and values into features that we want to provide in the system.

The other thing I have been doing is reading Tony Hsieh’s book of Delivering Happiness. In a small corner of his book when Tony talk about his encounter with Amazon’s Jeff Bezos, he talked about the concept of ‘people are really bad at predicting what will make us happy in the future’. We like to think things like wining the lottery, entering into a top college, or getting a dream job will make us happy for a very long time. But, in reality, the happiness associated with these things can come and go very fast.

So, go back to software development; if we are so bad at predicting what will make us happy, how valid can our requirements be? We see that VERY often. Managers come to software developers asking for a website thinking that having a website can bring in more sales and make them happy. Executives come to BI developers asking for a data warehouse thinking that having intelligence at the finger tip will enable them to find inefficiencies and make their future decisions much better. The reality? Business users are really bad at predicting what will make them happy. That’s why many business system features end up not being used at all.

This make me also think of an interesting debate between Kent Beck (XP and TDD father) and Alan Cooper (About Face and UI design guru). The central theme of their topic is who should determine what should be built. In Kent’s argument, customer should be the one who is making the call, driving the direction of the system. Software developers take advantage of the fact that software is soft, so they build the system as fast and as flexible as possible, and allow customer to change the direction easily without too much penalty. From Alan’s point of view, customers are so bad at knowing what they want, software developers/designers should take more active role in shaping the direction of the system and make sure the design is RIGHT. We want the design to be right because the cost of wrong design is very high, as illustrated in the six-part serious of videos How Buildings Learn.

So, I have been thinking about these things. How do we as software developers (experts in developing software to address business needs) know that we are building the right set of features? Even we ask the customers, how can we make sure they are able to predict what will make them happy? Can we challenge their predictions? Should we challenge their predictions?

• when facing a new code, software or hardware, no one is going to read the documentation
• when you got stuck in even the simplest problem, every one’s first reaction is asking where the documentation is
• no matter how good the documentation is, no one really fully satisfied by the documentation
• programmers don’t like to write documentation
• programmers likes to complain about not having enough documentation
• most of the time, the comments or documentation are just not correct again
• the only way to know how an application behaves is by looking at code
• all documentation are only valid for a specific configuration of software in the past

So

• don’t waste your time complaining about not having documentation
• don’t waste your energy complaining about how wrong the documentation is
• when reading documentation, always assume it might be wrong
• be really good at writing very readable code
• be really good at reading code

Also, read Working Effectively with Legacy Code .

If you have not read the book, here is an excellent summary.

During the re-reading and thinking about the story in the book, couple of thoughts kept brewing in my head about the application of the model introduced in the book. So, I am writing this to jot down my thoughts for my own reference.

OK here is the famous model (stolen from http://sequimur.com/banditsnomore/wp-content/uploads/2007/06/fivedysfunctions.gif)

The basic idea is that, from building trust, then having healthy conflict, then commitment, then accountability, the team can eventually pay attention to result and becomes a very effective team.

Now my thoughts:

• The model does not take into account the external political constraints of the team. What if the board did not trust the executive team and wanted to pursuit with the Green Banana’s deal to buy Decision Tech? What if Mikey eventually did not resign, and the board did not like Katherine’s action of letting Mikey go?A lot of real world teams face situations that require them not only fight with the goals but with some external forces that is beyond the control of the team. What if a software team that is under the instruction to work on a death march project? How is the a functional/effective team’s way to resolve this kind of situation.

• It is understandable that the book author wants us to believe that any team can achieve the same result. But, what if the team’s leader is not a great communicator like Katherine? What if the CEO is a dictator and you are a member of the executive team, how do you make the team an effective one?

• The idea of ‘First Team’ does not work exactly the same for teams that are not at the executive level. What if you are a middle manager, what is your ‘First Team’? Should it be your manager fellows? Then how about your supervisor (department head)? What is his/her first team? What if there are conflicts of priorities between these two teams?

• What if Mikey did not resign? What should Katherine do? How do you deal with team members that are hindrance to team’s effectiveness?

These are just thoughts that make me wonder. I know this book is just a fable that is used to illustrate a model that is particularly suitable for executive teams.  And to be honest, this is a very very good book. But to use it in a general and more commonly struggling team, I think we have more to learn than just applying this model.

Have you read the book? Do yo have any thoughts?