UML? Simple Sketch? Or use UML as sketch?

At university most of us, future Software Engineers, are introduced to the fundamentals of the Unified Modeling Language (UML), myself I took at least a couple of classes that covered three or four types of UML diagrams. However, in an interview when I am asked to quickly draw the design of a project or other system, I get confused: should I try it in UML or is any “sketch” acceptable? Is it ok if I make mistakes during my attempt at UML? This confusion takes over, because UML is a relatively new standard for software design as it was accepted in 2000 and has been a  very controversial topic in large scale development since. Hence, you never know what others think about it. The main reasons against UML use are deemed to be the large variety of diagram types, the use of it for different purposes and that not everyone is familiar with it[1]. Myself, I strongly believe that every software engineer, who one day hopes to successfully contribute to the design of large scale projects should  be familiar with the “basics”of it in order to communicate ideas freely.

*

The “three types” of UML

In large scale development it is important to be able to communicate the system design to all team members. Martin Fowler describes three types of UML that serve different purposes:

  • UML as “sketch”. This type of sketching allows to draw diagrams only for the processes of interest at time of discussion in order to clarify the code to be written or an already implemented system. [2]

  • UML as “blue print”. This type is to represent the whole system design with great detail and tools are mostly used to produce them. [3]

  • UML as “programming language”. This type with very detailed UML diagrams is to compile the diagrams drawn into executable code. [4]

It is evident that all the types are useful in different contexts, to my mind, every developer that wants to collaborate in a team in order to contribute to a project would benefit from knowing how to use UML as “sketch”. This is because, it’s main purpose is to convey ideas and share understanding rather than guarantee completeness of the design in mind, which may be documented in other ways. The other two types of UML described are admittedly not as straight forward and need a lot more practice and detailed knowledge of UML  in order to produce good results. These advanced skills should come with time and depending on what depending on the documentation and coding conventions within the company.

Know the basics and navigate

The idea of using UML diagrams for “sketching” purposes in order to clarify the main components of the design raises the questions: why is the formality of using UML needed? Wouldn’t simple box and line diagrams be enough? [1]. From the first glimpse they seem to suffice, however using UML should be much simpler. This is because in order to draw a simple box and line diagram, one would have to take time to invent their own notation on the spot and explain it to others. Also this notation would have to be explained in writing if the “sketch” ends up being used in documentation. However, when using UML there is a high possibility that other software developers have some knowledge of it or at least would be able to read most of it and ask for some clarification. Moreover, as UML is a standard notation[1] that can be easily looked up. Of course, no one is expected to know the 14 different diagram types in UML and their notations. Surveys have shown that engineers are familiar with about only 20% of UML which is in their sphere of interest and suffices for communication[1]. During my summer internship at a larger company, at first I had to familiarize myself with the system architecture, before diving into the formalities of the code and the JavaDocs. The documentation that I read to do that contained just some very simple UML diagrams to illustrate the how different components come together and what responsibilities they have. Being a newcomer I could “google” all the notation that I was not familiar with, without disturbing my colleagues for explanation. Hence, speaking from experience, trying to put together sketch diagrams using UML notation saves time and facilitates the overall understanding.

Forgetting notation & making up as you go along

Easily forgetting the notation is a common problem, when Joshua Bloch, the author of “Effective Java”, was asked about the use of UML, he said: “I think it’s nice to be able to make diagrams that other people can understand. But honestly I can’t even remember which components are supposed to be round or square.”[5] When notation is forgotten in a middle of a discussion, one automatically switches to some made-up intuitive notation. Making adjustments to UML is  acceptable during interactive discussion as the importance lies in conveying the message, but obviously cannot be included in documentation as others may not understand. Hence, the diagrams have to be brushed up with the conventional notation for inclusion in more formal documentation. Once, again it can be argued that not everybody is familiar with the notation, hence it may not matter what is used, or that everyone who is going to be looking at the documentation was at the meeting and will be able to understand the diagram. However, remember, in software engineering people move on and new ones join, they will want to and have to understand everything, UML makes this easier.

Embarrassment and jeopardy of mixing up details

