- How is the journey so far?
- I am actually most excited for a discovery I made a few days ago. Currently, the project is littered with C# Dictionary return types of the form Dictionary<string, [type]>. This makes readability really low, since you have to scroll forever to figure out what the function is even called, let along its parameters. I’m going to create a few return types, so instead there are IntersectionDictionary or NodeDictionary, etc. Why am I started with this discussion? Well, because our project is finally up and running!
- This has already been a long road. We need to take existing code, change how it is hosted, implement better authentication, modularize existing code, test API endpoints, and document what we did. And we spent quite awhile even figuring out the current setup. Now that the early portions of the project are over – the design, requirement gathering and analysis of the past project phases – I feel like I’ve drive out of a city and finally hit an Interstate where the speed limit is 90 mph. This comes with limitations, as, for instance, adding exception handling can break endpoint tests because the endpoints no longer return only mocked up requests. Progress sometimes means breaking what you already have.
- What communication tools is your team using, and how well is this going?
- We decided early on to use Discord. This has proven much more reliable than Zoom or email. I think communication is one of the strong suits of the team. We’ve been using a Discord channel for daily standups, which allows us to problem solve around blockers and celebrate breakthroughs! I also like the asynchronous nature of the standups, since we’re in 4 different timezones. We use voice calls once a week, plus as needed to resolve blockers, to keep everyone on track without burdening everyone’s time. I would definitely consider this model in a professional setting.
- What Project Management tools is your team using, and how well is that going?
- We’ve centralized project management in Github with Github Issues, Actions and Pull Requests. There are definite limits to this course of action, especially for projects lasting longer than two months. However, for our purposes, it keeps everything contained and centralized. We’ve also been using Confluence for extra data, research into various technologies, and strategies. This makes up for the lack of longform integration in Github.
- How often does your team commit their code? Is code integrating easily?
- At the moment, large portions of our code is actually integrations within AWS. In this sense, we integrate several times a week. For instance, getting the existing frontend setup to handle AWS Amplify and Lambda Functions requires configurations within AWS. We have several team members working on this type of AWS integration and setup. I commit at least once a day when I’m working on my modularization project for the backend server. The difference here is that I’m making more traditional edits to a monolithic code base that can be tracked via Git. The contributions of my team members can be tracked more by the fact that you can login, authenticate and host on AWS and thus are visible best on AWS itself. Furthermore, the frontend authentication has required modifications to the installation scripts, which is now part of the Github repository and is being updated as team members resolve authentication issues.
- How about pull-requests or code reviews? Is this too much overhead or is it useful to your team?
- Again, because most of our work is currently done within AWS, I would ask that we expand some definitions here first. As one team member figures out how to host, integrate or develop something, they will host an information session or show their work in an ad-hoc meeting. This has so far been a really effective way to get everyone’s local environments communicating with the AWS instances. There isn’t a traditional pull-request or code review, per se, but team feedback and team assistance is communicated via Discord and then via these live meetings. Since the goal is integration and testing, this is a huge advantage for the team.
- I’ve been opening pull requests for the backend server project. Teammates have left very useful feedback, including new ways to develop or integrate what I’m working on. We then approve the pull request and merge it back into the main branch. This is the majority of the traditional “pull request/code review” workflow at the moment, again because of the AWS integration. I’ve found this the perfect combination of overhead and feedback.
- What about your build/debug/deployment? Is this going well, or are you spending a lot of time debugging?
- I’ve setup a Continuous Integration workflow for the server modularization and in fact the whole server repository. This has gone relatively well, with short periodic issues stemming from Visual Studio’s strange testing practices and integration testing. Since the project is an integration project, I’ve had to adapt to both integration testing as well as unit testing. I’m also developing tests to measure the effectiveness of the modularization. We’re working on integrating Postman into unit tests to avoid the one issue we’ve had, where my code improvements in exception handling have disabled the endpoints required to integrate into AWS.
- We are spending a lot of time debugging the code from previous groups. For instance, getting the authentication working on the existing frontend has been rather complicated. Several team members are working on modifying, improving and modularizing that, so the debug flow should improve. At the moment, it’s basically extracting the design from the implementation, which is difficult.
- How well is your team following your original Team Standards?
- I think my team is exceeding my expectations from the original Team Standards. There’s high buy in from the team and a lot of hard work. I’ve felt supported by them and have endeavored to support them as best I can. There’s been a lot of highly organized work creating documentation, creating ERDs and other designs, creating code to implement those designs, developing authentication mechanisms, and developing database calls. We’ve settled into relatively well defined project spaces but frequently assist each other.
- Do you personally feel your part of the project will succeed? If not, what do you plan to do to get back on track?
- I do think I’ve achieve the modularization I so naively volunteered myself for. I think I’ll be able to increase performance and ease of integration for the existing code. This should make sure projects focused on extending use cases much easier. I also think the architecture points I’ve learned about (I’ve read the entirety of Clean Architecture for this course) will succeed in making this a more modularized, sustainable and readable system. I’m a bit nervous about the workload, but it doesn’t seem out of my abilities.
- Do you feel your project is on-track to succeed? If not, what do you plan to do to help the team get back on track?
- I’m a bit worried about the entire project succeeding. It’s a very open-ended project that we’ve received, and as we dig deeper we keep finding more complications. In a way, I sliced off the most clear-cut portion of the project. I’m able to move stuff around internally in the server code and so long as the public interfaces such as API endpoints and database calls work, I can pretty much do what I want. My teammates are attempting something that is, in my opinion, an order of magnitude more difficult. They have no control over how AWS works, and have to figure out how to host the server code, integrate databases such as DynamoDB and Athena to improve performance, and figure out how Lambda Functions work to authenticate the frontend. They have less freedom in deciding what to do, but actually having those projects succeed is critical. They’re doing a great job, performing a lot of research and developing better and better integrations. It’s still a monumental challenge.
- What one thing would really help your team succeed?
- We could really use an AWS solution architect. In a sense, we’re all trying to become AWS Solution Architects at lightspeed, but we could really use someone with those preexisting skills to advise us on precisely how to implement certain AWS-standard interfaces. We’ve been working on figuring out how to host on Beanstalk, for instance, but we’ve also been having to test the most cost-efficient way to use EC2 to support the Beanstalk implementation. This has meant one team member setting up multiple different proofs of concept and testing them out. While I think that will definitely help his job search, I’m sure he’d appreciate having someone with the AWS-specific knowledge to answer his questions about configurations and so forth. Similarly, I’m sure that the Lambda Function development would be a lot easier if we’d had existing documentation to figure out how it was originally setup. The preceding team did leave documentation, so again this is not anyone’s fault, but someone with the preexisting knowledge would be very useful.
- Anything project related. You choose.
Leave a Reply