Archive for May, 2011
May 30th, 2011
There are two factors that determine an IT project. Projects aim to raise the return on invested capital; the two main enablers are to save money or raise the perceived customer value. Either you become more efficient or you generate new opportunities. There is often a combination of these two where projects aim to both get new opportunities and save money at the same time.
If the first priority is to generate new opportunities and to raise the perceived customer value, the marketers will probably be your customers. And if the main enabler is saving money, you customer will probably be a administrative manager.
Deciding which one is more important – cost savings or opportunities – means analyzing requirements and establishing priorities. You might have several different stakeholders and users and it may be difficult to understand what they really wish to accomplish with a specific feature or demand. That’s when it might be helpful to ask, is this a cost saver or a new opportunity?
If you come up with a plan, you might surprised to learn that your customer will be dissatisfied about cost savings if you developed a project with new opportunities in mind after consulting with various stakeholders and users.
This means that the motivation of IT problems isn’t to solve technical problems; you are foremost there for solving organizational and business problems.
May 29th, 2011
The Agile Manifest says that people is more important than a process. But what if you don’t have a great team that are smart, disciplined and attentive. If you projects consists of three trolls, a senior fresh out of school consultant from Accidenture and a relatively bright project manager, who happens to be deaf, blind and mute. No amount of coaching can help this team to magically self-organize and deliver a successful product. Then rules, micromanaging and a step-by-step process might be the only way. Smart, disciplined and attentive people simply do their jobs well and don’t get ticket for dangerous behavior. And the agile methodologies build an assumption of that you always got the great team. But the world isn’t perfect, sorry all employees. So self-organizing might not work so good for all teams.
Related post: Self-Organizing Teams the most debated Agile Principle
May 27th, 2011
Higher management staff – CEOs, CFOs – CIOs – Business Development – are normally more interested in how products and services reduce cost, generate new revenues, strengthen the trademark and brand, improve customer relations, create new market positions, and acquire competitive advantage. They regard their respective departments as unique and special, so out of the box solutions would probably not be welcome.
Higher management individuals work at a strategic level and their decisions are seldom short-term. It’s therefore important to show them clearly how the solution will support the business. Why should they invest in this? Their perceptions are influenced by those they serve and the costs of providing this service.
Middle management staff – product or system owners, line managers, administrative managers, software development managers and business development managers, ), focus on what their respective business unit does. They are often focus on a specific project or responsibility making sure that the proper “housekeeping” is done so everyone else can work efficient.
They work at a tactical level and prioritize different activities. Their main preoccupation is how to make things more efficient. They do comparisons and benchmarking. Their perceived customer quality is based on the ratio between prices in relation to the perceived value. They are responsible for their assessments of new systems and features.
It is therefore essential to demonstrate to them why the solution or feature they require is produced with cost efficiency in mind and which would be the best solution for them. The keyword for middle management is what. What does the solution, system or service do in particular that it cannot be obtained at a cheaper price elsewhere?
The competitive factor is not price, but the perceived value that can be obtained. They like to know that what they like to achieve is clearly understood. Documenting their requirements is one way to prove that their needs are understood.
Team and Operations Management
Management at the operations level is often very close to execution with good insights about the process. They know how work is performed. They are more interested in how things are done and how they should work with a specific solution. Business value is easier to measure in terms of work and costs. The interest is on the details of the solution. At the operations level, the right competence for the right task is what matters most.
May 26th, 2011
The following conversation is typical between a manager and developers:
Project manager: How long will it take you to develop this specific feature?
Programmer: One month of uninterrupted work
Project manager: Oh, I need this done faster. Can’t it be done in a week? Need this before next month’s fair.
Programmer: It might get done in three weeks.
Project manager: Two?
The project manager will note the estimate of two weeks and will hold the programmer accountable for it.
So what was this discussion about? It’s about three different concepts: estimate, business targets, and commitment:
- An estimate of work is based on a calculation of quantity of the value of something. How long has this type of work taken to complete before or what do the different parts cost and how long do you need to assemble them? The estimate is used to decide if the work is worth doing or not.
- A business target is a desirable business objective, “I need this before the next month’s fair.”
- A commitment is a promise to deliver by a certain date or event.
What the project manager wanted was a commitment based on a business target, not an estimate. This is now a commitment but don’t call it an estimate. The estimate was 4 weeks. What happened was that either the scope or quality has changed or the programmer worked more hours than he originally planned.
May 24th, 2011
Pair programming is sharing knowledge not only about how the code works, but also why it looks that way. It is sometimes difficult to write explicit instructions on why code looks a specific way and how it’s organized in pair programming. A common question about pair programming is will pair programming slow us down? The answer is yes and no. If the purpose is to spread knowledge, I would reformulate the question to will pair programming slow our learning or speed it up? Another advantage of pair programming is that interruptions tend be minimized.
Sometimes a group’s efficiency is linked to the specific knowledge of one or more people. When an expert becomes a bottleneck, let that expert be the adviser. By spreading the knowledge and letting the team try it first without the expert, it might not be as efficient, but in the long run, the knowledge spreads.
If you are not allowed to make mistakes, you will not understand the whole picture. If the expert isn’t directly involved, the rest of the team has to take more responsibility but still must have access to the expert as an adviser. The expert being fully involved is probably the most efficient approach, but if it limits the team’s performance, it would pay off in the long run.
May 22nd, 2011
Agile work uses short cycles so that developed things get too used fast. All code that isn’t used is just an inventory cost and isn’t learned from. The sooner that valuable result can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction. In order to learn as fast as possible about the real use and see how it works frequent deliver of the system is a core idea. There is an explicit trade off: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one’s retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.
May 20th, 2011
The foundation of Agile methodologies is to work in iterations. This has many benefits:
Benefit # 1: Code that is not used by stakeholders is an inventory cost. If you had a store selling clothes in all models but are not visible to customers, they would never get sold. Their value declines because soon they will be out of fashion.
It’s the same with code. If it isn’t used, you never get real feedback or get the chance to test it. The world around the system constantly changes and soon you will be working on new problems if the code isn’t used. When you move on to new features, this unused code becomes an inventory cost.
A ratio that is used in financial analysis is the stock turnover ratio. Stock turnover ratio = annual sales / average inventory. The average stock is calculated by adding the inventory value at the beginning and end of the year and dividing it by 2. For software development, you could say that the turnover ratio would be “features shipped per year” / “average number of features that are waiting for testing or deployment or not being used by users”.
Benefit # 2: Continuous integration and frequent deliveries generates feedback. Small and fast iterations also mean that the code must constantly be integrated with previous work and frequently delivered to users. This means that the code is tested during integration and also tested by users after it has been developed. If something goes wrong it is better to know about it at once. If you investigate a bug which is the result of work done 6 months ago, the root cause analysis will take some time. But if you get feedback on work done today or recently, you can easily find the root cause.
Benefit # 3: The complexity factor does not become large with small iterations. If you estimate doing two things that are about the same size, you think of the work as a having a linear relationship; that is, if I do twice as much it will take twice as long. If the first thing takes 8 hours and the second one takes 8 hours, you can do it in two days.
But if you have to do both of them in one day with the help of one friend, can it be done in just 8 hours? The answer depends on the dependencies. If both works have dependencies, you need to make sure both parts interact as planned so they don’t interfere or overlap one another.
- If you have one thing to work with, you’re dealing with only one thing.
- If you have two things, you deal with them, but you also have to deal with the way they interact and interfere with each other.
- If you have three things, you have those three things, but at the same time you have three different sets of interaction between pairs of the three, plus you have to deal with the way all three things are combined which leads to seven aspects.
- If you have four things, you have 15 aspects, and so on.
Therefore, if you have 10 things that are related and dependent on each other, doing them might be 1000 times more complex (or to be exact, 1023 aspects to deal with). The number of dependencies multiplied by the number of things to do result in the following formula: (Aspects to handle = 2 x “the things” – 1). What do these things consist of? It could be number of users’ stories, number of integrated components, number of departments involved, number of people in a discussion.
Benefit # 4: Business value comes from the possibility of adapting to change. When you start a project, the decision to start it comes from the possibility of reaching an expected business value. When the first version of the system is released, not all of the features are perfectly adapted to users’ needs. The system, therefore, doesn’t reach the expected business value.
The longer the system is used, the more the business learns what it takes for the system to reach expectations; however, because the releases are infrequent, the system falls short of its value. After a few years, the system shall have reached its minimum accepted value.
When an Agile approach is used instead, the first release lacks a lot of expected features but because new versions are frequently released, the system doesn’t fall short of its value over time. Releases are delivered, because new knowledge is used to re-prioritize work. When the system is used for a period of time, expectations tend to rise.
Delivery of Business Value
The most important observation is what this does to the stock turnover ratio, since the delivered value of the system is based on the time the system is used. The delivered business value is the red area, because it creates value when it is used. So using a system early on shows that the value delivered is at least doubled when using the Agile approach.
When the minimum accepted value is reached, business people tend to think they need a whole new system; only this time the original requirement has changed. The priority now is to add features, and to change and adapt the system to new acquired knowledge, re-factoring and updating it with new technologies. In truth, what the business needs is not a completely new system with perfect requirement specifications. What the business needs is to continuously develop their system in new ways.
May 18th, 2011
Usability testing is used to evaluate a product by testing it on real users. It focuses on measuring a human-made product’s capacity to meet it intended purpose. By observing people that use the product and discover how they think about the product, new improvements can be discovered. With just a small operation can you gain a lot of quality improvement. The first time I watch a usability test from another room I just wanted to run into the test room and help the poor user that have misunderstood a vital thing about here pension forecast, we learned so much things about usability testing that we would never have come up with because we lack the perspective. We founded a lot of low-hanging fruits that we could fix immediate.
The results of the first test can be treated as a baseline or control measurement; all subsequent tests can then be compared to the baseline to indicate improvement. Usability testing helps you control:
- Performance — How much time, and how many steps, are required for people to complete basic tasks? (For example, find something to buy, create a new account, and order the item.)
- Accuracy — How many mistakes did people make? (And were they fatal or recoverable with the right information?)
- Recall — How much does the person remember afterwards or after periods of non-use?
- Emotional response — How does the person feel about the tasks completed? Is the person confident, stressed? Would the user recommend this system to a friend?
May 16th, 2011
When the team focuses moves from “me” to “we” coding standards becomes a natural outcome. Code must be formatted to agreed coding standards. Coding standards keep the code consistent and easy for the entire team to read and re-factor. Individual style is great when you’re working alone. In team software development, however, the goal is to create a collective work that is greater than any individual could create on his own. Arguing about whose style is best gets in the way; it’s easier if we work together in a single style.
May 14th, 2011
Noise is something within a specific context that interferes with the sending of signals or messages. When you’re communicating with someone and another person interferes by talking at the same time, it becomes difficult to have a discussion.
When the noise is greater than the sent signal, the sound of what I want to hear is obscured by the sound of what I don’t want to hear – noise. One great example on noise within communications was the following test by the American Psychological Association. Ken Schwaber and Mike Beedle used it in the cover of their book “Agile Software Development with Scrum”. The instruction was easy: “Don’t read the words in the Color Test. Just say out loud what color they’re printed in as fast as you can.”
Noise in Social Complex Situations
If you are like most people, this would be hard because you tend to like reading the text as “Red, Yellow, Green…” rather than reading the colors.
As Schwaber and Beedle showed in this example, noise has interfered with your perception. When you look at the words, you see both their color and meaning. When these two pieces of information are in conflict, you need to make a choice. This test showed that most people have learned that the meaning of a word is more important than the color of the word.
The interference effect suggests that you’re not always in complete control of what you pay attention to. When projects become more complex, the more conflicts between different learned simplifications systems you will experience. This leads you to make more unconscious decisions. Because you don’t understand the requirement or the technology or even the domain language, your old learned preferences are the ones making the decisions for you.
May 13th, 2011
There has been a four-fold explosion in the amount of information witnessed by human beings and society. This is reflected in the four-paradigm shift in media which is closely linked to new ways of communicating, given that an increasing number of people have gained access to more information.
First Paradigm Shift: The first paradigm shift in our history is when we became human beings. I am talking about what differentiates us from apes. We are different from apes not because we use tools (chimpanzees used tools!), but because we developed a spoken language.
In school we were taught that Homo sapiens are defined as a purely biological race that has ceased sexual intercourse with other apes about 7 million years ago. The purely sociological Homo sapiens developed the spoken language only about 100 000 years ago. Spoken language is therefore a fairly new characteristic of humans.
Spoken language gave us new opportunities to collaborate with each other and to start acting more as a group. One person would keep watch and if he saw a lion, he would shout to the rest of the group that a lion was approaching. It was this characteristic – collaboration – that Homo sapiens became the superior race on earth. One generation passes on the knowledge to the next generation and added on to existing knowledge – knowledge that grew out of experience. But knowledge didn’t spread so fast, if life expectancy was 20 years new learning took long time and not so much was pasted on. Community elders were therefore more valuable than newborns, because their knowledge helped the whole group to survive. If the chief of the tribe died, it meant that the tribe would have 7 years of bad crops before they could learn new cropping methods themselves.
Second Paradigm Shift: The next paradigm shift occurred in Mesopotamia (now part of Iraq) about 5,000 years ago when availability of information went through a rapid expansion. At this time, people learned how to transform verbal symbols to physical symbols, giving rise to written language. By transforming communication into physical form, humans were able to store knowledge and pass it on to others without meeting face-to-face.
Humans were able to extract information from inside the human brain to make it into something outside the human realm. This meant that the human race would not be disadvantaged if they lost a member of their group, and it eventually became easier to create new things based on old knowledge.
Third Paradigm Shift: This occurred when Johannes Gutenberg invented the printing press in the 1440s. With this technology, the cost of reproducing knowledge decreased significantly and an increasing number of people had greater access to the written word. This paved the way towards the era of mass communication – or mass media – as we call it today.
The basis of mass communication is that one producer is able to distribute a message to numerous consumers of information in a quick and cost-efficient way. Thanks to this development, books can be produced at a fraction of the cost of copying a book manually. When more people can afford to buy books and newspapers, there is a higher incentive for them to learn how to read.
A new society was born where reading and writing constituted the driving force. Knowledge and information became the best competitive advantage. This was the society we were living in until the Internet was invented and its use rapidly spread.
Other technical inventions like radio and television were just like electronic printing presses for sending information to a lot of consumers. Television is the most efficient mass communication medium so far, but it is still considered a passive, one-way communication medium.
Fourth Paradigm Shift: The Internet is the fourth paradigm shift. It enabled the first two-way mass communication. The Internet has changed the way we communicate as it allows the consumer to be involved in the development of the information process. The Internet is an interactive medium where people all over the world can easily collaborate and update each other on information, therefore building encyclopedias. One example is Wikipedia.
May 12th, 2011
Code reviewing has two purposes. The first is to make sure that the code that is being produced has sufficient quality. Is it ready for the next step in the process, might be check-in, merged to main track of the source or deployment. Code reviews are very effective at finding errors of all types, identify a poor structure or identify that the source doesn’t meet the business proposal. It’s a effective litmus test for quality of the code.
The second purpose is to spread knowledge, both for the coder and the reviewer. Developers learn when and how to apply techniques to improve code quality, consistency and maintainability. Through thoughtfully evaluating code on a recurring basis, developers have the opportunity to learn different and potentially better ways of coding.
Code reviews can easily start off on the wrong foot, because they are perceived as an unnecessary step that has been forced upon the developers or seen as an evidence that managers doesn’t trust the developers. Code reviews are a proven way to minimize defects.
Image source: http://zuskin.com/coding_habits.htm
May 10th, 2011
Humans have a need to feel that they are in control. Control is a profound need. When we feel out of control, we experience a powerful and uncomfortable tension between the need for control and the evidence of inadequate control.
From an evolutionary standpoint, if we are in control of our environment, we stand a far better chance of survival. Our subconscious mind thus releases certain chemicals when faced with danger. The only time we will feel a sense of control is when we understand how things work and we can predict what will happen.
So how much control can you expect in different situations?
In financial markets, you expect a 1-4% return if you want to stay in control and take a small risk. But if you want higher returns, you must be prepared to take more risks. When you take more risks, you lose control at the same time.
The higher the stakes are and the more pressure you feel, the more sense of control you will need. If you have more responsibility than authority, this can frustrate you. You feel the need for more control, and this in turn creates stress.
Running a complex project means that you’re aiming for more than 1-4%, and are willing to take a larger risk. To demand that someone be in control only creates stress. To gain more control and to be able to plan far into the future are only possible when you take more risks. To think that you can stick to a pre-drawn map that does not take into account the fact of control creates frustration and friction. The feeling of control in complex projects comes from breaking down all activities into smaller segments and making detailed short term plans. Don’t expect long term planning to work.
What’s my conclusion on the question, why is it difficult to plan for success in software development?
Reaching Maximum Business Value
When work is more of an exploratory journey, your work is to solve problems you don’t yet understand by creating a solution that you also don’t yet understand. At the same time, you should communicate with people in a language you haven’t yet learned. Because of these “unknowns”, the work is complex and there is a lot of noise. The noise interferes with your information in such a way that you can’t distinguish the message from the noise.
In this situation traditional plan-driven processes that try to predict the future will only give you a false feeling of control. To control this situation you will not be producing the best solution since you will steer to your perception of what the customer wanted in the beginning of the project.
During the journey, however, the customer got wiser so that the original goal is no longer good. The customer now wants the benefits of the knowledge he acquired during the journey. By organizing work in different ways, you are actually getting more business-oriented and you’re lowering the risk.
May 9th, 2011
Refactoring is about reorganization, it comes from mathematics when you factor an expression into an equivalence – the factors are cleaner way of expressing the same statement. Refactoring means equivalence; the original product and the end product must med functionally identical. There are generally two reasons to do refactoring:
- Maintainability – it is easier to fix bugs because the source code is easy to read and the intent is easy to grasp. This might be achieved by removing monolithic routines into a set of individually concise, well-named, single-purpose methods. Or it might be achieved by moving a method to a more appropriate class, or by removing misleading comments.
- Extensibility – it is easier to extend the capabilities of the application if it uses recognizable design patterns.
In order to ensure that the function is identical is common to create a solid set of unit tests. The test should demonstrate that the behavior of the module is correct. If the test fails, you undo the change. Refactoring shall make your code clearer, cleaner, simpler and more elegant.
May 7th, 2011
The practice of self-organizing team is one of the most debated principle and one that I personally haven’t figured out rather good. I think the big miss understanding is that people takes about different kind of teams in order to show the difference I like to show what I think the Agile Manifest meant by self-organized teams. What to strive for is that the “whole team” takes responsibility for getting things done and everyone feels that they can bring something to the team. But it doesn’t mean that the team is not free from management control.
What is generating energy and passion of the self-organizing team is that members enjoy the opportunity to organize their own work and contribute with a higher potential. But at the same time people enjoy avoiding administration and organization in order to concentrate on their work, often programmers like to program and not write progress reports to customers. So how does an agile leader achieve the subtle balance between command and influence?
This is the tricky thing. I think the team needs to be influence by the rest of the organization at the same time they need to focus on what they achieve. Management therefore needs to be helping the team figure out the direction and collaboration to other parts of the organization. The group shall have a great opportunity to influence how they work and how do what. I personally think a team needs to be lead and manage and have real genuine support from general management. So I’m probably in favor of more self-managing teams rather than self-Governing teams. I personally sees my management responsibility to make the best of the cards I been dealt with, I’m not always playing with a strait flush on hand. Not everyone have the ability to do the same thing and people do it different good and fast, therefore I prefer to manage who do what.
Here is some thoughtful links on the subject:
May 6th, 2011
A little knowledge can be a dangerous thing. Frequently, people may have read or heard about a new techniques – which in some cases can lead to that they will try to fit their problems to one of these new solutions. Especially if there is no culture of “begin with the end in mind”. Of course new technology should be adopted. I used to ask my architects to be the advocate for good quality and clean architecture. The majority of problems can be solved using fairly traditional and established techniques in an intelligent manner. Learn first how to get the best of simple, traditional techniques. When I see that people mastering a technique I sometimes send them on scouting missions to check out new technologies for the rest of the group. Its important to work in a consistent way, with new technologies you need to think how to it should relate to you old knowledge, it might there for be a good idea to agree on what the new technology aim to solve, before changing everything. Someone that doesn’t know how to handle a nail gun is more dangerous with one than with a hammer, even if it’s a more productive tool.
May 5th, 2011
Yesterday I was on an introduction course on Sparx Enterprice Architect which seems to be a quite competent tool. I like that they have collected all types of modeling, UML, Process, Class and DB into one tool. You can integrate it with versions controls like Subversion and TFS. It really feels like the modulation programs have got a bit further than just the drawing programs like Visio. I use to reverse engineer database diagrams and entity relationships diagrams with Visio and tried that with Sparx EA and it worked fine. The threshold seems to be a bit higher then with Rational Rose or Visio, but often that means it more productive as soon you learned the tool.
One nice function was that it was real easy to export everything to HTML in order to publish the whole model for other that don’t have SparxEA. It’s seems to be a great tool for documenting and modeling complex solutions. I will definitely learn more about SparxEA. Here is a brief introduction if you are curious: http://www.sparxsystems.com.au/resources/demos/eaoverview/index.html
You can try SparxEA for free in 30 days which gives you plenty of time to learn this tool.
May 4th, 2011
In order to handle complexity, software is designed in layers and modules. When a programmer is worrying about the details design of one module, there are probably hundreds of other detail that he cannot possibly worry about at the same time so in order just have to deal with a few parameters at the time the solution have to be divided in different building blocks that have their own intention. Design is made on a high-level (also known as “solution architecture”) are about dependency management where different aspects is divided, which things have a dependency and where shall different functions be grouped together.
And design is made on a low-level like how will this algorithm be implemented. If high-level of software design is a map of how the solutions is organized it will not be complete until it has been coded and tested. Testing is a fundamental part of the design validation and refinement process. So design is an every ongoing process and can’t be frozen like in a bridge building project. The more complex a solution is the more important it becomes to have a good architecture that helps you tangle with the complexity. You need to be stricter with modulation and coding standards when you need to collaborate with a lot of others.
I got a small project why not just code?
Over the years I learned that just start hacking might be quite rewarding, because you feel enthusiastic you like to get down to business direct. This habit might be hard to break, and are often addictive because you get to start with fun things. You can choose to make a minimal design but taking the time plan your work will save you a lot of waste because otherwise you will need to redo things. When you plan it becomes easier to estimate the coding and testing. A plan also helps you address high risk so that these can mitigated as much as possible, for instance by starting work on prototypes to investigate technology that is not well understood. A plan also makes it possible to evaluate the eventual software against important goals as maintainability, robustness, reusability or consistency with the company strategy, before coding starts.
How much high-level design (architecture) shall we do?
It’s hard to answer how much planning of solution that shall be done. It depends on each case, but the main drivers are “how well the requirements are documented and understood” and how many people that will involve.
So what can design be, here are some examples:
- Basic structure, which parts shall be grouped together, so that they can be isolated and controlled by them self.
- A block-diagram-level structure, broken into smaller components units.
- An analysis of the dynamics of the system in use (message, data-flow or sequence diagrams).
- Map relationships between the units.
- Plan precondition and post conditions.
- Detail user interface layout.
May 3rd, 2011
Projects often start because someone realizes that there is a new opportunity or that we need to fix something in order to save money. An idea soon becomes a requirement list and then the “innovator” convinces a manager that this might be something. The manager then contacts IT-people to get there view, what might the thing and what could be done. The “IT-People” realize that this is no out of the box solution, but this requires a unique system. The “IT-people” starts to write a specifications and talks to different stakeholder and then come back to the manager that first contacted team and asks “What if you add this and do that?” The manager answers “Ooh nice, can you also do this then” and so it continuous. And the specification just grows into a bigger plan. At this point the organizations seams to choose path to continue, either the plan-driven; phase by phase way or the agile let’s start solving some problems and see what we learn.
Now I’m probably a bit provocative but the problem but I think the plan-driven companies would probably end up with the right wrong system and the agile will probably just do it faster. The problem is that you are not solving and focusing on the real business problem, the IT-People have a tendency to start to focus on technical features. The most users will start dreaming up all kind of new features that you could do and be nice to have, but really doesn’t give any business value. Instead the most important thing you should do is to study users or future users how they would perform the action manually. Involving users early is a real key success factor, and then the important thing is to see what they really do and how they might use the system not what they think they might use and nice to have features. Cost savings driven project are more easily investigated. New opportunities driven projects are often more difficult to involve user feedback within, this is because people can’t as easy relate to something they don’t have experience with.
May 2nd, 2011
Six month have passed since I come up with the idea of www.applitude.se and I’m been analyzing my visitors so far. I have been publishing content for 4 month now and I got more than a 1300 unique visitors and last month I had 332 unique users that read more than one page on my site. Interesting statistics is that Spanish looks on the most pages and spends most time on my site. After that India is the country people spend most time on my blog with an average of 9.00 minutes. Sweden is just on fourth place with 3.12 minutes per visit. Firefox is the most common browser (25%), then IE (23 %) and then Safari with (22 %). The most read blog posts are:
Interesting is that I have had visitors from 29 countries. Never could have guess that someone actually would read my small fragments of thoughts. Thanks for reading my article and don’t hesitate to comment.
During May I will publish more frequently, at least one content article every second day, so stick around.