The ultimate danger when trying to “sketch” in UML is to mix up the notation and illustrate something different. It is not a surprize that this happens especially if one does not use the notation regularly. The most common problems include mixing up composition and aggregation arrows and forgetting to use the fork node from to indicate that both actions should be carried out from the initial node and not one of them[6]. Such misunderstandings may cause different comprehension of the problem and lead to wrong implementations, that may cause even larger problems as the project scales up. A way to avoid mistakes is to go through the diagram with colleagues and hope that they will point out the mistakes. Therefore, it is important that many would be familiar with the basics of UML in order to catch propagating errors. Also, some people may know more on that particular notation, hence admitting early that there is some uncertainty about the notation may reduce the number of problems and allow one to learn from others.

All in all…

I believe that knowing the basics of UML is very useful in large scale development, because it provides an easier way to communicate a design. As discussed UML can be used for multiple purposes, to my mind, the most important one to all developers is to have the ability to use UML as “sketch” to convey the main ideas rather than details, which can be easily done by knowing the basics. Discussing designs in person is much more flexible in notation rather when one wants to include a “sketch” in documentation. In person discussions allow alterations to notation, but for global understanding the actual UML notation has to be used for even simple diagrams that want to convey the idea. Surely, it is easy to forget or mix up the notation, as admittedly sometimes it is complicated, but in my opinion practice makes perfect 🙂 The simple “sketch” is only simple when it can be easily understood by others and this is achieved by using basic UML.

 References:

[1] Paulo Merson, Five Reasons Developers Don’t Use UML and Six Reasons to Use it: http://saturnnetwork.wordpress.com/2010/10/22/five-reasons-developers-dont-use-uml-and-six-reasons-to-use-it/

[2] Martin Fowler, UmlAsSketch: http://martinfowler.com/bliki/UmlAsSketch.html

[3] Martin Fowler, UmlAsBlueprint: http://martinfowler.com/bliki/UmlAsBlueprint.html

[4] Martin Fowler, UmlAsProgramminLanguage: http://martinfowler.com/bliki/UmlAsProgrammingLanguage.html

[5] Joshua Bloch interview, http://www.cs.umd.edu/class/fall2009/cmsc132H/JoshuaBloch.pdf

[6] Markus Sprunck, Three Common Errors in Whiteboard Job Interviews with UML Diagrams: http://www.sw-engineering-candies.com/blog-1/commonerrorsinwhiteboardjobinterviewswithumldiagrams

*The illustration above was made using the BitStrips app and some personalization

Response Article: Pair Program & Remain on Friendly Terms

This is a response article to “Pair Programming: Will It Make You Hate Your Colleagues?” blog post. The author of this article argues that pair programming 100% of the coding time is not a good idea and would result in annoyance between the programmers. I would like to disagree with the arguments made and argue that it is a perfectly good programming principle that can be applied everyday while the programmers still remaining on friendly terms.

Two thinking heads are always better than one

The author argues that every project has  “mundane” and “trivial” code to write, hence pair programming in such a case is a waste of time and talent, as one of the programmers could do the job well. To the contrary, I believe that when solving “obvious” tasks, pair programming is extremely beneficial. This is because, when programming alone people tend to make mistakes when they least expect them as they become too confident with the simple tasks and make careless mistakes. In the case of pair programming, solving these tasks may be boring and seem as a waste of time, however they are effective in catching bugs and with two people coding them up the opportunity to try out different approaches even to mundane tasks still remains[1]. Hence, the initial boredom should lead to more less discontent after, as mistakes are avoided early on.

Taking the time to learn

One more point that is being made that pair programming does not allow the observer (the developer that observes the person that codes) to learn how to use the developers tools. However, I think that this is not the case with pair programming as it has educational aims. In pair programming there are three types of pairs: novice-novice, novice-expert & expert-expert. In any situation one can take time to learn as an input to the future. The person has their hands on coding (the so called driver) uses the tool, while the observer observes carefully what is being done and then the roles should be switched in order to share the experience. Of course, this would take more time as two people would have to go through similar steps, but it is an input to the future and both developers learn how to use the tool. In the case of novice-expert pair, the expert can become the observer and advise the novice how to use the tool while they drive. Such an environment should not result in irritation, it should cause gratitude and joy that something new has been learnt [2].

No superiority & avoiding conflict

