Author: s1330485

Design Patterns are getting popular in recent decades. Most of the employers would ask questions about design pattern in the interview with applicants. It seems to be an essential skill that software developers must have to find a good job. Most of the companies are more or less using some of the design patterns in their products because it can bring them huge advantages. However this article tries to explain that design patterns are not almighty and understanding the concept behind design pattern is more important than knowing how to apply them.

Why to use design pattern

Software usually consists of tens of thousands lines of codes. Code consists of two parts, data structure and algorithm to implement some functionality. Software also consists of two parts, codes and design pattern. A complete software will integrate those small pieces of code to make them work together and this how would different piece of code be organized and designed to cooperate to deliver a complete system is a reflection of design pattern. For the same problem different people may have different ways to organize their code,logic to solve it. Design patterns are reusable standardized solutions to typical problems that frequently occur. They have proven to be the optimal approaches to solve specific problems.Apply the existing design pattern means one does not have to work on a problem that has been already solved by others. Also design patterns are useful in creating a shared vocabulary in a large team[1].

It’s very hard to use design patterns appropriately

Even though we can benefit from applying design patterns in our projects, it is very difficult to use them appropriately. People are very likely to fall into a trap that they want to use a design pattern not because it can solve the problem but simply because they can use it. It happens a lot to novice developers who fell in love with design patterns because of the beauty of the excellent design or obsessed with the feeling that they are being professional. This attitude will normally lead to abuse of design pattern. Applying the wrong pattern or needless pattern will unnecessarily increase the complexity of the code and increase the cost for testing and maintenance etc. Also there are criticisms on design patterns saying that the emerging of design pattern is a sign of lack of corresponding feature of programming language/framework. For example the Singleton, can totally be replaced by developing a new feature of any programming language to ensure there is only one instance of given class.

What do we actually need from design patterns?

As I mentioned in above section, sometimes developers use design pattern even when they do not understand why they are using it. Then it comes to the question that when to use the design pattern or what do we get from design pattern. To me it is the concept behind patterns which is important rather than the actual patterns. When it comes to the real software development, chances are the real problem we are facing usually is very complex and do not fit with any single existing pattern. With the knowledge of concept behind the patterns, we can accordingly modify/combining the existing design patterns to cater to the specific requirements. Design patterns are like a set of screw drivers of different shape and size. We need to know how to create one rather than how to use one because the bolts’ size are all different. We may find a suitable one but not a perfect one.

It is not all about design pattern

Software is not all about design patterns and there are lots of other things we need to take into account, for instance performance,maintenance cost and testing etc. Sometimes applying a design pattern can create decent and clean code but we may need to sacrifice for other reasons. For example, if you are developing a web-system to generate analytical chart for users. You may want to apply a template pattern to achieve a better code re-usage, which means code on the server side to generate the chart and only return the chart to client. However in reality no people would do that because the server has to do the work of both filtering data and generating charts. That will increase unnecessary burden on server. One would possibly do is to put the presentation on the client side code, so the server only need to filter data and let the client side to generate chart based on the returned data. This would possibly lead to some duplicate codes but it is necessary cost to achieve better performance.

Summary

In this article I have shortly describe what is design pattern and its advantages. Then I tried to convince the readers that it is very hard to fully understand design patterns and apply them appropriately. Furthermore I made the point that what is valuable to us of design patterns is its concept. Understanding of the concept is required to avoid abuse of design pattern and to make more reasonable design given a specific requirement. As a conclusion, it is good to know design pattern but do not attach to it. It is just a set of general approach to certain problems, not a big deal. Do not treat it like something you can show off then it will be very useful.

References:

[1] Allan. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/415

[2] Design Patterns wiki page. http://en.wikipedia.org/wiki/Design_Patterns

[3] The pros and cons of adopting and applying design patterns in the real world. M.P. Cline. Communications of the ACM, 39(10):47-49, October, 1996.

[4] Design Patterns: Elements of Reusable Object-Oriented Software Gamma, Helm, Johnson, and Vlissides 1995, Addison-Wesley, ISBN 020163361X.

 

This article is a response to the post ”Conservatism has no place in project management”.

In this original post, the author stated the fact that project managers often refuse to accept new technologies in their project which is way too conservative in the author’s point of view. Instead, it was suggested to always try new technologies because the version control guarantees the changes are safe. If things do not work out then revoke the changes and go back to the old version, only certain amount of time was wasted, nothing else. I disagree with this and I think the author has oversimplified the situation. If the adopted new technology were eventually proven to fail, things would be a lot worse than just “losing an unmeasurable amount of time”. Chances are it will be working perfectly in the beginning and start to present the shortcomings(caused by requirement changes/new features) after a period of time. This could be as long as weeks or even months. It would be a disaster to roll back to the version of months ago. Even it is been promptly stopped after two weeks, it is still much worse than it sounds like(two weeks can be as long as an integration in agile development environment).

