blogarticle

High level vs Low level approach to development

We had a discussion in the virtual office earlier today when we were working together to change a report in one of our applications. The report output used Portable Document File (PDF) format and we use a library called fPDF that allows use to create PDF documents via PHP for web based application and one of our developers asked:

open quote Why not use a library that can convert the HTML output into PDF? close quote

It's a good question and can certainly be done, relatively easily, when the HTML is well structured and created using HMTL5 / CSS3, but it has it's limitations.

Using a PDF Library like fPDF allows developers the control to output and allows them manage virtually any aspect of the document, where as a conversation of HTML to PDF doesn't.

Taking the high / low road

I said that we need the control of the output and using a pre-built component or library to manage the conversion would take away functionality. I went on to explain the differences ...

Using a low level approach, you have to define and create the universe in order to build anything, but allows you to define the laws of physics within the universe.

Using a high level approach, you use a universe that someone else has created and are constrained by decisions the previous programmer made, when defining his laws of physics within his universe.

So whilst low level takes longer - after all, according to Genius it took God seven days - it allows you to define the laws of physics (or rules), rather than using someone else's. It reminded me of a project I developed back in 2009; we chose Java J2EE to create a desktop application for creating cash flow scenarios, using data extracted from various accounting software. We need to create a user interface that worked like a spreadsheet, using pivot tables and all sorts of wizardry that chartered accountants like to use for projecting cash flow, enabling business managers to make informed decisions.

java.png

We made an important decision, early in the development, to create a custom model that extended the Abstract Table Model used by Java Swing Tables (which, whilst would take longer to develop) and would give us more flexibility and enable us to create custom functionality that extended that native behaviour. It was a good decision and saved time in the long run.

Conclusion

Development decisions can sometimes seem innocuous, but development teams have to consider how a solution might be used and / or extended over time, so great care should be taken when making decisions of using pre-built code or libraries. Short cuts will often come back to bite you in the arse!

Date: 08/04/2021

gettingintouch

If you like to get in touch, please telephone our offices on +44 (0) 1364 582017 or complete our on-line form and we'll get back to you as soon as possible.

stayingintouch

Stay in touch with what we're up to at Ayrmer Software by following us on one of our social media feeds: we'd be delighted to welcome you as a follower on twitter, become friends on facebook or add us to your circle on Google+. You'll also find us on Linkedin, of course.

clienttestimonials

We researched lots of different on-line booking systems for our Breakfast and After School Club and found that CoB was the only one which would fit around us, as opposed to us changing our processes and payment structures to fit around the software. ...

Jo Sutton Business Manager
The Brook School

Read more ...