It was argued that disagreements on design and implementation may result in one of the team members to feel undervalued. Of course, an argument may happen, but if there is a mutual understanding that all choices have to be justified, then the decision with better reasoning is made no matter who suggested it. As both developers are to aim for the best solution “giving in” in order to avoid conflict does not seem reasonable, because one will have to live with decisions made for a long time. Hence, there is no programmer is superior [3] unless it is the expert-novice situation, where the expert usually is the one to make the big decisions, but should also be open to hearing the opinion of the novice, who may point out something that has been missed. Therefore, of course it may be disappointing that maybe one programmer’s decisions prove to be more justified more often, but the other programmer can learn from it and in the future they may follow a similar line of reasoning or may find better arguments to refute it, hence being grateful for improvement.

 Spending time exploring 

With regards to the idea that pair programming reduces one’s individual familiarity with the code base, it can be said that such a situation should not exist, otherwise the whole project is in jeopardy. This is because both developers should be familiar with the whole code base and be aware of all the changes that are being made while pair programming and understand them in order to make good development decisions in the future. Collectively exploring the code should cause more satisfaction than anything else and make the programmers more confident with their understanding [4], as collaborative exploration should bring out aspects of the code that one would not notice alone and should make understanding the code easier, as different people understand different things.

 Being considerate

The argument that programmers have days of low productivity that are not good for pair programming and may result in conflict and have extremely productive longer days that compensate for the former cannot be applicable in a well functioning working environment. This is because, work has to be done and one cannot wait until the morning of or plan the way that they will feel during that particular day. Of course, everyone has good and bad days, with this understanding within the pair of programmers, adjustments can be done to who is “driving” and “observing”. It is understandable that everyone is different and may get irritated or otherwise, but the assumption is that two reasonable individuals are coding a solution up and have no other option but to get the work done. Since everyone is human, one should support the other on the bad days and not to expect the other to catch up during the extremely good days, with such a mutual understanding and respect, colleagues would respect each other rather than risk hatred.

 Conclusion

All in all, I believe that taking the pair programming approach every single time when coding is a practical technique and will not cause the programmers in pairs to hate each other. The idea is that two people approaching a problem is always better than one, as it reduces the amount of mistakes made and ensures that in the future there will be less problems. Pair programming is based on mutual respect and consideration of others’ opinion, which provides confidence in the solutions implemented and provides many opportunities to learn. When working this close together and relying on each others decision it is difficult not to remain on friendly terms as trust develops over time.

 References:

[1] Dominic Williams: Don’t restrict pair programming to difficult tasks, http://www.dominicwilliams.net/en/pair_diff.html

[2]Cockburn, Alistair; Williams, Laurie (2000). “The Costs and Benefits of Pair Programming” . Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000).

[3] Pair Programming wiki,  http://c2.com/cgi/wiki?PairProgrammingQuestions

[4] Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries. “Strengthening the Case for Pair Programming.” IEEE Software. IEEE Software, July–Aug. 2000. Web. 4 October 2013

Accepting Agile: Too Many Variables, No Single Formula Exists

When taught, we are given the impression that agile and plan-driven software development methodologies contradict each other completely. However, to my mind, this is not true and the solution is to find a healthy balance of the two. This idea is conveyed in the article “Management Challenges to Implementing Agile Processes in Traditional Development Organizations”[1] by B.Boehm & R. Turner. It argues that it is difficult to integrate the agile methodologies within companies with large legacy systems. Also, the authors present many reasons and suggest possible solutions.  While agreeing with the article’s claim, I was surprised, by the wide range of challenges that need to be overcome, as you are forced to look at the big picture of the whole company. I would like to add my own observations from the industry and highlight some of the reasons why I think there is no one clear approach in integrating agile methodologies within traditional companies, as there too many different possibilities.

Restructuring: Starting from Scratch Not an Option

Agile software development principles are rather recent and innovative when being compared to other methodologies such as the text-book example Waterfall and others. Hence, many significant software projects of successful firms have foundations that are directly incompatible with agile software development, since they are difficult to refactor and unfriendly to the short development cycle of an iteration. However, this is an obvious incompatibility that needs to be handled, the two software development models are different.

A less expected factor that influences the use of agile is the size of the team and the scale of the project. Agile is known to work on small projects, with a team of a few people working to solve problems, where as the legacy systems tend to be large with a larger set of people working on it with different responsibilities. Within agile, close collaboration is needed within team members, hence the tradition of scrum meetings. This may be difficult with large teams and may take more time than expected. Also, it may cause various logistical issues within a corporation if the teams are split across countries[2]. Hence, some sort of re-organization is needed that should be tailored to the company’s needs.