New technology is attractive, but just attractive

The author believed project managers often over estimate the cost of learning new technologies and underestimate the benefit of that. I agree to the first part of it(over estimate the cost of learning new technologies) however disagree to the rest. Experienced developers can easily learn a new technology in short time and most importantly they are keen to learn new things! The fact is developers will get bored by using the same technology and repeating the same thing all the time, they have the passion to learn. However, I doubt how much value it would bring by adapting new technologies. Illusions are new technologies will outperform old ones because they are more advanced, have more useful features etc. It is undeniable that new technologies can perform better than the old one, but not always. Too much focuses on these advantages would leave the negatives ignored; the new technologies are new! A technology is new means that there are few people using it, limited resources about it, little help you can get on it. There are lots of potential bugs it new technologies have not been observed yet and expected to change in the future. This means unstable and certainly it is not something we want. Technologies are nothing more than tools to us. We use them to solve things rather than causing problems or get hurt someday in the future. Old things are proved to be true and strong while a lot of uncertainties in the new ones. There are a lot of risks in adopting new technologies and it is a critical decision to make.

Think carefully before move

New technologies can bring us beneficial then why we do not use them? We will, but not so quick. It’s too risky to adopt a new technology without enough research on it. We need to make sure that we can certainly benefit from it while the risks are acceptable. Based on my software working experience, a good idea would be assigning someone knows the current system well to evaluate the new technology. This step is essential because it tries to minimize the risks. A full study of the technology would include speed, performance, robustness, maturity, ease to use, cost of employment etc. Also we have to evaluate the possibility of affecting the current system in a bad way(slow down/break up some features)and if it is suitable in the context of our circumstances and any other factors it may affect the system. After we have made a thorough evaluation of the new technology and the result shows it is a good idea to introduce it to the system then be brave to do it without any hesitations. As long as we can control the risks, new technologies are our best friends. So we should not fear them, instead, any possible new technologies are welcome to be brought on the table for discussion because they can make our life easier and enjoyable.

Conclusion

Adopting a new technology in a large-scale long-term software development is valuable while very risky. The author of original post thinks that many project managers have been too conservative to waste the potential benefits a new technology may bring. I agree the author’s opinion that we can benefit from new technologies but disagree with it because the author seemed to be underestimating the risks behind it. I have elaborated on these in the post and suggested to be proactive to think any possibility of employing new technologies but do a full research and think carefully before the actual move.

In this article I will identify and distinguish two different types of estimation in large-scale software development. Also I will discuss the techniques to improve the accuracy of estimation for each of them. I will use some examples and analogy to illustrate and prove my points and hopefully every reader can easily understand it and learn something.

Estimation is hard!

There are some facts about estimation that few people dispute them. Usually the estimation work is done at the beginning of the project with poor requirement specification by hand. Some project estimations are even performed only with a rough idea. It is determined by the nature of the project, most of the time it is more like a demand. For example, think about the time that cloud storage services were not that popular yet. There are several companies can expand in this market and could earn massive profits. Now the companies have decided to develop a running project as quickly as possible or the market share will be obtained by the rivals and then put a deadline on the first release, say three months. In this case, three month is just a demand rather than a completely reasonable plan. Even though this estimation is not necessarily bad because anyway it can be achieved by modifying the requirements accordingly[1], but it is definitely not a good estimation because that was coming from the customer requirement(strategy of the company) rather than from the project itself[2]. Early and continuous release can perform very well with small projects but it may cause refactoring and other issues when it comes to large-scale projects which will make it more difficult to estimate. It is fairly easy to estimate and control when the project is small but it becomes more and more difficult when it scales up. Till here, we have reached the conclusion that estimation in large-scale software development management is hard.

Estimation is not always hard!

If you are familiar with Agile development methodology, then you’ll know the entire development process will be divided into small iterations which are often one to three weeks[6]. There is estimation involved in each iteration. Each iteration will be given a theme and include tasks picked from the task backlog which are considered to fit the developer’s capability in terms of time. Imagine a developer team of 10 people. For a two week iteration, the total time capacity of the team will be 10*8*5*2 = 800 hours(8 working hours a day, 5 working days a week). That means tasks worth total number of 800 hours work can be picked and put into an iteration and that requires an estimation of each task. In the beginning of each iteration, there is a group meeting in which those estimations will be made. Now, the estimation here is way different from the one mentioned earlier happening in the beginning of entire project. Each iteration can be viewed as a small portion of the whole development process and each task is even a smaller portion within the iteration. That is to say a task(which we’re trying to estimate how much time it would need to be finished) is very specific and small compared to the entire project. Small fraction means that it does not have much potential issues which may cause delay. In other words there’s little interference to be considered and easy to estimate. Also these small pieces of work are usually measured by hours and any mistakes in estimation would not make too much differences. Two hours variation is nothing compared to two months. Also it is more flexible when we are talking about hours instead of months. For example, a developer spent two more hours on a task than it was originally estimated. He/She can easily catch up on other tasks. Based on my work experience, a Scrum team of about 20 people can produce fairly accurate estimations on tasks.

