Vukoje.NET

Last night I have held presentation about Coding Standard and Code Review at Microsoft Serbia quarters in Belgrade. This was resumption of previous presentation on Code Refactoring. In amazing 3 hours I have managed to break every record (rule) regarding presentation length, so I want to thank all of you who came and survived. I know it was hard but I can only hope that it was useful.

For all of you who are interested in these subjects but couldn’t make it, I will be holding these two presentations in November at Sinergija.

You can download presentation here or browse it online here, and see photographs here.

Here are some useful links:

• Style Cop team blog
• Code Analysis team blog
• GhostDoc
• FxCop Warnings
• How to hold a more effective code review
• Checklist of things that you should look for during a code review

... And here are some funny links

• KLINGON GUIDE To Writing Perfect Code
• Cargo cult programming
• Unusual software bugs

In my previous blog post, I have stated that communication is very important for programmers, and maybe essential for successful teams. Today I want to clarify this subject by defining jet another guideline: Two heads are smarter than one. What this means is that two people are more likely to solve some problem faster and better.

Let’s put this in context of real programmer’s working day: you are trying to solve some problem, you cannot find good enough solution or you cannot decide which alternative solution to choose or how to organize your code, you aren’t sure will underlying technology cause problems…

What can you do about it?

You can do your best to focus, you can “google” solution all day long, you can pool out your hair trying to fit all that information in your head at once… or you can just ask for help person sitting next to you.

Often it is enough to try to explain some problem to another person and to see for yourself where you have gone wrong. If this doesn’t do the trick, your colleague already has advantage over you in solving the problem because he is approaching it from a different angle. It can be that colleague is more expirience with that kind of probelm, or that he is the developer who wrote original peace of code. Maybe he has already solved that problem, maybe he read something about it on the Internet, or maybe he knows that someone else in firms knows solution. It may also be that he is smarter than you, which again is great thing because what’s important is that problem is solved with little effort and that you learned something.

If all of these positive sides of communication didn’t solve the problem in first 2 minutes, you and the colleague are left to use power of brain storming, to inspect solution variations and alternatives.   The catch with programming is that it is very complex and that if some problem is not solved 100% than it isn’t solved at all. You can’t say to your customer, “I can obtain all data you need but I don’t know how to show them to you, can you pay me half?”  Sometimes you solve 95% of the problem for few minutes, and can be left struggling to solve rest 5% for days. Maybe your colleague has 50% of the solution, but it includes your missing 5%.

Other great thing about this rule is that motivates people to share problems. Beside the advantage of collective problem solving, it is great means for informing others about project state and sharing knowledge patterns in form problem -> solution. This way, some programmer is less likely to get stack solving problem that someone have already solved.

Few years ago my friend Aleksandar Mirilovic gave me an advice "No mater how small and easy project is, never work alone". At first I wasn't happy with idea but today it is an apsolute truth for me. What happend meanwile is that I have been working on mantaining a large project for two years. During that time I learned that some times you colleague can solve the problem you are working on in few minutes and that without his help you would be working on a problem for whole day.

So if it is that simple, why don’t we use it then?

Maybe it is because of our ego, because we like challenges or because we are afraid we will look stupid. The real chalange is to finish you task in simplet and fastest form using all available resources, and colleague sitting nexto to you is friendliest and most user friendly resource you will ever have. Use your colleague and don’t worry, he will share his adventures with you soon enough. Programming is hard enough, don’t make it harder on your self, use all the help you can get.

Yesterday I held presentation about Code Refactoring at Microsoft Serbia quarters in Belgrade. Main focus of this presentation was how to improve quality of code and what are the benefits of code quality.

Because of the last night games, we didn’t cover Coding Standard, Code Review and available tools for checking code quality and refactoring it. These topics will be covered in next presentation for which date is not yet set. Below is last night presentation. If you have any questions about it, please share them with us, I would be happy to apply.

You can donload presentation here or browse it online here.

Few months ago I found out about a book How to Win Friends & Influence People by Dale Carnegie that was recommended by Joel Spolsky:

