I was digging through some of my old files and ran across this old gem. This is a javascript function that will take an email and obfuscate it by creating a series of methods that create the mailto address on the fly. This is to thwart crawlers and is amazingly effective, even these days, as most crawlers don’t process javascript effectively.
Category - Software & Technology
There is a common misconception, especially among those new to Agile/Scrum, that Story Points are just another way of measuring how long work will take and can be easily swapped out with hours. A common mistake new Agile/Scrum practitioners will make is to hand out a matrix that new practitioners can use to easily map the hours of old to the new points system. This approach entirely defeats the purpose of story points.
Old Way |
New Way |
| 2 hours |
1 point |
| 4 hours |
3 points |
| 8 hours |
5 points |
| 16 hours |
7 points |
| 24 hours |
11 points |
Don’t do this…
Why Use Story Points?
Estimating work using story points solves the age old development problem of having different people write the code than those who estimated the work. For example, if you have a tenured, senior level engineer that estimates the work for a given project or sprint then a brand new engineer, fresh out of college, the new engineer is very unlikely to complete the work in the estimated timeframe, even if the senior level engineer padded the estimate to account for this. The problem is that we tend to be only moderately good at estimating things for ourselves and tend to be terrible at estimating them for other people. This is why most software projects and other forms of construction are often late.
Story points give us a way to measure work such that the experience level and speed of the person doing the work does not have a material bearing on the estimation process.
Story Point Basics
The hardest thing for new story point estimators is getting their head around the fact that story points do not measure duration. Instead, story points are used to measure size. By measuring size engineers are able to find a common ground that they can all agree on, even if it will take each person in the group a different duration to complete a task of the same size. Let’s explore with an example.
Story points measure size. For example, 1 mile. Minutes (hours with code) measure duration, or the amount of time it would take you to run 1 mile. Bob is not a very good running and it takes him roughly 15 minutes to run 1 mile. Swathi, on the other hand, is an excellent runner and can run 1 mile in just 6 minutes. The size of the task is the same but it takes each runner a different amount of time to complete the task.
If you translate this concept to software the team starts by forming an agreement for the size of various size tasks (more on this later). For example, adding a text field to a page may be 1 point, adding a new page may be 5 points, and adding a brand new user role may be 13 points. Despite the fact that each person on the team will work these points at different speeds the team has a common estimate for the size of the work to be done. They can now use the amount of work, as measured by size, that they completed in past sprints to determine how much they are going to be able to work in their upcoming sprint. By measuring size each sprint the team can take out the variable of how long it will take each person to complete a given task and instead just focus on the size of what a team can complete in a set timeperiod, their sprint.
This approach is something that tends to be off at first but as teams get used to each other and get a better common relative size reference, estimates dramatically improve.
Fibonacci Points
To estimate teams typically will use Fibonacci points – 1, 2, 3, 5, 8, 13, etc. By using these numbers it gives better relative size between each point choice, making it easier to compare the size of things to one another. For example, using a 1-10 scale it is very hard to say whether a 6 is a lot or a little different than a 7. But with Fibonacci points it is easy to say that a 3 is roughly 50% larger than a 2 or an 8 is roughly 40% smaller than a 13.
Planning Poker
Planning poker is a common practice, especially for relatively newly formed teams. Once teams become good at point estimating they will often skip planning poker and just assign estimates out together. This proces starts by everyone getting a set of cards with Fibonacci numbers on them. A team member reads out a story to be estimated, along with acceptance criteria, then each member picks a card from their deck that they feel best represents the size of the story. Once everyone has made their selection the team compares.
If there are discrepancies the team takes the time to hear why team members feel the size they applied is justified. This is often done by looking at the highest and lowest first, then working inwards. The team must work together to arrive at a common agreement for the size of each story. Throughout this process the team can always revisit a story if the relative sizing of other stories prompt them to rethink how large a prior story was. Note that this process is often very bumpy and takes longer when teams are newly formed. The better teams know each other and the longer they have been together, the smoother the process and the better the estimates.
Happy estimating!
There is a lack of understanding by many non-technical people on how the technology their lives revolve around works. This is the intention of technology – shield complexities of how things work from people and make hard things easy. However, it also has a potential dark side that can create a blind spot in people’s personal security.
Let’s take a simple example – any of the many voice response tools out there, from speakers to TV remotes to refrigerators to phone. Many people are unaware that to process speak most of these devices sends recordings / streams of people speaking to the company’s servers for processing (the chipset in most devices isn’t powerful enough to process things like freeform speech efficiently). The device opens a connection to the servers, sends information, then waits for a response telling it how to behave.
This means that all of your recordings, and anything you or others said in them, are now stored on a server and you no longer own them. Most of these devices claim that they sleep until their activation word is spoken, meaning that the only recordings are the ones that follow you explicitly initiating dialog.
It would be quite easy to couple the data in these recordings with your profile account information and other openly searchable data points (Facebook, LinkedIn, etc.) to put a pretty robust picture of you together. This could be used for anything from targeted marketing to targeted scams, if the data fell into the wrong hands.
This is just one of many examples of how our increasingly interconnected world opens avenues many people don’t realize exist. These technologies are not bad things. You should just make sure you understand what you are getting into and how you will use it before you go all in on the latest and greatest IOT device.
