Not all documentation is created equal. Too much time is spent on formal design documents that are immediately outdated, and too little is spent on writing code comments.
Make sure your process requires and rewards good code comments. And make sure your architecture diagrams are kept up-to-date.
This illustration is from my weekly “Technology That Fits” newsletter – sign up here.
I’m often engaged with clients helping them respond to Requests for Proposals (RFPs), and there are way too many bad RFPs out there.
These bad RFPs not only specify what the customer actually needs, they also specify that the customer can possibly think he will ever need. Typical requirements are that the user must be able to add extra attributes to all entities, or that the user can dynamically change which attributes are mandatory, or that the user can freely configure the order in which fields appear on the screen.
These are not real requirements. But because the customer isn’t sure there will be money to maintain the system, he specifies a system with enough flexibility to ensure that he will never have to speak to a programmer again.
Unfortunately, meeting these requirements takes complex and expensive code, and the customer ends up paying for a lot of flexibility he will never need. Specify only what you need.
Based on my article in the latest issue of OTech Magazine, I am offering a free teleseminar (by phone or Skype) on how to live a happy, meaningful life in IT.
Programmers have a head start over the rest of humanity in leading happy, meaningful lives. If you have not yet reached complete enlightenment, I encourage you to sign up and invest 30 minutes listening to this call. It might improve your life.
The summer edition of OTech magazine has just been published – 111 pages packed with information from international Oracle technology experts.
Authors and topics are:
- Sten Vesterli – The Spiritual Programmer
- Scott Weseley – APEX 5.0 New Features
- Patrick Barel – Dear Patrick
- Emma Groomes & Crystal Walton – KScope 2014
- Anar Godjaev – How to protect your sensitive data using Oracle Data Vault
- Debra Lilley – Women in IT Initiative
- Lonneke Dikmans – What’s new in Oracle Case Management 12c?
- Mahir M Quluzade – Oracle Data Guard 12c: Cross platform transport non-CDB to PDB using RMAN Backup Sets
- Lucas Jellema – The Next Generation: Oracle SOA Suite 12c
- Ric Van Dyke – Adaptive Query Optimization: Will the real plan please stand up!
- Simon Haslam & Ronald van Luttikhuizen – Provisioning Using Chef and Puppet, Part II
- Kim Berg Hansen – External Data From Within
- Bertrand Drouvot – Graphing ASM Metrics
- Osama Mustafa Hussein – Upgrade OBIEE and Enable Mobile Designer
Download a copy right away!
Gartner has just released another iteration of their classic “Hype Cycles.” They are up to more than 100 different topics now, but one interesting graph is one is the one for Emerging Technologies.
Source: Gartner Hype Cycle for Emerging Technologies 2014
I want to comment on a couple of points from this graph:
- Internet of Things as peaking – completely agree. Everybody is talking about it but what do we have? An internet-connected smoke alarm.
- Big Data is moving down from the peak – disagree somewhat. Big Data is still mostly talk and very few success stories.
- Cloud Computing is in the Through of Disillusionment – I don’t agree on that one. Many organizations are successfully using cloud solutions today
The IT business is producing buzzwords at a dizzying rate and you need to be able to peer through the fog to find the solutions that make sense for you. Make sure your organization has someone keeping a lookout.
I’m not in favour of calling books a “must-read”, but if you want to get your own book commercially published, I have to say you must read Write the Perfect Book Proposal: 10 That Sold and Why, 2nd Edition.
The main force of this book is that it explains the publishing industry from the inside: What a publisher is looking for. The authors honestly explain what the publisher will and will not do, and that you should plan on marketing your book yourself because the publisher won’t.
It was a surprise to me that I have to build a whole business case with market analysis, competitors and marketing plan, but with the information in this book I feel confident I can write a good book proposal.
I’ll be going to the UKOUG Tech 14 conference in Liverpool in December to give one of my favorite presentations: “APEX or ADF? From Requirements to Tool Choice”. I’m also leading the Development Tools roundtable, which is always lively at the UKOUG conference. If you want to discuss your options as a developer in the Oracle world, UKOUG Tech 14 is the place to be.
APEX or ADF? From Requirements to Tool Choice
APEX or ADF? From Requirements to Tool Choice
Quick, how many different Web Service specifications are there?
- less than 20
- between 20 and 40
- more than 40
I was in doubt whether the answer would be 1) or 2) – after all, there is a lot of WS-* stuff. Turns out the answer is 3) – there are currently 50 web service specifications.
A technology with 50 specifications is unlearnable. The basics of web services is simple and useful, but the IT industry is now trying to address each and every one of the classical IT issues (security, transactions, manageability etc) through additional web service specifications.
This is a wrong path, because architects and customers now simply request the silver bullet of “web services” instead of thinking seriously about the integration requirements and producing a proper IT architecture. Whenever someone requests web services, ask “why?”
I was recently advising a transition project where a customer was switching support and maintenance supplier. This means that one organization must take over a system that has been maintained by another organization for a number of years.
A lot of information is lost in these transitions because knowledge of the problem domain has been accumulated in the heads of developers over many years. This loss cannot realistically be mitigated.
But sometimes, specific information about the technical implementation is also lost, and that should not be allowed to happen. If you are receiving code to maintain, you need to make sure that you can check the source code out of version control, make a cosmetic change and follow the build and deployment instructions to deploy a new version all the way to a pre-production environment.
I’ve never seen a transition where this was possible right away. Trust, but verify.
I’m currently estimating the effort for a piece of software. With 20 years of experience under my belt, I don’t find estimating hard any longer. But back when I started out, I was terrified whenever I was asked to provide an estimate.
In most organizations, too much of the estimating is art and too little is science. Experienced developers can produce good, realistic estimates, but these are often treated as individual efforts and no organizational learning takes place.
For every estimate, you should capture the requirements and the estimate in an estimation database. This will allow less experienced colleagues to browse this database for something that looks like the task they are asked to estimate, and provide a reality check for their numbers.