Skip to content

Blogs

Python: BeautifulSoup – Insert tag

Mark Needham - Thu, 06/30/2016 - 23:28

I’ve been scraping the Game of Thrones wiki in preparation for a meetup at Women Who Code next week and while attempting to extract character allegiances I wanted to insert missing line breaks to separate different allegiances.

I initially tried creating a line break like this:

>>> from bs4 import BeautifulSoup
>>> tag = BeautifulSoup("<br />", "html.parser")
>>> tag
<br/>

It looks like it should work but later on in my script I check the ‘name’ attribute to work out whether I’ve got a line break and it doesn’t return the value I expected it to:

>>> tag.name
u'[document]'

My script assumes it’s going to return the string ‘br’ so I needed another way of creating the tag. The following does the trick:

>>> from bs4 import Tag
>>> tag = Tag(name = "br")
>>> tag
<br></br>
>>> tag.name
'br'

That’s all for now, back to scraping for me!

Categories: Blogs

Serverless Single Page Apps, In Print at The Pragmatic Bookshelf

Radyology - Ben Rady - Thu, 06/30/2016 - 15:31
I've been working on a book that explains the style of single page app that I've been building for the last few years. Up until very recently, I couldn't find a way to use this style for public-facing apps, because... Ben Rady
Categories: Blogs

Occam’s Razor and Agile Frameworks

Leading Agile - Mike Cottmeyer - Thu, 06/30/2016 - 13:05

Occam’s (or Ockham’s) razor is a principle we attribute to William of Ockham back in the 14th century. The principle states that “Entities should not be multiplied unnecessarily.”  The popular interpretation is, the simplest explanation is usually the correct one.

It has inspired numerous expressions including “parsimony of postulates”, the “principle of simplicity”, the “KISS principle” (Keep It Simple, Stupid).

Most of Occam’s principles originate from philosophy.  Maybe this is why you will now find many approaches (especially the principle of simplicity) in the basics of design principles.

Given a choice between functionally equivalent designs, the simplest one should be selected. Implicit in Ockham’s razor is the idea that unnecessary elements decrease a design’s efficiency, and increase the probability of unanticipated consequences. [¹]

When comparing technologies that perform the same function, one that is simpler in design will tend to be simpler to construct and repair.  Additionally, it will tend to require greater skill to use, whereas a technology that requires less skill to use will tend to be more complex in design and more complex to construct and repair. For example, a straight razor is relatively simple in design and construction, but requires considerable skill to use, whereas an electric razor is relatively complex in design and construction but requires little skill to use. [²]

Agile Frameworks

Now, go back and reread the two referenced passages, substituting design and technology with Agile framework.  I also like the straight razor analogy, mostly because I shave using a straight razor.  I only had to cut myself once (badly) before I realized I needed real skills to use such a simple tool. Counter to that, it took me several failures in complex organizations, to realize using a complex Agile framework does not translate to simple implementation.

Though I agree Scrum can address complex adaptive problems, I think it does so in a controlled team-level environment. I don’t see it working well on complex organizational-level environments.  It’s like shaving a yak with a straight razor.

On the other end of the spectrum, we have SAFe, LeSS, DAD, [enter your acronym here].  These frameworks have emerged, in part I believe, because complex organizations expect complex solutions.  We shave the yak, with an electric razor that Dr. Seuss would be proud of.

My Thoughts

First, though larger organizations are often complex, we do not need to make Agile frameworks even more complex. It seems like very few customers care how they get work done.  They just care that they deliver their product or service on time and within budget.  If you’re looking to add control points to process and governance, look for what will lower risk and increase value throughput.  Make processes as simple as possible and allow work to flow through your delivery system.  Simplicity (by removing dependencies) is the key. Dependencies break Agile.  While you should be careful not to add too many control points to a process, creating unnecessary work for everyone.  Additionally, don’t simplify too much either, resulting in chaos.  Focus on systematically removing dependencies and look for that happy medium.  As a result, you may just need three things.

Just be careful not to cut yourself.

[¹] http://www.visualgui.com
[²]  http://www.omick.net

The post Occam’s Razor and Agile Frameworks appeared first on LeadingAgile.

Categories: Blogs

PMI-ACP Exam Prep with Mike Griffiths – Mind Map