Ways to improve the accuracy of estimation

Now two different types of estimation in large-scale software development management have been identified. In order to improve the accuracy of estimation, different techniques have been developed respectively for them. COCOMO and poker playing are used as examples here and we can find out that they are totally different techniques[5]. The techniques for improving estimation accuracy of entire project/components/modules are usually involved with lots of mathematical and statistical equations. COCOMO is a mathematical equation that can be fit to measurements of effort. The simplest form of COCOMO consist of as many as 4 factors including the complexity factor, measure of product size, exponent and a multiplier to account for project stages(Details of COCOMO will not be given in this article because we’re only interesting in the comparison of the different techniques of how they would work). There are other methods like Standard Component Estimating but similarly using mathematical techniques to make the estimations more accurate.

Now let us have a look at what people usually do for the estimations for small tasks. Poker game! It looks informal and less complicated and much more funny than the COCOMO even by the name. And it truly is. The poker game is just a group of people having cards in their hands and giving their estimations to each task on the list simultaneously and anonymously. When there’s an objection then people exchange their opinions and re-play until there is an agreement. Simple like that. It is very easy to apply and useful. Again because the task is small so it is easy to estimate and any experienced developers can give accurate estimations on them. Compared to COCOMO, it is more subjective because the estimation is made based on the developer’s experience.

 Summary

In this article we discussed two different types of estimation in software development. One is early effort estimation of the project and other one is the estimation of small tasks with each iteration of the entire development process. Though both of them estimate the effort, timeframe and cost involved in delivering a project[4], there is a great disparity in the importance and level of difficulty. Estimate gets easier to make when it proceeds to the end of the project. Early effort estimation are made in the beginning of the software lifecycle which means the wrong time, and usually by wrong people for wrong reasons. No doubt that it will be very hard. The large-scale software management is risk management[8]. From the entire project’s point of view, there are lots of unknowns and risks. So the estimation would be used to give a big picture of it and steering the development process. Different from this, estimation for small tasks within each iteration has a very clear specification and know exactly what to be done. It is just a matter of resource allocation(management). That is assigning the right person for the right task(For example, one developer who is familiar with the component/modular involved in a specific task should spend much less time than those never worked on that component before).

Let’s finish this article by an analogy with hiking[7].So the project is to hike on the coast from San Francisco to Los Angeles. We should start with some planning like draw the route on the map and calculate the distance. Say it is about 400 miles long, if we can walk 4 miles per hour for 10 hours per day. It will be accomplished in 10 days. Now, the 10 days estimation is the outcome of early effort estimation. OK we are packed up and ready to go. On the first day, we are supposed to get past the Half Moon Bay. Before that, we have to get away from the city. So here’s the plan: 3 hours walk from home to the coast and 7 hours of walk along coast till we get past the Half Moon Bay. Getting to the coast from home and past the Half Moon Bay can be reviewed as two tasks in the first iteration(day one) and 3 hours and 7 hours are the estimations for them respectively.

 

References:

[1] Allan Clark, Software Architecture Process and Management lecture, University of Edinburgh. http://www.inf.ed.ac.uk/teaching/courses/sapm/2013-2014/sapm-all.html#/Estimation_Lecture_Start

[2] Get Ready for Agile Methods, with Care. http://dx.doi.org/10.1109/2.976920

[3] Estimation is evil. http://pragprog.com/magazines/2013-02/estimation-is-evil

[4] Dynamics of effort estimation.

http://www.techmachina.com/2006/11/dynamics-of-effort-estimation-in-most.html

[5] Cost models for future software life cycle processes: COCOMO 2.0 Boehm, B., Clark, B., Horowitz, E., Madachy, R., Shelby, R., and Westland, C., Annals of Software Engineering, 1995

[6] Manifesto for Agile Software Development. http://agilemanifesto.org/

[7] Estimation Analogy with Hiking. http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe

[8] Large-Scale Project Management Is Risk Management. R.N. Charette. IEEE Software, July 1996.

[9] Combining Estimates with Planning Poker–An Empirical Study. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4159687