50 Web Performance Tips and Tricks
 

I came across the below video on the web performance improvement tips and tricks. This is fantastic.

http://channel9.msdn.com/Events/Build/2012/3-132

In this video, Jatinder talks about Six fundamental principles for improving web application performance. He also talks a lot about how we go about Decreasing CPU time and increasing parallelism on the client machine to achieve faster web performance.

While I went through the video, I captured all the tricks he talks about. And thought will be useful for others while they watch it. Please find below the tricks.

Quickly respond to network request

  • Avoid 3XX Redirections (63% of top websites use redirect)
  • Avoid Meta refresh
  • Minimize Server time for Requests
  • Use Content distribution Networks (CDN)
  • Maximize concurrent connections.
  • Reuse connections – don’t sent connection close.
  • Know your other servers – you are only fast as your weakest link
  • Understand your network timing

Minimize bytes downloaded

  • GZIP Compression Network traffic
  • Persist application resources locally (Windows 8 applications)
  • Cache dynamic resources in the application Cache (html5 app cache)
  • Provide cacheable content
  • Send Conditional request
  • Cache Data requests (jQuery AJAX calls)
  • Standardize File name capitalization convention.

Efficiently structure markup

  • Load pages in latest browser mode
  • Use http header to specify legacy IE mode
  • Link CSS in the top of the page header, never on the bottom.
  • Avoid using @import of hierarchical styles
  • avoid embedded and inline CSS
  • Only include necessary styles in the page.
  • Always link JS at the end of the page.
  • Avoid linking JS in the header (use the defer & async attribute)
  • Avoid Inline JS
  • Remove Duplicate code (52% of the web have duplicate code
  • Standardize on a single framework

Optimize your media usage

  • Avoid death by too many images
  • If possible use Image Sprites
  • Use png image file format
  • Use Native image resolutions
  • Replace Images with CSS3 Gradients, border Radius
  • Leverage CSS3 Transforms
  • Use Data URI’s for Small Single view images
  • Avoid complex SVG paths
  • Video : Use preview images
  • Minimize media plugin usage
  • Proactively download Future media

Write Fast JavaScript

  • Stick to Integer math (Math.Floor)
  • Minify your JavaScript
  • Initialize JavaScript on Demand
  • Minimize your DOM Interactions
  • Built in DOM methods always more efficient (firstchild, nextsibling methods are faster)
  • Use Selectors for Collection access (document.querySelectorAll)
  • Use .innerHTML to construct your page
  • Batch your markup changes
  • Maintain smaller DOM (less than 1000 elements)
  • Json always faster than XML
  • Use Native Json methods
  • Use regular expressions Sparingly

Know what your app is doing

  • Understand JavaScript Timers (setTimeout, SetInterval)
  • Combine Application Timers
  • Ensure dormant timers are not running
  • Align timers to display Frame (16.7)
  • Use window.requestAminationFrame(renderLoop) for Animations
  • Know when your application is visible (document.hidden, Visibilitychange (event))

Conclusion

The web optimization is not easy and needs exhaustive deep look and hopefully this check list helps while optimizing your pages. Enjoy coding high performing applications. If you have more tips please provide them in the comments.

 

TDD (Test Driven development)
 

There are lots of practices that need to be followed while doing XP as an agile methodology. And one of them is automated testing. However, there is lots of confusion in the tech industry if you want to test the behavior of the system or the subunits/parts of the system. First, lets us understand these terminologies. In this post, we will talk about Test driven development.

TDD (Test Driven development)

TDD or Test Driven development is an approach in which unit tests drive the development of the code. That is, when there is a new feature that needs to be developed, the unit tests corresponding to the feature is developed first before the actual code need to create the feature is coded.

Let’s take an example. Let’s say at a point of sale system, we need to calculate the bill based on the list of products picked by the consumer. Let’s write unit test corresponding to this code. (I have used C# based XUnit as the unit testing framework)

        [Fact(DisplayName = "SimpleBiller Should Calculate Total bill Amount")]
        public void SimpleBillShouldCalculate()
        {
            //Given
            var ProductsList = new List();
            ProductsList.Add(new Product { Name = "test Product1", Price = 5 });
            ProductsList.Add(new Product { Name = "test Product2", Price = 5 });
            var simpleBill = new SimpleBiller();

            //When
            var bill = simpleBill.GenerateBill(ProductsList);

            //then
            Assert.Equal(10, bill.TotalCost);
        }

In the above Unit test, we have 3 parts.

  • Given
  • When
  • Then

Given

This is the known part of the problem. i.e in mathematical terms, it’s part of the problem. In the example, we have initialized the variables and known things corresponding to the products (selected by the consumer) and the Biller object.

When

This is the business action based on which we are writing the code. In this case its GenerateBill action/method.

Then

The purpose of the tests is to ensure that the code/action does it properly as per the plan. In order to do that, we are asserting the assumptions/result of the method we are testing. In our case, we are asserting the total amount that the bill will have to be generated for.

Running the test

There are three stages of running the test.

  • Red – When we run the test now, it will fail as there is no code corresponding to the calculate bill functionality.
  • Green – In order to fix the above test, let’s write the real code corresponding to the above unit test/requirement.
        public Bill GenerateBill(IEnumerable products)
        {
            var bill = new Bill { Products = products };
            foreach (var product in bill.Products)
            {
                bill.TotalCost += product.Price;
            }

            return bill;
        }

Now, when we call GenerateBill method from the test, it will return the Bill with the total amount.

  • Refactor – With the above code written corresponding to the test, we are sure the functionality is correct as per the requirement. But the code is not optimal, as the foreach loop can be reduced to a simple C# LINQ  expression.
        public Bill GenerateBill(IEnumerable products)
        {
            var bill = new Bill { Products = products };
            bill.TotalCost = bill.Products.Sum(x => x.Price);
            return bill;
        }

Conclusion

TDD is a foolproof approach to developing software as per the requirement. The test also provides confidence to the developers on the edge conditions and other possibilities in the code. However, there is an alternative thought that TDD could waste developer time. Do you think, TDD is the right approach to software development? Please provide your comments.

Abusing Agile – Part 1
 

Disclaimer – There is no intention to hurt anybody. The idea is to pass the learning and a MESSAGE. I have seen Agile getting abused and many a times it is visible to rest of the world except the one who is responsible for it. Click on each scenario to get more details.

Scenario 1 – I leave very early because I finish my work and I pick very less because this is all I can do.

Scenario 2  – I didn’t do anything hence pairing was a saver although it was knowledge transition.

Scenario 3 – A standup cannot be a meeting.

Scenario 4 – ‘Sprinting’ means running super-fast.

Scenario 5 – It is perfectly alright to play with estimation at any point in time.  

Scenario 6 – Story point is not about time, not even a range.

Scenario 7 – We will unearth acceptance criteria and requirements for a given story as we continue with development. Writing one liner description for a story should be fine and we will keep looking at it while work in progress during the sprint.  

 

Agile Appraisal – What to consider
 

If you are a manager and above in agile work environment and you need to go with appraisal, you might have encountered situations where what to expect from your team members compare to traditional model.  The focus is on collaboration, pairing, individual ownership for self and team. The “Working for team” culture over work for “self” make it more difficult.  One of the recommendation I have for all the managers or individuals responsible for doing appraisals for agile team is to have  a certain percentage allocated to team success in everyone’s goal,  and further how the team collaborates and how well they work together.  The percentage can differ with experience of an agile team member and expectations what you have from your team.

When it comes to individual performance (obviously there is a percentage attached to this as well which is typically little above than team success), I prefer to look at three factors which covers it all.

1. Competence – Demonstrates strong leadership in one or more areas (e.g., technical, project management, process, etc.). Consistently works to leverage skills for team and larger organization success.

  • Breadth and depth of knowledge and skills
  • Problem solving ability
  • Technical, communication, interpersonal, business skills
  • Leadership and innovation, applied to people, processes, and projects

2. Contribution – Someone who has a lot of initiative, is a leader across the organization, and has outstanding productivity.

  • Ability to meet commitments
  • Overall productivity and volume of output
  • Early communication of problems and contribution to workarounds that meets business goals
  • Versatility – willingness and ability to adapt to new tasks
  • Teamwork – willingness and ability to help others
  • Leadership skills such as architecture, project management, change management, communication, and mentoring
  • Ability to motivate others, manage self, and demonstrate initiative.

3. Value to business – This is very critical. What kind of value you are adding to business. There could be high competence and contribution to build a product while ROI (Return on investment) should never be ignored.

  • Knowledge and skills as mapped to needs of the business
  • Extra points here for unique skills we need

Every agile member should ask three questions to himself/herself frequently

  • Am I learning?
  • Am I contributing?
  • Am I making a difference?

The manager should ask the same questions to himself/herself and same for his team. If the answer is no then appropriate development goals must be planned and discussed.

The biggest goals for a manager should be in while managing agile project should be

  • Sprint success
  • Continuous Improvement
  • Constant Learning
  • Building Self Organizing Teams

 

Why sprint success is important
 

In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.

Fig: Success

Following are the some of the reasons why sprint success is important.

  • Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.

  • Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.

Fig: Habit Loop

  • Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.

  • High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.

  • Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes  bigger than individuals and  deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.

These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.

Why do we need tasks? What is the need of Planned, Actual and Remaining hours?
 

I have repeatedly heard from teams that we have done estimation for stories in terms of story points or t-shirt sizes hence now why do we create tasks or if at all if we create tasks why do we add hours to tasks?  Add to that what is the need for specifying actual vs remaining hours every day for each task. The story is good enough to know what is to be done so why look at tasks. The benefits over challenges are much bigger and you can be truly convinced when you attempt it.

The recommendation is to have tasks created for each story.  Typically individual task should not be more than a day. If that’s the case, break it down further. Almost every task can be practically broken down to meet this criteria.  Once tasks are created, each task should be tagged to approx. hours needed for the same.

While creating tasks not just restrict yourselves to functional requirements while focus on following but not limited to

  • Non Functional Requirements (Performance, Security, Scalability, compliance, accessibility, maintainability etc. )
  • Dependency
  • Constraints
  • Acceptance criteria

The best time to create task is pre-grooming which is done few days ago before actual sprint planning/grooming.  It is my personal recommendation to get as many tasks as possible before you go for actual grooming. You can always convince team how you have come up with these tasks.

I am listing some of the core benefits of creating tasks, assign hours to each tasks during planning, smaller tasks and further constantly entering actual hours and hours remaining

  • The tasks add lots of clarity to story. I always advice individuals to create tasks before actual planning meeting. The pre-grooming done in advance in earlier sprint is when tasks should be created. This results in better estimation further result in better planning.
  • It is always simple to do individual smaller tasks over doing entire story. It is undoubtedly faster better and cheaper option.
  • Having tasks for individual story make it very easy to share your story work with other team members.
  • The hour assignment for each tasks helps in predictability of complete the tasks. The risks can be mitigated much earlier or in many cases it can be avoided during planning itself.
  • The actual vs remaining helps to come up with burndown chart which is one of the core artifact of agile teams. You can always have burndown based on # of items closed or velocity burned but that doesn’t give clarity and adds up little or no value.
  • Adds lot of value to individual accountability as it gives clear picture in terms of who is doing what and whether he/she is taking longer or getting it done early. This is one of the main cause many agile members are not inclined to go and add that much of details. The thinking of to become accountable is not a good idea is in reality bad for developers. More than an organization loss, they are killing their careers.
  • Small victories (after completing each tasks) gives motivation to individuals.
  • You are directly or indirectly reducing assumption on stories resulting success chances getting better. “Assumption is mother of all screw ups”. You can’t run away with assumptions while reducing the numbers helps you to do more.
  • The question which you might ask your stakeholders at later stage is typically unearthed well in advance.
  • In majority of cases better sprint success rate by having tasks and further hours (Planned, actual and remaining)
  • The nonfunctional requirements (security, performance, scalability etc) are listed in advance and these are being considered while planning
  • These NFRs, code reviews, testing etc are never missed. Typically POs encourages to list only requirements those have business values while I always recommend to write all the tasks which you are going to do.
  • The dependencies, constraints are identified. Moreover the acceptance criteria is well covered. The tasks suffice the need for missing SRS (Software Requirement Specifications) in agile projects.
  • The productivity is bound to be better in addition to quality. I have personally worked with tons of teams and experience the same.
  • Better bonding within team as things are BETTER organized.
  • You can better calculate matrices like productivity, cycle time, utilization etc.