Mainly: You do not want to pick the tool that’s hot this year.
(picture from blog above)
The reason is that choosing this year’s hot framework is an unnecessary leap of faith that places your project at risk. What happens if you choose wrong? You’ll watch your application (more...)
I’ve just been troubleshooting an ADF application that ran fine on one environment and not on another. After some searching, I discovered that a script had not been run on one of the environments so the database was different.
That reminded me of a simple database check that I often include in my applications: I simply calculate a hash value of all tables and views with an SQL statement like this:
Oracle has just updated their ADF Statement of Direction, announcing that ADF 12.2.1 will be out in 2015. Here is what they are promising for this release:
The Next Version of Oracle ADF
Oracle is planning to deliver the next version of Oracle ADF – 12.2.1 – as part of the next release of Oracle Fusion Middleware 12.2.1 in 2015. Some of the focus areas for this version include:
I often train experienced developers in new tools, and I’ve found that most underestimate what they can do – their actual skill level is higher than their own perceived skill level.
This is different from new developers, who tend to overestimate their skills.
The reason this happens to most experienced people is the “loss of control” feeling overcomes the feeling of accomplishment. If you are very skilled with one tool, you are acutely aware that (more...)
When advising customers on ADF projects, I often find development environments where many or all developers are working against the same database. That introduces a hard dependency between different parts of the project – if one developer deploys a defective PL/SQL package to the database, nobody else can run the application.
This approach made sense back when hardware was expensive and databases had to be managed by high priests in glass-walled, climate-controlled rooms. Today, you (more...)
Last week’s Technology That Fits newsletter (sign up here) stimulated some interesting discussions. I showed the following graphic:
Everybody agreed that projects that choose good tools for good reasons are good, and projects that choose bad tools for bad reasons are bad. But some disagreed on Learning and Lucky categories above.
I call projects that choose good tools for bad reasons “lucky”. They are CMMI level 1 – sometimes they succeed, sometimes they fail, and they (more...)
Too many programmers think that their job is to write code. It isn’t.
The job of the programmer is to help the business solve a problem using appropriate technology for the task at hand. The programmer knows (or should know) the available tools and will hopefully select the right one for the task.
Unfortunately, too many programmers suffer from framework-phobia and don’t trust any code they have not written themselves. That takes more time, causes more (more...)
At Oracle OpenWorld, there was a lot of Oracle ADF material. I presented on Oracle ADF Bindings as part of the well-attended ADF track on User Group Sunday, and Oracle also gave some very interesting presentations on new and coming features in ADF. For example there is now an ADF component that you can use to visualize any network of nodes and edges.
But what struck me more was the fact that when Oracle buys (more...)
Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
My rating: 5 of 5 stars
An inspiring book from one of the original creators of Scrum. Full of anecdotes about how Scrum saved projects and can be used outside the software industry. Its main purpose is to motivate you to get started using Scrum, but it does contain enough methodology to actually allow you to use the methodology. It (more...)
Your applications contain 20-30% dead code that is never executed. Not just commented-out code that programmers have left in “just in case”, but routines never called, branches never executed and screens never displayed.
The cost of software maintenance depends on the size of the code base, but systems with dead code are more expensive to maintain. This is because every time a developer comes across a dead piece of code, he becomes unsure: “I wonder (more...)