Finally, and I know it sounds cheesy, but Dale Carnegie’s 1937 book How to Win Friends & Influence People is actually a fantastic introduction to interpersonal skills. It’s the first book I make all the management trainees at Fog Creek read, before anything else, and they always snicker when I tell them to read it, and love it when they’re done.

Well, book did sound really cheesy. Accidentally I came across this book in audio format which duration was little more than 5 hours. The book was short, simple, pragmatic and surprisingly reviling. It focuses on people relations, communications and misunderstandings. The whole book is composed of real world anecdotes so messages are clear and very easy for listening. The book main lesson on people relations (in my own interpretation) is: listen, understand and respect other. For summary of all advices see this link.

Who is this book for?

Well book title sounds like a weapon for some insincere and manipulative manager, but turns out that it contains useful lessons for everyday life and surprisingly useful in everyday work of  an engineer.

Programmers and Communication

Programmers, probably like any other engineers, aren't focused so much on people relations in every day work. They are focused on technical issues that are very much enough for consuming person's whole taught in one day. Problem is that problems being solved by programmers tend to be complex and like that are better solved when more brains are involved in synergy. 

Problems being solved by programmers are such that there is no “one right solution”, so informed decisions must be made by team members on daily basis and all team members should be aware of them. Usually, decision process consists of every man contributing with ideas. All ideas are valuable in some way but small amount of them will be accepted. This can lead to broken pride and programmers are known to have ego issues.

From all said above it should be clear that good engineer should also be good communicators. If we take a look at Scrum, we'll see that basically Scrum Master is playing role of communication facilitator in software development. That’s how important is communication in Scrum.

Avoiding Confrontations

One of the best advices I have received from this book is “Avoid arguments, you can only lose”. This is important because design sessions can easily go from technical to emotional arguments and no matter who is right, arguers will defend and embrace their previous positions. In the end even “winning” will hurt the loser’s pride and build resentment.

A Guide to avoiding arguments:

1. Welcome the disagreement. Be thankful for a new opinion.
2. Stay calm.
3. Listen first. Hear your opponents out.
4. Identify areas of agreement.
5. Admitting errors will make it easier for others to admit theirs.
6. If no resolution is found, postpone action and promise to explore the opposing perspective

Last month I have attended Scrum Master training at Faculty of Organizational Sciences in Belgrade. My mentor was excellent Dan Rawsthorne, with huge experience in production and strong hold in agile development. His experience gave his opinions huge credibility and his agile approach gave me a completely new view point to Scrum compared to one I have gained from Ken Schwaber’s book.

Here is list of my most interesting notes from training:

Agility:

• Brains solve problems, not processes. Process should only exist to enable focusing on brain power. Scrum is designed to force us to make hard decisions.
• Agility is opposite to prediction. We can not control the world, we can only adapt to it and that requires constant attention which is hard. Waterfall gives illusion of control and false comfort.
• “Every team member is doing the best they can, but not the best they could be doing.” This is really interesting statement and I think that one should always remember it when evaluating and improving team abilities.
• Programmer’s job is to create value, not to write code.
• Perfect is the enemy of good. Good is what we want, perfect is impossible.  
• There are no “I don’t knows” in Scrum, every decision has to have good reason which should be known to all (or most of) team members.
• Scrum is about committing, not about knowing. If you focus on knowing, you will be too slow. If you are not sure, build something and get feedback as fast as possible. You are committing to agreement, not to tasks. Tasks are there to help you commit. Do something and than get better.
• You can not build quality back in to the code, you can only replace it. Regular questions like “Has anyone written code he’s not proud of?” can help identify problematic implementations. If they can’t be addressed right away, related correction tasks should be added to product backlog.

Organization:

