I recently wrote a post about why software engineering is so great. This got me thinking about some of the negatives.

Perfection is necessary
Ever made a mistake? How about making thousands of somethings that you carefully designed? Now what if those somethings were responsible for moving millions in currency or reporting on sensitive data for strategic purposes? When designing and implementing software systems it’s absolutely necessary to not err. Errors have devastating consequences and nobody is terrible interested in being understanding when a missing comma or poorly constructed process has “lost their money” or put business on hold.

High reliance on others
As a software engineer you can only perform well if you have certain tools, the right information, the right budget, the right environment, the right user response and enough time. Those factors are of concern to managers, sponsors and business but you still rely on a lot outside of you just to do your job.

Lots of “shovel work”
In any job you may expect some “shovel work”. When I job shadowed programmer some ten years ago I saw very clearly that his particular job was not for me. He did the exact same thing every day. He built tiny web applications. As most of every application he worked on consisted of 6-10 patterns sitting together on a website, he would literally copy-paste, all day long. He hated his job and just watching almost put me to sleep. I likened his job to shoveling. Take dirt from here and put it there. Now every job has it’s “shovel work”. In building systems there can be a lot of this sometimes. No intelligence is required. One pattern is implemented a thousand times over. Almost copy-pasting. That’s not fun.

The changing space of software
While it’s great that we get to go on learning all the time and this keeps things interesting (see my previous past) it also means everything you build will be replaced, it will get old, it will get too slow or too something. Everything is going to be thrown out and something new will take its place. This is scary as people themselves age. I’ve seen some good developers I know almost refuse to embrace the changes coming to my particular space. Those who don’t adopt severely shorten their working lifetime.


Ever wondered why software engineering is one of the top jobs? While I’m sure that people considered a number of factors before publishing articles like the one linked (I’ve seen many that put software engineering in the top three), here’s my list.

  1. To be continually learning. Learning means interacting with something different to what you already know. The nature & content of what you deal with all the time is changing. This is far better than dealing with the exact same task or information all the time. It keeps things interesting. This is very different from the “functional consultant” role. One functional developer told me once, “We just follow the manual or the wizard. There’s nothing to it.”
  2. Dealing with something so immaterial. There are a thousand different ways to implement something. They can all be as different from the next way as night is from day, all while looking no different to the front-end user. There’s something about this that is very satisfying. It’s like working with magic. Where the part that is unseen is most important and most complex though from the front-end there’s no reference to anything that testifies to this.
  3. Problem solving. Nothing makes software engineering more fun than tackling a problem – something that looks impossible is just another adventure in solutions design. Add to that, complexity. We try to keep solutions simple but we still have to deal with the complexity that is already present. If this is done following standards and best practices the resulting solution can work well.
  4. Getting to make things. Everybody likes making things. Just look at kids with Lego or Minecraft. It’s much the same for software engineers. To type a bunch of code arranged in some particular way and watch it come to life and achieve something truly useful is an absolute joy. This is very different from the “technical consultant” role as an implementation covers so many layers. Techies normally work in a tiny space – like the database with some PLSQL. Being a software engineer means having to plan for and build in all the layers of modern, mature Middleware so as to achieve a quality, decoupled  solution.


Ever got something like: ORA-20000: ORU-10027: buffer overflow, limit of 20000 bytes or maybe ORA-20000: ORU-10027: buffer overflow, limit of 10000 bytes?


Try expanding the buffer by:


Sometimes infrastructure changes results in serlvets being moved. A new strategy or design could result in servlets that have been published that some still make use of (old client software / apps) now sitting neatly in a new better organized place that makes more sense.

What about the older url mapping? Should it just timeout? Maybe respond blank? No, it would be better to response by indicating that it has moved. Modify the code below to point at the new location using accepted web standards:


Servlets are great for simple HTTP get / post requests and responses. The HTTP specification allows for files as well as text to be sent and received.

Here’s a simple example of how to retrieve and sent an image as a response to a servlets doGet() method:


A simple servlet that responds with the file requested

A simple servlet that responds with the file requested



You would call this at it’s url mapping for example: /download/* with the parameter of id={filename}

A request could look like:

Working with servlets can be a lot of fun. Sometimes you may want to check the IP address of the client connected  to the socket making the request.

The doGet method is sent a HttpServletRequest and an HttpServletResponse.

Use the Request to pull the clients address.


If your doGet method looks like mine:

public void doGet(HttpServletRequest request, HttpServletResponse response) {

String clientAddress = request.getRemoteAddr();



All the change happening in the Oracle Database space have made things very interesting! it’s really gotten me thinking.

It’s no secret that Oracle database is an outstanding product. With most banks, finance houses and governments choosing Oracle everyday it’s easy to see where the experts put their trust.

Soon Exadata, Cloud and Big Data will be everywhere. What will this future look like? Here’s a few rough notes on what I’ve from read all over the Internet.

  1. Companies will want to consolidate all their databases and for the first time the hardware will be able to handle it.
  2. Costs will still be extremely relevant.
  3. People were excited about “post-relational databases” but RDMS has stood the test of time. We’re even seeing major players like Google move back to this technology.
  4. DBA’s will continue be necessary and important.
  5. DB Security and Procedure will become a big issue. With more and more companies with all their databases in one place spread over fewer hardware, the stakeholders are going to demand tough standards that work.
  6. Oracle Exadata offerings: For small and some medium size companies their databases are going to get cheaper and aren’t going to sit on their own hardware.
  7. One-click upping of resources (more CPUs / RAM) is going to push people toward the elastic cloud.
  8. We should see an emphasis on Middleware. With less access control over the database, more and more core-infrastructure (libraries and code frameworks) will be written in Java, the Middleware is going to become king.
  9. Everything is moving from disk storage to RAM. Data will still be written to disk though but queries are going to fly.
  10. Private clouds – everywhere!
  11. SOA is going to be a must-have.
  12. BPM will be to die for.