- Why did you and your team choose the technologies you did?
- My team was in the slightly less common position where we were stepping into an existing project. This was actually a surprise to the team. Prior capstone teams had implemented a prototype of the product. We had prepared a whole design process, and then suddenly found ourselves in the middle of halfway begun project. Although it was not what we were used to from the coursework, my experience at tech companies tells me this is precisely how the real world works. Rarely, unless you start your own company, do you start tabula rasa. Instead, it’s in media res. And that, my friends, shows off my unique humanities/computer science fusion education.
- The outgoing team also only completed a prototype. As we’ve dug into this project, it’s obvious that that alone was a monumental task. They took existing desktop code that operated similarly to Google Maps, put it on a React frontend, and hosted it on AWS. That along is a huge project. Our job, we discovered, was to integrated all of the components into a single, cloud-based, web product. And then we needed to write tests.
- So, here’s a list of the technologies we’re currently considering using. We know for certain that we’re using React and Node because the frontend is really well developed. We’re using AWS, although we’re debating how best to host the backend server. The frontend is definitely being hosted on Amplify. We’re using GeoJSON and a REST API. I have limited experience with GeoJSON from a hobby project, so it’ll be nice to implement it “for real”. There’s also a series of API calls to OpenStreetMap, which is an open source version of visuals and data that you could also find on Google Maps. The backend is going to be primarily ASP.NET and C#, which is a stretch goal for us since most of the team hasn’t worked with them before.
- I drew an architecture diagram that I’m rather proud of. It could be improved in 10,000 different ways, but I threw it together in the time before a meeting at 4PM and the assignment due date at midnight. This should illustrate our current thinking.
- What are their pros and cons?
- So since a lot of the project was already predesigned, we honestly had to pick our way through what we want to retain and what needs to be discarded. The pro to a lot of the architecture was that it simply exists. A prototype is better than a design doc, and a design doc is better than nothing. The implementation has reached a point where the entire frontend architecture wasn’t really up for debate. We will optimize and profile the frontend due to slow loading times, but we didn’t have to design it.
- The backend requires more of our own input. The choice of language was dictated by existing company infrastructure. C# naturally lends itself to .NET development and the language of the web is in JSON. So those elements just kind of clicked together. However, the cloud hosting is more of our own design. We are actually looking into extending the above diagram to include Elastic Beanstalk because it will allow better hosting opportunities. We are also adding Dockerization so that the architecture is more modular. The cons to all of this is that we haven’t done it before. This is uncharted territory for the team.
- What do you like or dislike about your system UI/UX?
- I tend to dislike GIS databases. Google Maps is just about the only one that doesn’t take a billion years to load and since I’m cheap and on low end hardware, I frequently have to kill my Firefox instance or even shutdown my computer altogether. The frontend design from the prior team is brilliant, it make use of a lot of the usability engineering principles I studied in usability engineering. The layer toggles could perhaps be more usable/discoverable but that’s really closer to a better labeling system. Otherwise, the UI is fantastic. The UX is severely hampered by slow loading times and one of our non-functional requirements is a page loading time < 1 second.
- What do you like or dislike about your server/backend system/API?
- I worked in support for a web product for 2.5 years. I mention this because I am not a very good Agile practitioner. I like documentation, I like reading something that explains everything and then following along in the code. I’d rather get the design right long before I implement anything. This makes me much more of a Waterfall practitioner. I mention this because the backend system, as it stands, has low amounts of documentation. I extracted a series of GraphQL endpoints from the frontend and Postman and .NET endpoint from the backend to create an API design document. It’s a pretty basic CRUD system with, actually, a heavy preference towards data reads. I used that set of endpoints to extract a potential NoSQL database design and a set of class diagrams. My team is reviewing my documents, mostly because although I can work fast, I often miss pieces of functionality.
- I think this project is primarily a backend and architecture project. I’m uneasy at how hard it was to onboard originally and don’t like how hard it was to extract the interfaces from the existing setup. I’m making it my mission to significantly enhance that experience for whatever team works on this project next. All of this is to say that the backend and API design is lagging a bit behind where I’d have hoped it would be, but I think it’s trending in the right direction.
- What do you like or dislike about your design modularity? Does it enable each of you to work independently?
- I’m going to be honest, I’m not sure my team wants full independent work. I’m meeting a teammate for some pair programming and design work later today and we have been collaborating a lot on Discord. We have assignments for each team member in our project plan and I’m glad we do so we can fall back on them when we’re uncertain what we’re doing. Nonetheless, I think interdependence is more the way this team is working.
- As for design modularity, I think we actually aimed for designing for modularity. We are trying to design the integration, testing and hosting suites for this project. We’ve done things like create Confluence documents, design documents, and schemas. We’re trying to make the actual design as modular as possible. This means that, theoretically, if someone’s assigned responsibilities blocking, another team member can either assist or take over that task. This is why we’re also trying to document our designs.
- Anything else. You choose.
- A lot of our team is dealing with feeling overwhelmed and out of their depth. This is, I think, normal given that we’re stepping into a situation where we aren’t designing from scratch and where we have to actually gather requirements. There’s a sense of panic and confusion at times that manifests itself in different ways. For me, it manifests in an obsessive need to write documentation because of my support background. If I didn’t have a team to move me along, I’d probably spend the next 8 weeks writing design documents and maybe a line of code.
- I think it’s important to remember that capstone projects will of necessity be left unfinished. At least, those sponsored by industry. Industry partners are used to successive waves of development, integration, testing and redesign. One of the vital stepping stones from studying computer science to working as a software engineer is learning how to step into an existing project. It’s an uncomfortable experience, especially with grades and deadlines, but a necessary one. I’m looking forward to this challenge and the career that will follow.
Leave a Reply