The project is finally at the stage where coding work is starting. Given our team is taking over this application from the year prior’s team, most of our coding work is figuring out what the current code is doing. Up until this point though, it has been a lot of writing.

I had started the project under the assumption that the writing would be minimal; we already had a product to work off of with diagrams and previous technical requirements. What I had found however is that a lot of it needed to be updated, despite mostly not being touched over the summer. Of course you can always find work to do and things to fix when you’re iterating over something, but a lot of what was updated was more than this. I think a lot of the differences between last years and current years documents came from requirements actually changing.

I’ve always heard praise for newer more iterative approaches to software such as Agile and Scrum, but it’s neat to see the benefits of such things manifesting here. I think after our project sponsor had more experience with the current version of the application, he had realized the requirements needed to go in a different direction. A lot of these issues showed themselves in ways that suggest a lot of the behind-the-scenes (backend) work had been done before showing something up front. Below is an example of how the data was proposed to move in the application. Our project sponsor now thinks some of these sections aren’t as useful as initially thought to be, such as how labs use/share data.

I think I’ll make it a goal to try and share as much insight into the code as possible with our sponsor to avoid missing or misinterpreting requirements. I’d rather keep the technical requirements a living document than something to forget about and let fall out of date.