Code review is important for the quality of a software product. It used to be a meeting activity where a small group of engineers walk through changes and provide the author feedbacks. This is highly effective but not flexible enough, especially when there are frequent code changes.
Having read my articles on vSphere APIs and software designs, you may feel a bit bored. Today I will write something different and generic: how to simplify things.
By nature, the world is complicated as it should be, and will remain so or even more forever. Simplification does not change that fact, but your perception about the world. Unless you are writing research papers, you want to simplify things you work on.
Last November I posted several jobs from our software team, they were all filled. As VCE grows rapidly at a runrate of $800M at the end of last year, we are now having more jobs. In my group, I have two development jobs opened. Should you be interested or know of someone who may be interested, please let me know. My VCE email account is like <firstname>.<lastname>@vce.com, and my twitter is here. Besides these two, there are many other jobs at VCE covering almost all technical aspects. I can help refer you to our recruiters directly as well.
If you are familiar with agile processes, it’s most likely you also know of, or even practice, test driven development (TDD). Several years ago I read the book Test-Driven Development by Kent Beck, and found the idea pretty interesting. After that, I rarely found myself using or even thinking about this methodology. I am not saying that test driven development does not make sense, but that it is not the approach working for me, and maybe some others as well.
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 (email@example.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.
- A static methods prevents you from using instance variables for passing information around, for example, as parameters to or as result from it. As a general rule, you should not define an instance variable if it’s not an intrinsic property of a class or type. It may seem obvious,
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:
When a developer learns a new programming language or API, the first thing is probably to try out a HelloWorld sample. As said, real programmers don’t read documents. Although I don’t fully agree on that, it has some truth in it.
In my own experiences, I normally continue with other samples after HelloWorld one. When something is not quite clear, I check out the API reference or read some tutorials. Anyway, I am not telling you how to learn a new language or API, but trying to make a point here on the importance of code samples for the developers. In my opinion, samples are the most effective way to empower your users.
I think you would agree with me, there are too many bad samples. Here are some typical symptoms:
- Too much boilerplate code to a point that the code illustrating the API usage got buried. Typical boilerplate code includes extensive exception handling, GUI, logging, etc. Some samples even have a common library that could confuse your users totally.
- Too many API calls in one sample. You may need several APIs for a use case, but don’t aim one sample for multiple use cases.
- Too much object oriented. Object oriented programming is a best practice for application development. But it could confuse your developers sometimes.
- Dependencies on other APIs. To run the sample, your users need to install other libraries which may or may not need extra configuration or tuning. To understand the sample, users need to understand additional APIs. Extra burden, really!
- Of course, typical bad smells of programming which are not unique for samples. For example, bad naming, unnecessary global variables, using object attributes for passing values between methods, etc.
Now, how you can develop great samples? Besides the best practices writing great applications, you want to follow the following guidelines:
IBM DeveloperWorks recently published the result of a survey of 2000 IT professionals excluding IBM employees. The key findings are:
- Cloud Computing to overtake on-premise computing. For the question, “how do you rate the potential for cloud computing to overtake on-premise computing as the primary way organizations acquire IT by 2015?” 30.4% said likely, 21.6% most likely, and 13.6% definitely.
- Mobile application development to dominate. 55% of respondents see app development on mobile grows than other platforms in 5 years.
- IT professionals need, but often lack, industry-specific knowledge. 28.3% thought moderately important, 45.6% very important, and 15.9% extremely important. This is not an IT trend per se, but represents the demands for IT professionals.
The first two findings are mentioned and somewhat confirmed by another survey by Forrest and Dr. Dobbs, which is more developer oriented:
If you attended last year’s VMworld keynote by Steve Herrod or watched the online broadcasting, you may still recall the code2cloud.com website (see the top banner here). That was a very simple Web application meant for the keynote attendees to submit names and email addresses to win a chance to go to the backstage with the Foreigner band. The website was hosted at Terramark vCloud and continued to run for about one month afterward.
Following my prediction in a previous blog, Google just made the tools from its recently acquired Instantiations free to all developers/testers. Besides goodwills to the developer community, this move makes GWT a serious competitor to Adobe Flex, Microsoft Silverlight for Rich Internet Applications.
You can give these tools a try while developing and testing Web applications, or Java GUI applications:
- GWT Designer
“a powerful set of Eclipse-based development tools that enables Java developers to quickly create Ajax web applications using the Google Web Toolkit (GWT).”
I attended Eclipse Day at Google headquarter today. It’s a great event packed with several great talks.
Mobile application is for sure a hot topic these days. There were several talks on mobile application development like Android Tools for Eclipse by Xavier Ducrohet from Google, Eclipse Sequoyah for Android App Developers by Eric Cloninger from Motorola, Tools for Mobile Web by Paul Beusterien from Symbian Foundation, and EMF for GWT by Ed Merks from Cloudsmith.
While sitting in the talk on Instantiations Eclipse Tools, I learned that Google bought the company 3 weeks ago. I expect Google will soon make WindowsBuilder, a famous WYSIWYG GUI authoring tool, free for GWT users, therefore further drive the adoption of GWT in competition with Flex, SilverLight.