Leading Answers - Mike Griffiths - Thu, 06/30/2016 - 04:41
For anyone studying for their PMI-ACP exam, I have created a mind-map of the PMI’s Exam Content Outline and my book contents. So here it is, on a single (large) page all the topics within the exam and the second... Mike Griffiths
Categories: Blogs

Article Review: Agile Teams Bend But They Don’t Break

Learn more about transforming people, process and culture with the Real Agility Program

In an out-dated model of work environments, there are clear “rights” and clear “wrongs.” Usually, the management or leadership determines this and they call it “Policies and Procedures” or “Mandates” or simple “Rules.” There are usually severe consequences for not following these, intentionally or accidentally.

In the new and emerging agile model, where team members focus their attention on taking action with little planning, reflecting, learning and planning frequently work environments are very different.

Instead of looking for people to blame when challenges emerge, an agile team looks for ways to learn and develop. The team can collectively embrace new ways to adapt to change together.

This is one of the things I am learning about in high-functioning agile teams.

I like the way Brian Milner addresses this in his article “6 Ways to Bring  Humility to your Agile Leadership Style.”

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Article Review: Agile Teams Bend But They Don’t Break appeared first on Agile Advice.

Categories: Blogs

25 Ways to Get Better Results

J.D. Meier's Blog - Wed, 06/29/2016 - 16:10

Have you ever wondered why some people seem to be really good at getting results, while others struggle?

What are the true secrets of productivity that set one person apart from another, and help them achieve high performance?

I’ve studied the challenge of personal productivity deeply to really understand the difference that makes the difference.

I’ve put together a list of 25 Keys to Getting Better Results that cut to the chase and get to the bottom line of extreme productivity:

25 Keys to Getting Better Results

This list of productivity secrets is from my best-selling productivity book, Getting Results the Agile Way, and reflects the best of what I’ve learned in terms of what really makes some people stand out when it comes to personal productivity, high performance, and making things happen.

After all, who doesn’t want better results in work and life?

You can read the list of productivity secrets, but here I want to touch on a few key ideas.

Vision

Vision is probably the single most important starting point when it comes to getting better results. 

It’s hard to do anything if you don’t know what it’s supposed to be or do when it’s done.

If you can see the end-in-mind, then you are off to a good start.

And if you feel really good about the end-in-mind, then you have something to pull you forward versus trying to push yourself forward.

When your vision pulls you forward, you are on the right path.

Value

Value is in the eye of the beholder and in the eye of the stakeholder.

Value is also the ultimate short-cut.

If you know what good looks like or if you know what’s actually valued, you can refocus your efforts on high-value activities that produce those outcomes.

When you don’t know who the value is for, or what good looks like, you are in trouble.

That’s why it’s important to check with the people you are producing value for, whether you are actually nailing their pains, needs, and desired outcomes.

If not, no problem – learn and adapt.

Learn early, learn often, and really get curious about which of your activities produce the highest value results.

Velocity

Speed is the name of the game.

As John Wooden would often say, “Be quick, but don’t hurry.”

In other words, make your moves quickly, but with intention, and with quality.

Quality comes through practice and repetition.  It’s how you learn.

Try things.   But try then quickly, and experiment in how you product results.

Use speed as your friend to learn faster, and to build momentum.

Don’t get bogged down.  Use speed to cut through your challenges, and quickly prioritize your best bets, and create a flow of continuous value.

Sometimes you will need to slow down to speed up.

But more often than not, you will need to speed up, so you that you are effectively taking massive action.

Few challenges withstand the onslaught of massive action, as long as you keep on learning and improving.

Well, that’s about it for now.

I hope that gives you at least a big of an edge that you can use in your day, every day, to get better, faster, simpler results for work and life.

Enjoy.

Categories: Blogs

Product Owners and Learning, Part 5

Johanna Rothman - Wed, 06/29/2016 - 16:00

When I think of POs and the team, I think of learning in several loops:

  • The PO learns when the team finishes small features or creates a prototype so the PO can see what the team is thinking/delivering.
  • The team learns more about its process and what the PO wants.
  • If the Product Manager sees the demo, the Product Manager sees the progress against the roadmap and can integrate that learning into thinking about what the product needs now, and later.

Note that no one can learn if they can’t see progress against the backlog and roadmap.

There are two inter-related needs: Small stories so the team can deliver and seeing how those small stories fit into the big picture.

I don’t know how to separate these two needs in agile. If you can’t deliver something small, no one, the team, the PO, the customer, can’t learn from it. If you don’t deliver, you can’t change the big picture (or the small picture) of where the product is headed. If you can’t change, you find yourself not delivering the product you want when you want. It’s a mess.

