No… Scope Creep

It’s almost been one whole year since I started working at the University. On top of my regular workload there has been a major and minor project, based on the amount of time and effort invested in each, that I have worked on. This past week I had the privilege of presenting the minor project, which had a soft rollout earlier in the month. This project is a customized and branded URL shortener, affectionately referred to as the “Go-Server.” What I like most about the project was its clearness of purpose, allowing for concise actions. Actions that led to a successful soft launch and a podcast appearance.

In the beginning the Go-Server was just an idea consisting of a list of benefits, wants and “nice to haves.” As all projects are in the beginning.  What made it stand out to me was the straight forwardness of converting those ideas into requirements. However, simplicity does not guarantee ease. With more complex projects or ones where the ideas were never fully fleshed out I have found it difficult to pin down what the requirements were.

Branding makes up a large chunk of the Go-Server’s purpose. Even with open source solutions available on the web, there was still plenty of work to be done. Meaning I got to code. Which is the part of software development I like the most. Writing code. Debugging. Getting mad at the computer because developers never make mistakes! Customizing the plain vanilla  solution required an understanding of what I was working with. Once I had a grasp on the inner workings of the open source application, adding and disabling features was a walk in the park. This was my first time starting with another’s code base.

Design changes / scope creep changing requirements during the development lifecycle remains a sticking point for me. While I do pride myself on being able to adjust and go with the flow, changes that come down the pipeline and alter or destroy previous assumptions make me question just how flexible I am. Sometimes you just have to throw the whole code base way. This is why quickly surmising requirements, being able to test and code them was a breath of fresh air.

From the planning to design phases, the clarity of purpose made it possible to drive this project home. To me, it emphasized the importance of planning and understanding before code gets written. That is key.  If there is a client that does not have that clarity from the outset it leaves me open to getting bogged down with changes. That’s because “the client is always right.”  Of course there is a limit to the amount of clarity you can have, especially when dealing with more complex applications.

My major take away from the Go-Server is to nail the client down on the core idea of the application. If there is too much room for interpretation or major tweaking, revisit that good old drawing board until all the questions are answered. It’s harder to change a design once the foundation has been laid. And it would suck to be half way through construction only to have the requirements for the foundation change.



Jul 07, 2019
Apr 02, 2019
Mar 13, 2019
Mar 02, 2019
Jul 23, 2017