• When product is reviewed on meeting, developers have urge to demonstrate unfinished functionalities and demonstrate only happy paths in Use Cases. Unfinished functionalities create false impression of faster product development which can only lead to shortening of deadlines and later confrontations with stakeholders. “Happy paths” often hide real world usage scenarios that are most problematic and that should be discussed the most.
• Always time box exploration tasks.
• Scrum Master can lead only one team because it is full time job. SM can also be team member, but you have to bear in mind that his team duties can lead to neglecting of SM responsibilities. SM shouldn’t be Product Owner because that would concentrate too much power in one person that can destroy self organization and initiative if SM doesn’t control his urge to control. Micromanagement is obstacle to self organization.
• At the end Product Owner is the boss (decision maker). Team can only do it’s best to prove its concepts. PO has veto powers all the time, but he should control urge to use them.
• Scrum doesn’t fit teams that aren’t constantly trying to improve them selves. If you can't imagine your tem being self organized and taking initiative, then that is probably because you really can't, and no methodology will help you.

Previous weekend I was preparing for gaining Scrum Master Certificate. If Scrum is new to you and you are interested in it, I strongly advise you to take a look at this video where one of the Scrum inventors is talking about its implementation at Google.

In preparation for Scrum curse I have read Agile Project Management with Scrum by Ken Schwaber. The book is excellent and I recommend it to anyone interested in Scrum. Thing I liked the most about it was the way book was written. Main thing about Scrum is that it is simple, pragmatic and lightweight and the book is just the same. Book is short, simple and knowledge is passed to reader through real world examples. Most of these examples were examples of Scrum misusage, which are extremely valuable because they keep us from repeating common mistakes and at the same time enables deeper understanding of Scrum driving forces.

Next thoughts were most interesting to me:

• Role of managers is to shape the organization not through the power of will or dictate, but rather through example, through coaching and through understanding and helping others to achieve their goals.
• There are three legs that hold up every implementation of empirical process control: visibility, inspection and adaptation.
• Scrum uses power of time-boxing to instill the art of the possible and avoid pursuit of perfection, the practice of incremental delivery to improve engineering practices, and the practice of empowerment and self-organization to foster creativity and worker satisfaction.
• Every increment of potentially shippable product functionality that is demonstrated at the Sprint review must be done. Done means it contains all analysis, design, coding, testing, documentation, and anything else appropriate for application.
• Many development teams accept the risks and don't discuss difficulties and options with stakeholders until the end of the project. This is natural result of an environment in which developers don't really know where the project stands any better than management does.
• Scrum relies on high-bandwidth, face-to-face communication and teamwork. Cubicles and unneeded artifacts promote isolation and misunderstandings.
• Build the infrastructure for scaling prior to scaling and always deliver business value while building it.
• You can get through almost anything if you don't try to impose rigid solutions before problems even arise, instead devising solutions as necessary when problems crop up.
• Retrospectives that don't result in change are sterile and frustrating.
  
  