When you don’t have small stories and you can’t deliver value frequently, you end up with interdependent features. These features don’t have to be interdependent. The interdependencies arise from the organization (who does what) and think they are talking about interdependencies in the features, but a root cause of those interdependencies are the fact that those features are not small and coherent. See my curlicue features post.

That means that the PO needs to learn about the features in depth. BAs can certainly help. Product Managers can help. And, the PO is with the team more often than the Product Manager. The PO needs to help the team realize when they have a structure that does not work for small features. Or, when the PO can’t know how to create feature sets out of a humungous feature. The team and the PO have to work together to get the most value from the team on a regular basis.

This is why I see the learning at several levels:

  • The Product Manager works with the customers to understand what customers need when, and when to ignore customers. It is both true that the customer is always right and the customer does not know what she wants. (I won’t tell you how long it took me to get a smart phone. Now, I don’t know how I could live without one. You cannot depend on only customers to guide your product decisions.)
  • The PO Value Team discusses the ranking/when the customers need which features. When I see great PO Value teams, they start discussing when to have which features from the feature sets.
  • The PO (and BA) work with the team to learn what the team can do when so they can provide small stories. They also learn from the team when the team delivers finished work.

The larger the features the less feedback and the less learning.

So, I’ve written a lot here. Let me summarize.

Part 1 was about the “problem” of only addressing features, not the defects or technical debt. If you have a big picture, you can see the whole product as you want it, over time. For me, the PO “problem” is that the PO cannot be outside-facing and inward-working at the same time. It is not possible for one human to do so.

Part 2 was about how you can think about making smaller stories, so you have feature sets, not one humungous feature.

Part 3 was about ranking. If you think about value, you are on the right track. I particularly like value for learning. That might mean the team spikes, or delivers some quick wins, or several features across many feature sets (breadth-first, not depth-first). Or, it could mean you attack some technical debt or defects. What is most valuable for you now? (If you, as a PO have feature-itis, you are doing yourself and your team a disservice. Think about the entire customer experience.)

Part 4 talked about how you might want to organize a Product Owner value team. Only the PO works with the team on a backlog, and the PO does not have to do “everything” alone.

If you would like to learn how to be a practical, pragmatic Product Owner, please join me at the Practical Product Owner workshop, beginning Aug 23, 2016. You will learn by working on your roadmaps, stories, and your particular challenges.  You will learn how to deliver what your customers value and need—all your customers, including your product development team.

Categories: Blogs

Links for 2016-06-28 [del.icio.us]

Zachariah Young - Wed, 06/29/2016 - 09:00
Categories: Blogs

What’s your favorite Agile Conference?

Ben Linders - Tue, 06/28/2016 - 16:01

favorite agile conferenceAs a trainer, (keynote) presenter, editor for InfoQ, and agile networker I go to conferences all around the world during the year. They are all different, each one has it’s own strong points. Now I’d like to hear from you: What’s your favorite agile conference? Please share your favorite agile conference by commenting on this post.

In 2016 I attended the Agile Practitioners Conference, Scaling Agile for the Enterprise, DevOps Summit, 1st Conference, QCon London, Agilia, AgileEE, Retrospective Facilitators Gathering, Software-Centric Systems Conference and GOTO Amsterdam. For these conferences I visited Tel Aviv, Brussels, Melbourne, London, Olomouc, Kiev, Sagres, Eindhoven and Amsterdam. Why go to conferences


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

People go to conferences for different reasons. I go to them to learn new things, stay up to date with what’s happening in agile communities and to share my experiences.

I really liked giving a keynote at the 1st conference because it was my first time to Australia which felt great. This conference had a fully packed program for people that are new to agile, I was amazed by it’s broadness in topics and the quality of the talks.

It was my second time to the AgileEE, and I felt at home right from the start. There’s always an lot of energy at this conference, people are networking everywhere and it’s the conference with a very diverse audience who’s eager to learn. The new venue was a real improvement.

The Retrospectives Facilitators Gathering is different because it’s a small group dedicated to agile retrospectives. It’s a full week open space on agile retrospectives, for me it’s the place to be to sharpen my facilitation and training skills. Upcoming conferences

In the coming months I will be attending the following conferences:

There are a couple more conferences coming up, which haven’t announced my workshops or talks yet. As soon as they become public they will be added to my conference schedule. Your favorite agile conference

