Day 19

The development of our system is over now. But there is still so many things to add :( Today we had our last sprint demo. Everyone was so confident in our success, that only we only had a few spectators. They were right, ours and Java teams demo was successful.

After the demo we had a video presentation seminar. During this seminar we discussed various ways to make our presentation better and more memorable. Everyone offered their thoughts and tips on what helped them, when giving a presentation and we were able to ask any questions about presenting. After completing this we were tasked with creating our final demo. While previously this final demo had been just a box to tick, this changed when Oliver said that this demo will have crucial impact on how we as a team will be remembered at Helmes. This meant the demo was suddenly very important and this brought a certain level of pressure with it. We didn't even know who would be presenting for our team.

In the end we decided that my teammate Eva will do the problem introduction and Giorgi will go through the application while I present. And by the time I had gotten my head around the fact that I would have to be presenting it was time for our video practice session. Java team went first and their presentation was roughly listing most of the features added to the system. As it turns out this was not the aim of the presentation at all. The aim of the presentation was to show what had changed in the process by adding this application to Helmes's tools. Leonid, the Java team presenter got a lot of feedback and then it was our turn. It went a little better as we did show the value that we created, but we were demonstrating the wrong part of the system. So for both teams it was back to the drawing board.

The next 3-4 hours we rewrote our presentations and reworked our demonstrations. The evening ended with us doing 2-3 practice runs to be ready for Friday mornings final demonstration.

Day 18

Our last days here. We're wrapping everything up and trying to finish off the stories we have left. During the stand-up we informed our PO, that we have a version on the test environment that is close to the final release for the sprint.

My task today was to load the data from our part of the system to the existing system using JavaScript. As I had started with that task yesterday and completed half of it already I was confident of finishing the task before 2 pm. Without much resistance I managed to complete the task just before lunch. As I asked my teammate to deploy the changes a familiar demon rose from the depths of our code. The attachments. As we were very close to completing our sprint my teammate took on the bug of being able to upload files larger than 100mb. And he succeeded! All is well.

Trying to load a contract with attachments

Now armed with our giant files the application felt like a Kia Cee'd, in the winter, with summer tires, on ice. After debugging the problem with our mentors we determined, that the fault was in our global usage of the dbset, which lazily loaded the attachments with every contract you accessed. After rewriting our usage the application was loading our contracts with blistering speed once again. Yay!

Everything else taking advantage of our glorious lazy loading however was now broken. With some trial and error we started weeding out the troublesome places. This was no simple task since writing the project has been a team effort so we didn't know where someone might have used lazily loaded attachments. Also each person themselves hardly remembered the places where they used our beloved attachments.

After many hours of not very effective debugging we managed to get a working demo out. When we left the Java team was still there, God knows what they are doing there. The demo is at 9:30 am. Testing is at 9 am.

Day 17

Today we instinctively started talking about tasks before the stand-up even officially even started. Everyone who arrived shared what we wanted to do today and what tasks we would be taking on. As it was first come first serve type of situation we had divided all of the juicier tasks, meaning the ones that required more time and effort. As our last member walked in all they could do was take on some of the smaller tasks and help others. By now it was time for our actual stand-up. So we reflected on what we had done yesterday and filled our PO on what we had planned for today.

This is not the stand-up you're looking for

I ended up with the task of integrating our project with the previously completed part of the system. I've heard some horror stories when people have been dealing with integrating systems together, so I was cautious when approaching the task. Luckily for me it was a tiny change, only requiring changing 2 tables and the code connected with them.

As that would be the juicy part of the solution I naturally decided it would be smart to leave this problem for the evening, when I'm tired and there are no mentors to help you. The other task of submitting data to the other part of the system was straightforward and I had done it by lunch. As I already had some momentum writing the code I tried to keep it going by moving to the harder task.

The right approach would have been to map out what needed to be changed and what changes in the system when I make my changes. This calm and collected approach would have saved me time in the long run. Boys being boys I went in guns blazing. The database change was completely painless as it had been done on the first day by one of my peers here in Bootcamp. Then with some back and forth I changed the views to contain my id and text for the user. This was somewhat challenging, but it did submit to a few wild swings of the hammer.

Now it was time for a seminar about software development in Helmes. The seminar started with our presenter Eliis Väert asking each and every one present about what we would like to hear about. We went over the whole process how development happens in Helmes. Starting with finding clients and how the analysis process takes place. The duration and requirements for the analysis can vary wildly as the client can come to Helmes with just an idea or have their analysis done already or they want to use the waterfall method. To quickly mention the stages of analysis are called
QuickStart → R&D Meeting → Scope definition & solution design → Presenting solutions → Offer presentation & contract. We moved on to the kick-off, where development starts and the number of  team members are ramped up. As a part of kick-off we fleshed out the roles in a team and what the function is for team lead,  analyst and lead developer. We discussed the problem, that the product owner is not always available or great at developing backlog and how the extra load is carried by the 3 more senior roles in a team. After the development cycles comes the release of the MVP. This means that the system needs to be supported by the team. There may be additional developments for this client, but it might just be all the client needs and need for the code to be maintained. This creates a problem of motivation for the team as no new technologies are introduced and the team happiness may suffer. A solution can be to rewrite the system whenever a functionality is requested. We ended the talk with some differences in finding clients in regards to culture, preconceptions, ease of communication and briefly discussed how these differences could be overcome.

After the talk I refined the previously written hammercode with a small chisel. Apparently thinking about your solution and stepping back for a while helps, who knew? The rest of the evening I battled with some errors and quirks caused by my changes. Fortunately by the end of the day I fixed it with some levelheaded help from my teammate.

Day 16

Our last week of bootcamp. Feels sad. But the development cycle must continue. So the day started with a stand-up. After laying down our daily plans, we set to work on them.

Writing code became more of fixing the bugs and tying up loose ends. Getting into the nitty-gritty, making the UI understandable and appealing to the eye. All of this is highly time consuming and often does not produce the same level of satisfaction as adding a new functionality and figuring the problem out. This is more of a fine tune of the existing code and takes a lot of time and rewards the programmer only sparingly.

Did I break something?

With small tasks and improvements on our sprint board we chugged slowly closer to completing this sprint. By the end of the night we came to the realization, that we needed to get more stories. We scheduled a meeting with our PO, who so conveniently is always here for us. We took on a few new stories and gave assessments to a few more, that we didn't dare to add to the sprint, but if we had the time, we could get started on them. Not pure Scrum, but in the duration of the sprint it will be beneficial. Remember when I said we will play paintball on Tuesday?

Yeah! We played paintball today! We met up at Männiku where we were provided with the gear and the battle commenced. The first two games on the open the Java team dominated and won them in a convincing manner. But then the change happened, we moved to the area with terrain and it was clear, that the superior wits of the .net developers would triumph here!

Yeah..No. I don't know what Java team was compensating for on the battlefield, I guess we will see during the demo on Friday. They took the two next rounds even with strong opposition shown by the .net team. The last two rounds were split by the teams. And in the final round the Java team gained the upper hand once again. A dominant victory for Java team, but it was fun for all participants. Great experience, great people!

Day 15

As the day started with stand-up we had little to report on what we did yesterday as we had had a half day of programming since we had the sprint yesterday. So we focused more on what we were planning to do today.

The day after the sprint is always the most rewarding day as you can just crudely write code and see the features being implemented. These days have become my favorites and I had a nice time filling the criteria in my story. That is until I hit a roadblock. I needed to filter our contracts by date and had to send the date as a GET parameter. This didn't work since the default InvariantCulture was using a different format than our date fields. So I opted to write a slightly modified model binder that took the datetime object and parsed it the way I wanted. As I hadn't done this before it took me a lot of time.

Some days you just get stuck on a problem for hours and solving it takes way too long. Meanwhile my teammates were skillful enough to avoid all of this type of pitfalls and the progress made was significant. We were confident we would have to take on new tasks by Tuesday as we left for the weekend. 

How things are in the Java team ¯\_(ツ)_/¯

Day 14

Today started with sprint planning, we still had a nice backlog for our project so for us we just assigned story points to our backlog and added them to the sprint. The beginning was easy as we were adding new features that did not conflict with our completed stories. When we hit the famous attachment story about Power of Attorney documents, then our team decided to revisit the attachment module and make sure we would be able to support attachments over 100MB. This was taken on as a big story and it pretty much concluded our last sprint for us. 

Our last sprint :(

At 11 o'clock we had code review, where our code was deemed good, but we should make use of Linq more in our queries and iterations. This is somewhat easier than our Java team, where their code had to be more readable than this blog.

Java mentors when reviewing code

With our new tasks in hand we assigned them and everyone was busy working on their problems until the internet connection was gone from the whole house. As this happened half past 4 already most people decided to call it a day and head home. We on the other hand had our paintball activity event planned and it would be easier to leave as a group from our offices. So we waited out the internet issue, that only took about 25 minutes.

About 30 minutes before we were to leave for the event Oliver came into our room asking "Have you seen the weather?". We were caught by surprise as we had no windows in our room, "It's pouring rain outside!" Oliver explained. We still decided to give our group activity a shot, maybe it wouldn't rain there.

So yeah, it rained there. We rescheduled the team event for Tuesday and currently we are praying for good weather.

Day 13

Today is the demo day again. Wow time really flies when you got some problems to solve. Time had not flown as fast for my team as it had for our other team though. Beginning their last day they had completed half of their stories.

Due to us having only one story to do for our day and the testing being done for other components (Yay for taking on more stories at the end of the sprint), we tried out the fabled quad-programming, where one person codes, other person observes and two others are just distractions.

This was pretty much our day up until 1 hour before the demo when we experienced our first server downtime.

Our server got knocked out! We alarmed our bootcamp main organizer Oliver, who sped us to the Ops room, where they were aware of the problem and laughed at our timeframe of needing to do a demo in an hour. "Plenty of time." they said and asked "Do you want to install updates while it's down?". Joking aside the server was up soon enough.

Did our deployment still work? It did not. So we needed to redeploy. We went over the changes we had made since the last deployment and speed-tested it. Now or nothing we used the luck we had and deployed our newest publication.

The time for the demo was here and the Java team went first. Having complained for the whole day, that they had nothing to present to the client to due multiple blocking stories, they sure did have a lot completed. They had chewed through most of their harder tasks and those not implemented were just tiny features on the good foundation that they had. The demo was a screaming success.

Same goes for the .net team, but with less drama and simpler demo.

The Sprint retro was highly positive and everyone found more good points to put on the board. This concluded the sprint for us and we were free to go home.

Yay for an early day

Day 12

The morning stand-up revealed, that the sprint is looking good and all we have left is a bunch of testing and deploying.

We wanted to  get all of our tasks finished and deploy our changes to the test server before our PO demo at 1 o'clock. This challenge we managed, but we still couldn't fully demo it on the test server as it had some issues.

The demo went well and we got positive feedback from our PO. She highlighted some problematic decisions we had made in the design and gave us some feedback on what to work on next. Our PO also offered to test the authorization in the test environment, when it was operational. So getting our deployment running is what we focused on after the meeting with our PO. We only had 30 minutes to tackle this problem, because we had a meeting with the CEO of Helmes scheduled.

In the meeting we got to hear the day-to-day operations Helmes CEO has and how he helps the company run smoothly. Biggest revelation being that a manager has done his job well, if he is not needed by his subordinates. He spoke about attracting clients and described how the process can be a long one, especially for big multinational companies. Creating a link between your company and the other company is key in making future deals happen. Many big contracts with over 80 people working on them today have started with projects assigned to a team of 2. 

After the meeting we were back in the world of fixing our deployment. We had an issue with seeing all the contracts when logged in as an administrator. We couldn't figure out why the administrator didn't have all the rights he/she would need. As we couldn't just access the code running on the server we really needed to access the logs. Guess who didn't log their project? 

With a bit of messing around we got some logs to show up in the database, but still couldn't figure out why we were getting this error. But then I remembered, that we use AppConfig to store some variables. And the only file we didn't overwrite or even check when deploying? Yes, we really are that stupid.

Our mentors actually warned us about this and recommended to use a nice tool called TotalCommander, that allows you to compare contents of a folder and displays files that differ and enables you to view the differences in them. Being brash bootcampers we didn't heed these suggestions. May you be smarter than us.

We finished the evening by getting 2 more stories for our sprint and started on them.