In the world of VMware, “view” is an overloaded term which is used in desktop, vSphere APIs, and PowerCLI. Outside VMware, you can also find it in MVC architecture, which basically divides a software system into model, view, and controller. This separation has become a basic programming paradigm in modern software design and development.
While we in software industry debating which process to adopt for development, I found something in manufacturing very intriguing. On a recent article of Business Week The Case for Making It in the USA, it mentioned a GE factory in South Carolina where aircraft jet engines are made. What struck me is the following:
“Teams can adjust the line operation as they see fit to remove bottlenecks and maximize productivity. Recently, two teams came up with different ways to speed up the washing of turbine blades. The plant leader, rather than picking one way as the winner, approved buying equipment for each team to wash the blades its own way.“
I would say it’s pretty
Communication is always important in any teamwork environment. This is especially true in software development where changes are constant. There are two levels of possible communications in software development: soft communication and hard communication. Let’s go over them one by one.
It happens among people, those who work on a software project. Two popular forms of soft communication are
If you are a software engineer, you may move from project to project over the time. How to quickly ramp up with a new project is always a challenge. The term “new” I use here does not mean that the project is new and you need to start from scratch, but that the project is new to you.
Although we all like to start from scratch, the reality is that 80% of engineers are actually doing maintenance works on existing projects: fixing bugs, adding new features, etc.
When you move to a new project, you have to
There have been long debates on whether object oriented is the future of programming. Repeating it over here doesn’t make it any clearer. As you can tell from my blog, I am an OO bigot because it can significantly improve productivity. If you are not convinced about OO benefit, you can look around those top programming languages mostly support OO these days.
By reviewing the whole software lifecycle, however, you will find a gap between requirements and OO programming today. While describing application requirements, a business user almost always describe them in a number of steps (procedural). It’s not realistic to expect requirements described in an OO way. While developing, programmers write and see classes and objects.
How to bridge the gap between the procedural requirements and object oriented programming? It basically boils down how to
While reading Who Says Elephants Can’t Dance by Lou Gerstner, the following paragraph caught my attention and made me think about it in the context of software development.
We started with a statement of principals. Why principals? Because I believe all high-performance companies are led and managed by principles, not by process. Decisions need to be made by leaders who understand the key drivers of success in the enterprise and then apply those principles to a given situation with practical wisdom, skill, and a sense of relevancy to the current environment.
Although managing a company and managing a software project are two different things, I believe above paragraph is perfectly true for software development as well. Let’s paraphrase it:
We started with a statement of principals. Why principals? Because I believe all high-performance software development teams are led and managed by principles, not by process. Decisions need to be made by leaders who understand the key drivers of success in the software development and then apply those principles to a given situation with practical wisdom, skill, and a sense of relevancy to the current project.
Sounds true? For your curiosity, the principles Mr. Gerstner wrote for IBM in 1993 were:
If you have a new hire, do you want him/her to push code into production system on the very first day? You may be OK with this sometimes. What if it’s a trading system with real money involved? More often than not, you come up with a different answer.
On Wednesday night, I attended a seminar organized by SDForum SAM SIG at LinkedIn headquarter. Pascal-Louis Perez and David Fortunato from Kaching.com engineering team gave a great talk on how they streamlined their software development process to the extent that they normally release 20 times a day to their production system. It’s quite a safe process that it’s OK for a new hire to push code on day one.
Today I read a blog by Martin Fowler, the author of the famous Refactoring: Improving the Design of Existing Code and other books. The blog explained why he declined the invitation to be part of the SEMAT (Software Engineering Method and Theory) initiative by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Ivar Jacobson is known for his contribution to the UML, together with Grady Booch and James Rumbaugh. All of them worked for Rational Software, now part of IBM, which I was part of from year 2000 to 2005.
Martin added his rationale for his declining:
…From here I got the distinct impression that the central thrust of the initiative is to create a software meta-method-kernel – essentially a set of common process elements for software developments that you can rigorously compose into a method for your own project.