So tell me: What’s your favorite agile conference? Please share your favorite agile conference by commenting on this post.

 

Categories: Blogs

What IT Directors Mean In Business Speak

Leading Agile - Mike Cottmeyer - Tue, 06/28/2016 - 13:30

As a coach and committed Agile Evangelist, I spend most of my time convincing the software organization that they are actually part of the business. In this role, I also help with interpretations of Software / Technical jargon to business speak. Here are 5 of my favorite IT Director phrases:

  1. We are going to make the date at all cost.
  2. Refining requirements with business partners is bureaucratic and slow.
  3. It is up to the Operational team to clean up the process.
  4. We will work with DevOps to smooth out deployments.
  5. This new technology will speed up delivery once we re-write everything.

Now drumroll please, here is what they mean to the rest of the business.

Business Speak 1


  1. We are going to make the date at all cost. Actually means you need to have funding for 2 support people for every developer on staff. It will take one to three years to make this software run smoothly. At the end of the third year, we will make the case that it is too costly to maintain and try to make the date at all cost for a replacement.

    Business Speak 2

  1. Refining requirements with business partners is bureaucratic and slow. Actually means we in IT can write a bunch of code much faster if we don’t have to understand how you are going to use it. We will just give it to you and you can figure out how to change your processes to make it work. If you can’t make it work, we can start up a replacement project.

    Business Speak 3

  1. It is up to the Operational team to clean up the process. While delivering at all cost we created a bunch of manual steps, such as loading data directly to the production database. These manual steps will be turned over to technical operations with knowledge transfer sessions, i.e. someone sitting with someone but nothing actually written down. Once it is in the operational team, it is up to them to figure out how to automate these manual processes as long as they do not use development time.

    Business Speak 4

  1. We will work with DevOps to smooth out deployments. We were busy delivering at all cost and never got around to automating our deployments. We are turning over that piece of work to the Delivery Operations team to automate.   We don’t have time to document the deployment procedures but they have been working with us for the last few months so they can do it.

    Business Speak 5

  1. This new technology will speed up delivery once we re-write everything. Actually means, I found something new and cool that I want to learn and it will look good on my resume.   That old stuff is hard to maintain and change. We have no idea what most of that code is doing so let’s just start from scratch. We will not be able to make any business changes to the existing software. All of our efforts will be building the new software to do what the existing software already does.

Finally, the one that the IT Director says in the hallway but never in a meeting, “I have no idea what all these operational people are doing, I wish I could get that headcount for software delivery.”

The post What IT Directors Mean In Business Speak appeared first on LeadingAgile.

Categories: Blogs

The Art of Software Gardening

TV Agile - Tue, 06/28/2016 - 10:30
Software development has evolved a lot the last decade. Developers are not considered code monkeys any more. They’re expected to write clean and maintainable code that continuously evolve with business needs. Some times they need to work remotely in dynamic and multi-cutltural environments using a variety of technologies and programming languages. Nevertheless they still want […]
Categories: Blogs

Reimagine Your Productivity at Getting Results.com

J.D. Meier's Blog - Mon, 06/27/2016 - 18:27

image

Imagine if you could master your motivation, your productivity, and your time management?

It’s time to get your game on.