In my previous post what to code next, when I discussed choosing next module for building I completely ignored importance of business value and ROI (return of investment). This was noticed by my dear friend Aleksandar Mirilović (who's blog is still under construction) and confirmed in Scrum. Fact that something has greater business value or is urgent can not be ignored. Also business value is excellent test for early system architecture. If you respect ROI and deliver complete functionalities at the end of each print, you will be able to go live with incomplete product at any time, which I argue is very valuable flexibility for business.

In my next posts I will cover things I have learned in course so stay tuned.

Do you have any real world experiences with Scrum? Are you planning to?

This week I have attended Microsoft one day conference DevDays 2009 committed to fresh and soon to come Microsoft development technologies. Excitement as one geek can be, I still was annoyed by new technology rush, so I wanted to share some of my taught on that subject.


Term explosion

When ever I hear about new things I find my self in mental process of translating them in set of terms that I understand. This probably is related to lack of IQ but it is mainly due to term explosion. Every new thing that comes out has to have some cool name although problem is widely known and defined few decades ago. Please, don’t do this.

Technology and problems

Technology is here to solve problems, so to use it you first need to have a problem for solving. If you don't have problems, new technology will bring them to you. New technology needs to be learned and the God knows what errors it has. Yes, I still have urge to use newest, fanciest tool, but can I justify it to my manager? Best thing to do when you get existed about the new stuff is to ask what are the technology faults, and rest assure it does have them. Following are some of the question:

• Will it take too much time to learn it?
• Will other developers except it and learn it good enough?
• Are enough resources available?
• Are there any major issues?
• Will the product be supported over next few years?
• What about performance? 
• What are software and hardware requirements for running it?
• Is the software mature and fast enough?

I will quote Facts and Fallacies of Software Engineering:

• Hype (about tools and technology) is a plague on the house of software.
• New tools and techniques cause an initial loss of productivity / quality.
• COBOL is a very bad language, but all the others are so much worse. 

Examples

Workflow Foundation - When I first saw it I went nuts. I taught it is the next big thing. Today I can't imagine any use of this technology in my everyday work. I guess that some software houses working on software with extremely big and complex business processes that need to be configured at runtime by business users can find good usage for it.

WPF - No tools, no GUI controls, slow. Will be standard in future, but for now I don't want tell customer to buy better PC so he can run my address book.

Linq to Sql - This technology is dead, so I don't plan to use something depreciated by manufacturer. I have bean there with UIP and it is not a happy place.

Entity Framework - I am most exited about this one, but it is simply not mature and stable enough and there are very little resources. On PDC presentation it was clear that they still aren’t sure what will next version look like.

When you want to do something, next question always comes up “What should we do next?” The answer will differ if you are making decision what module to develop in next few months, or you are wondering what functionality to code next. 

Choosing next module

When you pick a development task for a longer period, always pick the hardest one. This approach is also called “Swallow the biggest frog first”. This means that if you will be developing some software in period of one year, in first quarter you should tackle all biggest risks and most difficult implementations. These hard problems must be solved before project is completed and if you delay them:

• they will only become harder because already implemented components introduced higher complexity
• you will not have sufficient time to solve them because you already burned big amount of time solving less important issues
• it is more likely that important feedback will come too late when too much time and money is spent 

This approach will lead to early pain in project, where you have large problems right on project start. You should cherish early pain because alternative is slow and painful project death.

Choosing next functionality

When you are choosing next feature the code, choose the smallest/simplest one that will work. If you choose simplest possible task, you will be able to:

• implement, test and check in your code easily and quickly
• you will reduce chances for making a mistake because work is small and simple
• you will be less stressed because there will be less things that you have to hold in your head
• undo all changes and start from beginning if you get lost or insecure

I have stolen this principle from TDD and Refactoring principles.

Often when something is being built, the question comes up “How far should we go with this?” If you are building application data access layer, the questions can be:

You could go with all or nothing solution and spend few years building data access layer. This approach is also called gold plating,  and is always wrong approach because customers won’t wait 10 years for you to achieve perfection in data access. The right answer is to do a minimum that works. In previous example you probably won’t need support for multiple types of database nor advance domain object mapper.

If you do a minimum that works, you have: 

This is true for code, as it is true for documentation. If you try to gold plate your requirements you will end up with such amount of documentation that no one will want to read it. Also to much trivial information can hide important information. It is situation when you can’t see forest from trees. Look at this excellent experiment that shows that you can do more with fewer requirements (Thanks to Vojin for link).

It is important to stress out that doing minimum that works doesn't imply minimum quality. I can only think of three situations where low code quality is acceptable:

In my earlier posts I have written about why should software be documented and what should we document, and today I will write about software requirements. Requirements are written documents that describe system that should be developed and serve as communication tool between customers and developers. Requirements are also thinking tools that help you understand what you need to build so you don't waste money building the wrong thing.

"The very act of writing a specification forces you to think through the design you thought you had in your head, and helps you see the flaws in it quickly so that you can iterate and try more designs. Teams that use functional specifications have better designed products, because they had the opportunity to explore more possible solutions quickly. They also write code faster, because they have a clearer picture when they start of what’s going to be needed." [Joel on Software]

Approach to writing requirements

You can organize your requirements in more or less formal or agile fashion but the main point in requirements isn't the document templates and complex diagrams. The main point is information. I learned this from few starting chapters of Writing Effective Use Cases (Alistair Cockburn). I was expecting to find template for Use Cases that will help me write better documentation, and instead I found out that approach to writing documentation is more important than document template.

Amount of written requirements