Reading time: 10 - 17 minutes
Header Information
|
User
|
Technical Buyer
|
Economic Buyer
|
|
· Developer
· Architect
|
· IT Department
· Offshore Manager
|
· Director
· CIO
|
A day in life (before)
Scene or situation: Focus on the moment of frustration. What is going on? What is the user about to attempt?
Borys is the lead programmer of a mid-size offshore Development Company based on Poland. He is currently working on the corporative payroll system of its main client who is based on the United Kingdom. He spends one week a month at the client company at London working along the client in planning new features and requirements. That week is always very intense as the face to face communication makes it a very productive time. Borys is a very skilled developer, he got the lead programmer job after his superior was required by the client for another mission critical system just a couple of month ago. Before that he was the developer of the Transacting engine, the one that execute online transactions on behalf of the entire organization.
In one of those trips an urgent change request was added to the backlog by Ian from the business analysis team. That left them 4 days to do the necessary changes in the transacting engine, and the rest of the application.
Irena was a very clever developer at the Warsaw team, leaving her in charge of the 120K lines of the Transacting engine code, had been a no brainer decision. However, she was quite new to the job of extending it.
Desired Outcome: What is the user trying to accomplish? Why is it important?
The change request was in fact caused by a new requirement issued by the England Central Bank, and it must be in effect by Monday morning, when the company would start the payroll processes to all their providers and workers. If they didn’t comply most transactions would be rejected by the source and requiring the company to handle each one individually by a manual workflow; with the volume of transactions scheduled to occur that was definitely an impossible task.
Attempted approach: Without the new product, how does the user go about the task?
Borys meet with Ian and Irena for 2 hours to understand the scope of the critical request. Irena was at the phone from Poland, and she was able to understand the main problem. After that Borys meet with her by phone to speak about the extensions that had to be performed on the rules engine to handle the requirement of the Central Bank. Borys knew that the rules engine was capable of doing it with some extensions that would require slight architectural changes in the adapters and rules logic. Being the most knowledgeable person on the transacting engine (it was his baby after all), he explain in detail Irena the solution. It wouldn’t take him more that 1 day to solve the problem, which would leave the certification team Friday to perform all the required tests to put it in production on Saturday.
He continued with his planned work while Irena was busy working along the plan they laid out. At the end of the day they spoke again, she was a little behind, and had to take a couple of decisions that Borys wasn’t confident about. He had his time booked until after dinner, so he wouldn’t be of much use that day. She continues working around the clock until 1AM.
The next day, they had the daily meeting Irena needed lots of help with the rules engine, but no one was as skilled at it as him. They phone called each other every 2 hours to assess the status. Lots of emails with questions went back and forth, Borys was worried. At the end of the day he had to take the airplane to come back to Poland, and they were already delayed.
He went to the office on Saturday and started to review the code, he found very important mistaken assumptions; it wasn’t Irena’s fault, which was the first time she extended the rules engine. That part of the system had been in place without modifications for almost 6 months. He had a hard time remembering all the nitty gritty details on why he did some things also. They pair programmed and redid the entire feature and finished by 2AM. On Sunday the Certification team had to come to the office, they weren’t very thrilled at it. Deployments where done on weekends so the production team had rotating personnel that worked on weekends so they didn’t mind.
Errors where found and corrected by Borys and Irena, working around the clock they decided that if there was a bug they wouldn’t correct it; there was no more time, they had to put the changes in production right now. The production team finished by 5AM London Time and was ready to roll by 7AM. Most transactions were executed with some exceptions that were performed by hand. The mission has been accomplished. Remaining defects where squashed during the week for the next weekend deployment.
Interfering factors: What goes wrong? How and why does it go wrong?
Irena was a very clever developer but her knowledge of the inner working of the rules engine was not as detailed at needed, even if Borys was pretty detailed in the documentation. Borys wasn’t able to see what Irena was doing because IT rules at the client company didn’t allow him to use screen sharing software (banking network restrictions are a norm almost everywhere) so his communication bandwidth was limited and wasn’t able to track her steps to guide her. The end result was to restart the entire work Irena has been doing for 2 days adding to the project wasted effort.
Borys knew very well the inner working of the rules engine (as he has written it) but the last time that part was modified she wasn’t on the job. Even Borys had trouble remembering why he did something like performance tweak here and there. Those detailed inner working reasons are not typically documented because they are not worth the effort (except in cases like this one).
The certification team at London was not very happy to have to work on Saturday night and Sunday when they were told that they would have the build by Friday. And the production team had to work around the clock to have the system productively by 7AM without the entire certification process done; at the time they were already complaining that if something bad happened it wasn’t their fault.
The system worked but they were lucky, as the certification process couldn’t be performed in it’s entirely; so they risked a lot to go into production.
Economic Consequences: So what? What is the impact of the user failing to accomplish the task productively?
Failing to have the requirement changes by Monday would have been a huge problem for the client company and for Borys boss too. Having to resort to the manual workflow would have delayed the payments to providers for 2 to 4 days, delaying also the delivery of important goods. Borys boss would have trouble billing the extra hours worked by Borys and Irena, as the client wouldn’t be too thrilled of the inconvenient.
A day in life (after)
New approach: With the new product how does the end user go about the task?
Borys and Irena would have the meeting with Ian. Irena and Borys would fire up Visual Studio, and try to connect through the Windows Peer-Networking stack (a peer-to-peer technology that can pass firewalls that enable IPv6 edge traversal). Sadly the IT department does not allow IPv6 traffic, so Irena shared the solution through beWeeVee for Visual Studio Saas Viewer, a Silverlight application that is able to give basic access to the solution on the other end.
Borys and Irena discussed the detailed implementation right into the code, putting comments and discussing key details of the inner working on the rules engine. At the end of the 2 hours conference call they had already laid out a solution straight in the code. That was possible because they would simultaneously write code while they discussed the changes needed. Borys helped Irena also to write the tests that would define the interface and behavior of the rules engine changes.
Irena worked on her side, and once in a while Borys connected to the Saas Viewer to see a fast playback of the changes that Irena is working on; in the event he discover something that he was not confident it can work, he annotate the information in Irena’s code and sent her an small review project tweet for her to notice that he was around.
Irena finishes by 4AM and by Friday morning, the build was sent to the certification that took the entire day and Saturday morning. By Saturday midday the build was ready to be put in production.
Enabling factors: What is it about the new approach that allows the user to get unstuck and be productive?
The live collaboration straight into the code that beWeeVee added to Visual Studio allowed Borys and Irena a very efficient communication and collaborative workflow. The use of the beWeeVee for Visual Studio SaaS Viewer gave Borys the ability to access Irena’s solution code in a split second from a web source, even if the typical workflow was disrupted for security reasons inside the bank.
Furthermore, the ability to replay all changes that Irena made to the code was an invaluable aid to let Borys understand in a quick glance the state of advance. Even more, being able to review some rule engine key changes months ago using the playback feature aided Borys to remember key details that were invaluable at the time of communicating the solution to Irena.
Economic rewards: What are the costs avoided or benefits gained?
One of the biggest benefits of beWeeVee for Visual Studio is that the communication bandwidth is enhanced by working directly with the subject matter, not in an abstract way. In that way, the mental model mismatch between Borys and Irena get narrower, diminishing the rework, accelerating the time it takes to accomplish the task. The solution obtained diminished the needs of redesign and refactoring after production because the entire team was more efficient.
Under the same assumptions, an alternative solution to diminish the risk identified after the first day would have involved Borys to depart Thursday noon to Warsaw to join Irena on Friday. Even in that case, they couldn’t have been able to release the build for certification on Friday mid-day.
Under a different set of assumptions the IT department would have permitted the use of a remote desktop solution. That could make a slight difference on the communication (the first 2 hours information exchange between Borys and Irena), however it wouldn’t made much difference on the efficiency of being able to write code simultaneously and the ability to use the playback ability. So the efficiency would have been still much lower under those assumptions. Moreover, as beWeeVee for Visual Studio is embedded in the native development environment, the development workflow is not altered; something that would have happened using other alternative software likes Etherpad or beWeeVee Web.
Corvalius, Technology
beweevee, co-operation, collaborative programming, live collaboration, visual studio
Recent Comments