Latest Contributions by JosiahPoyitt

In Mary Shelley’s classic novel Frankenstein, when Victor Frankenstein sets out to achieve his goal, he seeks to make the perfect man. After realising that an average-sized human would require delicate assembly, he makes his creature (Adam) 8 feet tall, with proportionate limbs, lustrous black hair, and pearly white teeth. So engrossed in the details of assembling and animating the creature over several years of the project, he never stopped to look at the whole. It is only after the first twitch of life coursed through his creation that he realised: I had worked hard for nearly two years, for the sole purpose of infusing life into an inanimate body. For this I had deprived myself of rest and health. I had desired it with an ardour that far exceeded moderation; but now that I had finished, the beauty of the dream vanished, and breathless horror and disgust filled my heart. Unable to endure the aspect of the being I had created, I rushed out of the room and continued a long time traversing my bed-chamber, unable to compose my mind to sleep. Shelley may have published Frankenstein in 1818, but this moment in the novel is an exceptional analogy for the project and application development process. As geospatial professionals, project managers, and developers, there is a definite temptation for us to work tirelessly on a technical development without pausing to look at the bigger picture. I know that I personally relish the challenge of attaching the veins, arteries, and muscle fibres of an application and am sure many of you feel the same way. However, it’s important to ensure that the technical innovation of an application does not overshadow the original purpose. It is unlikely that an application or project will come to life and kill my loved ones, as it does in Frankenstein, but the consequences of a final product that doesn’t suit the original business need can still be severe. I’ve seen the effects of poorly executed projects and applications first-hand. After working within one organisation, if I heard someone mention a particular software suite, I would wind up rolling my eyes so hard I could see the inside of my skull. I’ve also had to spend long periods of time restoring a user’s faith in ArcGIS, or even convince them that geospatial tools were worth pursuing, all because of one bad experience. Working within GIS, projects, or application development, we are rarely building an output for our own benefit. As an executive I once worked for put it “we are not a self-licking ice cream”. The apps and projects we oversee are intended to solve a defined business need. If that need is not met, your application may not be utilised by the clients or users you have developed it for. As a consultant, you client may not be as eager for your company’s future business if you were unable to provide what they paid for. If you are working directly for an organisation, your manager or executive may lose faith in your ability to deliver what they want. Once an organisation has devoted time and money developing a solution, they will understandably want a return on that investment. An application that doesn’t provide a benefit will not be utilised, but will hang over the workplace like a bad smell, potentially souring people’s impression of you or the software suite you use. When we focus on the bigger picture, we ensure that our applications focus on the needs of the user, rather than focussing on the technical side. It’s understandable to be excited by, or proud of, a piece of code you’ve written, or an inspired piece of data manipulation, but it cannot come at the expense of the actual requirement that was given to us. The last thing we want to see is that first twitch of life move through something we devoted time and effort to, only to realise we have created a monster. ... View more