This month Eclipse turns 10 years old. Ten years ago, IBM donated the initial Eclipse Java IDE, which was then estimated $40M, to Eclipse Foundation. It has since grown to 273 open source projects and $800M portfolio today. Quite an achievement by any standard!
This news release summarizes some of the key accomplishments:
I think it’s going to be the longest single post I have ever done because we have quite a few openings in our VCE team. We are building our software capability for what I called turnkey software stack for cloud computing on Vblock.
The following are just three openings we want to fill immediately: Sr. GUI Engineer, Sr. Build/Automation Engineer, and Sr. Software Development Manager (update: Principal Solutions Engineer). We also have more software engineer and QA positions whose descriptions are not listed here. If you are interested in any position, please feel free to email me (firstname.lastname@vce.com).
While everyone can learn and practice programming, it’s hard to find a good software engineer, even harder to find a great one. My definition of a great software engineer is someone who can solve real world problems with software expertise, not someone who can only write code, or someone who can only talk about architecture on paper, or someone who complicates real world problems.
Yes, we can all learn programming related concepts, languages, tools, and etc. But how to use them effectively on a business problem is really a test stone for anyone. It’s important to study textbooks, learn from others; even more so to
In object-oriented programming, static methods are the methods that are defined with static keyword. They don’t have access to non-static instance variables. This very limitation can be an easy cure for many programming pitfalls I’ve seen over the years.
In business world, we hear frequently the word “focus.” To achieve business goals, for example, deliver software, it’s absolutely necessary to focus on the projects and priorities. Teams that focus on execution typically perform better than others that don’t.
It’s, however, not a good idea to focus all the time. In fact, human beings have limited period of attention. Passing that period hurts one’s effectiveness – one explanation, perhaps, for why long working hours don’t deliver proportional results – not to mention the detrimental effects on one’s health.
Moreover, focusing really narrows
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
It has become a conventional wisdom in software development that you should NOT re-invent a new wheel – reuse an existing one instead. There are many compelling cases in which re-inventing wheels had caused catastrophic failures as described in Joel’s article Things You Shoud Never Do (Great article BTW). One famous example there was the NetScape’s loss to Microsoft in the browser war more than a decade ago.
Nothing is absolute in software however. You can find opposite cases like Microsoft’s successful re-inventing Windows from Window 95 to Windows XP. Actually in a longer term, you cannot stick with a wheel forever; otherwise we are still using wooden wheels in the pre-industrial age. Same is true for software.
I think the question is really not whether to invent a new wheel, but when. In other words,
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
Today I read a commentary of latest MSDN magazine by David Platt who is famous for his book why software sucks. In his commentary titled Never, Never Land, he compared our software development to the medical industry on malpractices, and drew the following conclusion:
Certain occurrences are never, never, acceptable. We need to define these events, publicize them and educate developers about what they are and how to avoid them.
In IT world, we’ve heard many best practices. I have personally contributed many of them in using VMware vSphere APIs, cloud application development, and writing sample code. For consistency with best practices, I call these never land “never practices.” If you search the Internet with “never practice” today, you won’t get any but this post at the top. But we do need more never practices. In the article, David offered one general never: never lose users’ data, and he asked readers to share more.
This is yet another post based on my notes taken at LISA 2010 conference. The talk is The 10 commandments in release engineering by Dinah McNutt from Google. Dinah did a great job in summarizing the basics of release engineering therefore it’s worthwhile to compile my note and share it here.
Note that although typical release engineering does not produce virtual appliances, the basic principles are the same. You will find these basics helpful as well.
Release engineering is a critical part of software engineering and should be treated as products in their own rights. But often there is disconnect between development writing the code and the system administrator who installs it. Release process is usually an afterthought.
Typical Release Process
The following steps are executed during a release run:
English
Recent Comments