I was laughing so hard. You have to see and hear this one.
I’ve been notified that I have been selected again as a db4o Most Valued Professional (dVP) awardee for the year 2009. I’m honored and proud to receive this recognition for the second time in a row. I want to thank db4o and the db4o community. There are only 12 dVP 2009 awardee’s in the USA. Thank you.
When Object Persistence is done right, there can be some great rewards in the areas of Productivity, Maintainability, and Cost Reduction. Some areas directly affect other areas. For example, if one can maintain an application fairly easily, this would result in a higher productivity. There are fine balances between these areas.
Productivity in software development can be measured in how fast a developer can complete a given work item with the assumption that the quality of the software is not compromised. How much time does it take to get things done without any compromises? Because most projects have a limited amount of time to complete, being productive impacts Cost Reduction to create and maintain the application as well as a better chance for future funding. Being productive should mean that one can get the work done and still deliver high quality software, with a high degree of reliability, and a fair amount of maintainability. Compromises in any one of these areas will result in loss of productivity either in the short-term or long-term of the product life-cycle.
The Object Persistence can be designed in such a way that the system is not locked into a particular database, for example. Because there is no database vendor lock-in, you can gain productivity by simply abstracting storage specific features. For example, if you decide to use an Object Relational Mapping Tool (ORM), you should let the ORM tool worry about creating and maintaining the database schemas for any database it supports based on your Object Model. This can buy you a tremendous amount of productivity because you are delegating this huge maintenance burden to the ORM tool.
- Productivity in software development can be gained through abstraction and automation.
Depending how Object Persistence is done, it usually allows for easier maintainability when requirements change. The fewer changes that need to be made to a system, the easier it is to maintain. Because of abstracting the object persistence, there is a high possibility that a system can be created that is easy to maintain. Because you no longer have to make changes to a database schema or data access layer, you can concentrate on making the changes usually only in one place: the object model and sometimes to the output such as the user interface or a new report
How many times have you read somebody else’s code and trying to figure out what the heck it is trying to do? Hard to read code, or Spaghetti code, is hard to maintain. In general, the fewer lines of code to maintain, the better. Because of the abstraction of the Object Persistence, much fewer lines of code are necessary. A simple method call such as the Save() method is all it’s needed. This makes the code much easier to read and to maintain.
By eliminating the database schema, eliminating a data access layer, and any data or value objects, we are eliminating several points of failures. By reducing point of failures, the system becomes immediately easier to maintain and more reliable.
The easier it is to maintain an application, the less time is required to train somebody else to learn it. Easy to understand code is easy to support no matter who will need to take over the code.
Maintainability is probably the biggest impact of an application throughout its lifetime much more so than the advantages of reusability in Object Orientation.
Studies have shown that in the lifetime of an application, 10% of the time is used to create the application, and 90% is used to maintain it until it is retired. If we can reduce the amount of time needed to maintain the application, we can reduce the amount of money spent to keep it alive. We are trying to work smarter using the right tools instead of harder using no tools or unnecessary procedures.
Being more productive has an immediate impact on cost. When a developer can implement a change quicker, the cost of maintaining an application is reduced. The time saved can be used for other duties or other projects. Many times, being more productive can allow for future projects to be approved vs. projects that won’t make the approval because the timelines would not permit to do so otherwise.
Today, labor cost is one of the most expensive liabilities a company can have. On the other hand, the workforce is also the most important asset a company has. There was a time where hardware was the most expensive part in an IT department. Hardware and tools are now extremely inexpensive today. It is mass produced and no longer a major factor in software development.
Purchasing third party component libraries can reduce the time and effort to complete an application. Some of these tools such as ORM tools can seem expensive initially, but; in the long term, you cannot afford not buying them. It is far more costly to write these components or tools on your own than to purchase them.
I’ve done it. After almost 18 years, I’ve switched from a PC to my new iMac OS X. I still can’t believe it. Over the years, I’ve always monitored Apple and how they went from a proprietary hardware system to the Intel platform with the new OS X.
As a professional, I’m running my .Net development on the iMac using VMWare under a Windows XP window. Works great. The main reason to actually go out and invest into an iMac was iPhone development for the new iPhone 3G using the COCOA Touch framework and XCode.
This is really exciting and I strongly believe that the iPhone from a development point of view has a huge potential. I’ve some personal projects I’m working on for the iPhone at the moment. When the first app is released in the AppStore, I will announce it here. I’ve not felt this excited since the late 80’s when I started writing my first shareware program ACZAR.