I’ve completely revamped Getting Results.com (http://GettingResults.com) to help you think, feel, and do your best in any situation.

At Getting Results.com you can learn all about Agile Results.  It’s more than just a time management system or a productivity system.

It’s a personal results system for work and life.

Agile Results is a simple system for meaningful results.

It helps you respond to change while making things happen.  It helps you use your best energy for your best results, while you keep learning and improving.

What Will You Find at Getting Results.com?

Getting Results.com is a source of insight, inspiration, and action for mastering productivity, motivation, time management and more.

Here are some of the key things you’ll have access to:

  1. Get Started with Agile Results.
  2. Articles on Agile Results, Goals, Motivation, and More.
  3. 7 Day Agile Results Jumpstart, helps you take Agile Results for a test-drive and potentially have one of your best weeks.  Ever.
  4. 30 Days of Getting Results, this is advanced training that will help you get better results for work and life.
  5. Resources that include Cheat Sheets, Checklists, How Tos, Visuals, and more.

You can also read Success Stories to hear about how others have implemented and are using Agile Results.

Getting Started with Agile Results

While there are a lot of resources at Getting Results.com, the most important thing you can actually do is just get started with Agile Results:

Get Started with Agile Results

Take it for a test drive and see if you can create better results at work and in your life, the Agile Way.

Categories: Blogs

Trello Board with Retrospective Techniques

Ben Linders - Mon, 06/27/2016 - 15:27

The Trello board retrospective techniques for coaches, Scrum masters, and other facilitators provides exercises and ideas to design agile retrospectives. Philip Rogers created this board, he has added me so that I can contribute my experience with retrospectives.

This interesting retrospective resource on Trello has columns with:

  • “All-in-one” plans for retrospectives, descriptions of exercises that cover the five phases mentioned below.
  • Futurespectives, where the focus of the conversation is not on something that has occurred in the past, but instead on what the team foresees in its future.
  • Activities for the five phases from the agile retrospectives book by Esther Derby and Diana Larsen.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Trello Retrospectives techniques boardThe trello board with retrospective techniques has been added to the retrospective exercises toolbox.

I’ve contributed to the board by sharing my blog posts How Futurespectives Help Teams to Reach Their Goals, Retrospective Prime Directive in many languages and What to do when safety is low in a retrospective on this board. More will be added soon.

My mission is to help teams all around the world to increase the value of their agile retrospectives. There’s the book Getting Value out of Agile Retrospectives, the Retrospective Exercises Toolbox, workshops for Valuable Agile Retrospectives in Teams and for Increasing your Agility with Retrospectives and there are lots of blog posts on retrospectives. And you can Ask Your Agile Retrospective Question on line. All these things help you to make your retrospectives valuable.

A big thanks to Philip Rogers for providing me the possibility to share my experience and ideas for agile retrospectives on this board!

Categories: Blogs

Review: Switching to the Agile Mindset

Learn more about transforming people, process and culture with the Real Agility Program

Recently, I discovered a well-written article on Scrum Alliance posted from a member entitled “Switching to the Agile Mindset.” In this article, the author lists six key components of the transformation individuals and teams go through as they adapt more agile mindsets and approaches to their work. I found this article ideal for new coaches and also useful for people on the team who may feel challenged by the switch.

The part which stands out for me the most is the phrase, “Change acceptance develops agility in a team.”

This concept is enshrined in the Agile Manifesto itself. Being able to adapt well to change is the cornerstone of the new mindset and a high-functioning agile team.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Review: Switching to the Agile Mindset appeared first on Agile Advice.

Categories: Blogs

The Key To Delegating Work

Derick Bailey - new ThoughtStream - Mon, 06/27/2016 - 14:00

Getting thrown in to the deep end of any new responsibility can be quite a challenge – but none more so than the challenge of managing other people and their projects, when you have no experience with management!

As someone that has been through the ranks of project leadership and management, I’ve found a few principles to be consistent in learning how to delegate work to the people on my teams… a balance between two extremes that can be difficult to find.

So, what is the key to delegating work effectively – especially in your early days as a manager?

Find out in this episode of ThoughtsOnCode.

Categories: Blogs

Links for 2016-06-26 [del.icio.us]

Zachariah Young - Mon, 06/27/2016 - 09:00
Categories: Blogs

Dangers of Certainty in Realizing Customer Value

Don Quixote was certain he saw Giants instead of windmills. In this epic story, he believed he knew the answers and saw what he wanted to see.  Unfortunately in many organizations, there is this same phenomenon, a need to act as if we are certain.  In fact, the higher up you go in an organization, the compulsion of acting with certainty becomes greater and greater.  Statements like “That’s why we pay you the big bucks” are used to imply that the higher in an organization, the more you are expected to just “know”. 
Some think they must act with “pretend certainty” for the benefit of their career.  Others have convinced themselves of “arrogant certainty” where they believe they know the answer or solution but don’t (or can’t) provide any solid basis for this certainty. Unfortunately this arrogance can be interpreted as confidence that can be dangerous to the success of a company.  Nassim Nicolas Taleb refers to “epistemic arrogance” that highlights the difference between what someone actually knows and how much he thinks he knows. The excess implies arrogance.  What has allowed certainty within companies to thrive is that there is a distance between the upfront certainty and the time it takes to get to the final outcome.  There lacks accountability between certainty at the beginning and the actual results at the end.  Often times the difference is explained away by the incompetence of others who didn’t build or implement the solution correctly.
Of course, the truth is somewhere in between. The concept of certainty is actually dangerous to an enterprise since it removes the opportunity of acknowledging the options and allowing the enterprise to apply a discovery mindset approach toward real customer value via customer feedback loops and more.
We also want to avoid the inverse that is remaining in uncertainty due to analysis paralysis.  A way to avoid this is to apply work in an incremental framework with customer feedback loops to enable more effective and timely decision-making. Customer feedback will provide us with the evidence for making better decisions. Applying an incremental mindset will enable us to make smaller bets that are easier to make and allow us to adapt sooner. 
A healthier and more realistic approach is to have leaders who understand that uncertainty is actually a smart starting position and then apply processes that support gaining certainty. It is, therefore, incumbent upon us to have an approach that admits to limited information and uncertainty, and then applies a discovery process toward customer value. In the end, the beaten and battered Don Quixote forswears all the chivalric false certainty he followed so fervently.  Is it time for management to give up the certainty mindset they think they have and instead replace it with a discovery mindset as a better path to customer success? 
Categories: Blogs

Making Unconscious Habits in Culture Conscious in Agile Teams

Learn more about transforming people, process and culture with the Real Agility Program In the past, in our North American culture, power and authority in an organization was held by those who earned the most money, had the titles to go along with their authority, and they had the right to make decisions about where they went, when they went places and who they associated with. They also had the power and authority to decide what others did and didn’t do in their work environment. That was in the past.   Where we are headed in a more unified and equal culture, based on principles of collaboration and understanding is that power is now more equally distributed. Those who didn’t have access to education now do. Those who were previously barred from environments of wealth and prosperity are now welcomed in. Corporate cultures, and organizational models across the board are changing and it’s good for everyone.   The biggest challenge in any change arises when someone’s fear of being excluded is realized. The issue is no longer about money or time or integrity. The issue is that as work environments change, old (mostly unconscious) patterns of exclusion are changing too. It means janitors associating with doctors and delivery teams eating lunch with those in leadership (imagine that!). When an organization is going through a transformation, when they notice behaviours which were limiting and exclusive and change them, they are actively contributing to an ever-advancing civilization. They are creating a new and inclusive culture.   At times, mistakes will be made. Old ways will sneak their way back in and one or more team member may get snubbed or excluded for one reason or another. This happens. It’s normal and is part of the learning process.   But in time, the aim for any agile team is to continually make these old exclusive unconscious habits conscious so that work environments can continue to embrace a greater diversity of people, not just of cultural backgrounds but from different social and economic backgrounds, too.   The difference in life experience from someone who has lived in poverty to someone who has lived in wealth is as if they grew up in different worlds, even though we inhabit the same earth. Everything is different. Language. Behaviours. Hopes and Dreams. Everything is different on any level.   However, just as different races are now joining together in work and in marriage more often, so are people from different socio-economic backgrounds coming together too, in work, in community building, in families.   The pain of the growth is a worthwhile investment into a brighter and more unified future not just for us but for the generation to follow us. Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Making Unconscious Habits in Culture Conscious in Agile Teams appeared first on Agile Advice.

Categories: Blogs

AutoMapper 5.0 speed increases

Jimmy Bogard - Fri, 06/24/2016 - 23:43

Just an update on the work we’ve been doing to speed up AutoMapper. I’ve captured times to map some common scenarios (1M mappings). Time is in seconds:

  Flattening Ctor Complex Deep Native 0.0148 0.0060 0.9615 0.2070 5.0 0.2203 0.1791 2.5272 1.4054 4.2.1 4.3989 1.5608 134.39 29.023 3.3.1 4.7785 1.3384 72.812 34.485 2.2.1 5.1175 1.7855 122.0081 35.863 1.1.0.118 6.7143 n/a 29.222 38.852

The complex mappings had the biggest variation, but across the board AutoMapper is *much* faster than previous versions. Sometimes 20x faster, 50x in others. It’s been a ton of work to get here, mainly from the change in having a single configuration step that let us build execution plans that exactly target your configuration. We now build up an expression tree for the mapping plan based on the configuration, instead of evaluating the same rules over and over again.

We *could* get marginally faster than this, but that would require us sacrificing diagnostic information or not handling nulls etc. Still, not too shabby, and in the same ballpark as the other mappers (faster than some, marginally slower than others) out there. With this release, I think we can officially stop labeling AutoMapper as “slow” ;)

Look for the 5.0 release to drop with the release of .NET Core next week!

Categories: Blogs