As I worked in a team of a larger company that is trying to take up agile with a spin off project of slightly smaller size, the size of the team was still quite large. The team had representatives in three different time zones, however after making working hour adjustments, scrum meetings could be organized daily for the whole team to attend. Having said this, not every company can afford international calls or accustomed working hours, which once again leads to no clear one solution.

Planning: Always Expect The Unexpected

Plan-driven development is based on the idea, that the original estimations and requirements will not undergo great changes. Which is used in larger companies, as in this way it is easier to plan the business model. Unfortunately, change is often unavoidable. The agile principles try to accept these changes by developing in short iterations, without any large future vision in order to adapt to short notice changes. This is a very controversial topic, as agile principles may lead to the success of the project due to catering to the latest requirements. However, to do so in larger firms a plan has to be made in order to estimate scope, cost and length[3]. Also, multiple teams work in related products, and constant change would slow down the development cycle. A possible approach would be to plan ahead and make estimations, set a goal, and then organize sprint planning as well as development iterations in order to make the original aim come true with adjustments need to be made.

Referring back to my experience in a larger firm, one simply cannot anticipate everything from the beginning. For instance as, I was working on my project for which I had set myself clear goals on a strict timeline, I found out that there was a security issue if I took the original approach. This happened because the systems are large and different parts have different specifics. Obviously such an issue had to be addressed straight away and supplementary modules needed to be built, which took time and changed the timeline.

Unfortunately, facilitating the acceptance of constant change is difficult because it is difficult to tell the difference between a reasonable and timely change and the time and cost needed to implement the alternative solution. Hence, the call has to be made on project or even change basis.

Developers: Old Habits Die Hard

An astonishing discovery was the difficulty of making sure that software engineers understand and are willing to undergo changes. Traditionalist developers favour a more plan oriented approach due to the belief that it is more predictable and safer, while the new younger developers are willing to avoid the “crushing weight of rushing bureaucracy”[3] and accept the fast pace change in technology. It is evident that there exists a difference in generations of developers. This is because software is being built by programmers and their valuable experience with other methodologies cannot be ignored. People may find it difficult to adapt or may be stubborn and not want to accept the changes.

Agile requires a change in team dynamics and management. As in agile teams engineers tend to be “multi-taskers” rather than have a certain role, which is what many are accustomed to. In this case  merging the two ways of thinking may be difficult. The project manager has to be willing to accept that within a more agile team developers are more flexible and share tasks with respect to urgency and availability. It is their responsibility to face the Human Resources Management when it comes to assigning “roles”[1].

In the team I worked with everyone was willing to pursue the changes, but the concept of “roles” was still evident. To minimize that regular deep dive sessions are organized, where employees share their knowledge. It could, be seen that every step was made to accommodate agile within the traditional methods. However, this is only a solution, as there are too many variables to guarantee success of such an approach indifferent environments.

Stakeholders: Raising the bar

The relationship with stake-holders also needs to be taken into account, which may seem of less significance in the first place. In larger firms, that are used to plan-driven development, the requirements are agreed with stakeholders at the beginning. However, agile raises the bar: stakeholders have to be much more involved and willing to collaborate. This is challenging for both as stakeholders have to become available, even if they have other priorities, while developers have to be ready to receive feedback and may need to implement short notice changes[4].

This is handled differently by corporations, as the stakeholders differ. I was lucky to work on an internal product, for which in order to get feedback from a stake holder I could simply pick up the phone and make a call. However, once again this may not always be possible and other arrangements have to be made.

To sum up…

At university we are taught about applying method A and applying method B on separate occasions. The realisation that I have made is that the key to success is to learn to apply the best from (A+B) with respect to the given situation. However, this is not easy as there is a shockingly large amount of things to consider at an attempt to obtain the best out of two contradicting solutions. In this particular case one has to take into account the already existing software systems of the company, developers, stakeholders, the business model, team size, and available budget. All the variables have to be weighed with risk and the best approach should be reached for each situation.

References:
[1] Management Challenges to Implementing Agile Processes in Traditional Development Organizations. B. Boehm, R. Turner. IEEE Software September/October 2005.

[2] Disadvantages of agile Development. Kelly Waters, 2007. http://www.allaboutagile.com/disadvantages-of-agile-development/

[3] Get ready for agile methods, with care. B. Boehm. IEEE Computer 35(1):64-69, 2002.

[4]Agile Modelling: Overcoming Requirments Modelling Challenges. http://www.agilemodeling.com/essays/requirementsChallenges.htm