I’m still alive. I’ve made no real progress in coding this week; in between work and various social events, I haven’t even had enough sleep.
Work is going well. I was originally hired as a C++ engineer. The system we are working on has a Java server and a C++ server, and the two have to communicate. The Java server is mainly a ‘pass through’ checker so it is less complex, although, still complex. When a large amount of system changes came in to the Java server, it turned out we only have one Java engineer on the project. Since I have several years experience in Java, I was switched over to help out the Java project.
I wasn’t able to complete the task in the assigned time. However, that’s because I discovered a whole new bug that nobody knew about – that’s another story – and fixed that instead. The original Java engineer one day came past and fixed one line of code and it all worked well. How frustrating. Well, I guess that’s the power of having a fresh pair of eyes looking over your code.
At the moment, though, I’m working on the test scripts for the software. To be able to deliver the project, it needs to perform; we demonstrate that our system works by having it pass test scripts. Out of the team, only two people know how to write these scripts, one is the Java engineer who is super busy, and the other is our part-time subject matter expert.
So for the time being, my job is ‘write and/or repair’ the test scripts so that we can validate our project is deliverable.
As well as this, we are switching to an Agile development lifecycle. I’ve heard about Agile before, but I’ve never had the chance to experience it. I generally approve although many of the other engineers do not. I think we are not properly following the Agile methodology and that is the cause of frustration for the team. They only see ‘endless meetings’ but to me it looks like a good opportunity for our project manager to resolve issues being faced.
Today I had a good moment at work. We have a requirement in our system that we are not allowed to create pointers using ‘new’. The engineers took this to mean that pointers were entirely prohibited, and that the requirement was impossible to meet. I had heard this second hand. When I read the requirements and standard, I realised that their assumption was incorrect. We could still use pointers as long as they weren’t being created with ‘new’ (which meant dynamic memory allocation).
It’s the second time this week that I brought useful information to the team from overhearing conversations – Agile causes us to program in a tight space, so anything being said can be heard by everybody. It cuts down on gossip, but it also helps us to assist others quickly when we do know the answer.
Overall, we are still working on a prototype so the system has a lot of refinement. The lead engineer has used many, many design patterns, using a lot of polymorphism and abstraction techniques. However, this has made the code extremely difficult to follow since it, unexpectedly, jumps around a lot. The engineers have not followed what I expected to be a normal pipeline-inside-a-loop style. It is a state based machine. Because the system is huge, and namespaces have not been used, I’m unable to easily identify the logical flow of the software. I was eventually able to use a GUI step through debugger to walk the code, but even so, it was strange to see code that did not have a logical order.
The last major issue I have is that console output has been disabled. I know why this has been done; because the software is intending to be released as soon as sufficient tests are cleared, and if the console windows appear on the release, that’s a problem. However, this means that engineers are unable to use ‘debug writes’, a kind of troubleshooting tool, effectively. We do have an internal error logging tool but it fails to work in many cases. I often want to be able to see the data inside a given variable at a certain time, and it’s presently impossible at certain points in time, i.e, while the program is running.
There are other workarounds that engineers have used to partially circumvent this. To me it seems far more productive to enable the console until it’s time to make the release version.
I am the least experienced member of the team, so perhaps my issues are simply a matter of inexperience. I will surely look back here in a few months ashamedly. Still, seeing ‘real’ code and the way it’s implemented made me comfortable that I had made good architecture decisions in my software. One day I hope to release it, and if other people can’t use it easily, that’s unacceptable.