After just six weeks of graduate training, myself and two other colleagues are working on-site with a strategic, nationwide facilities management client.
We’re following in the footsteps of DJ Adams and Lindsay Stanger, who built an application that timesheet managers now use to input data about their workers. Their app means that workers are paid as accurately and efficiently as possible whilst providing a pleasant user interface for the timesheet managers. Our project builds on this, and you can read Project neon: Reporting with SAP UI5 and Fiori - Week 1 to find out about the scope.
Last week, we got our gateway service up and running, we had a code review and finished tweaking the UI, we mitigated scope creep after a demanding demo with some new faces, we worked around the problem of the client’s data cleansing exercise, and we started to look into data binding. What about this week?
The client has been great to work with, and very accommodating to the fact that we’re new graduates with just six weeks of training under our belts. Understandably, as we approached testing and go-live, the client wanted reassurance that we’d deliver on time. We had a meeting on Monday to set a day-by-day timeline. The main reason for this was to ensure that we had access to the right systems, resources and assistance to achieve go-live on time. Yet the exercise also proved useful because it helped us to break down our final two weeks, during which we had a lot to achieve, into shorter-term and more manageable tasks, giving us some perspective on the end result.
More data binding
Our main priority this week was to set up the data binding. Ideally, we wanted to start data binding in week 4, but it’s a complex task and something we hadn’t covered during training, so when we spent time on data binding in week 4 we were mainly researching different methods. That meant we really had to get our skates on this week!
Sadly for us, Lindsay was spending time in Berlin at the SAP Tech-Ed conference, so she wasn’t available to help us on-site this week. However, this meant that John Murray joined us on-site in her absence. John has experience with data binding, so we were confident that things would progress more quickly with John on hand to help us, than if we had to try to figure it out alone.
We were right: John’s experience proved vital to our progression, especially at the start of the week. As I’ve mentioned, the documentation that’s currently available on data binding is confusing and inconsistent, and often two resources will contradict each other in the approaches they suggest. As such, we didn’t really know where to start, but John could guide us in the right direction. This meant we didn’t need to spend time experimenting with different methods of data binding, and we had a clearer idea of how to make data binding work early in the week.
That being said, every project is different, and our app often required types or methods of data binding that John hadn’t encountered before. This meant that, on a few occasions, we reached out to other Bluefin UI5 leaders like Oli Rogers and Brenton O’Callaghan in order to help us resolve persistent issues with data binding, and to speed the process up when it started to slow down.
These kinds of difficulties surrounding data binding did indeed slow us down, which was frustrating: although we were progressing through our to-do list slowly but surely, and although we were learning lots about data binding, we weren’t progressing quickly enough to meet the targets we’d promised to the client. We had a demo to give on Friday afternoon, and by that point we also wanted to be ready for testing. This problem was exacerbated by the fact that John wasn’t supposed to be with us on Friday: he was due to work on another project. However, in order to meet our Friday deadlines, our vertical head Chris Smith drafted in John to give us more of his much-needed guidance. Without John’s help, we wouldn’t have been able to complete all our work on time, so a big thank you goes out to him!
Ready for launch
As we approached the end of the week, we had to ready ourselves for leaving the client’s development landscape, and for landing in pre-production on Monday. In order to give us a head-start on the transport process we released our transports on Friday, as they were already ready, even though we weren’t scheduled to release them until the Monday. This meant our transports had a wider window of opportunity in which to be approved, increasing the likelihood that the pre-prod environment would contain everything we needed by our Monday deadline.
Additionally, with testing on the horizon, we had a meeting on Friday afternoon with the individuals that will be testing the app for us. We demoed the app to them, and had a long, interesting discussion about tweaks they’d like to make to the UI. This was great, as it gave us a taste of what it will be like to implement changes and fixes that are picked up during testing, and it allowed us to get to know the types of things that our testers will be looking for.
Whilst this week has been stressful, it taught us a lot about being realistic about how much we can achieve, and about being self-aware. It’s okay to admit that you need help, because everyone wants you to succeed and will do all they can to help you. The challenge is knowing when to reach out for help in the first place, and striking the balance between working things out for yourself, and keeping the project on track.