Outsourcing Revisited And No One Is Safe
By Paul Kenjora | December 27, 2008
The recent article Outsourcing Killed By Django And Ruby On Rails has caused as much proper debate as it has blind controversy. The feedback provided by readers here as well as other sites like Y Combinator and Reddit have brought up some good points. If I had to write the article again here is what I would change…
Drop the US as an example, define outsourcing relative to any geographic point. If you’re in Germany as US developer would be considered offshore. The same problems and the same numbers would apply.
Remove references to quality, focus on incurred cost of outsourcing. Quality is difficult to quantify and easy to debate. When frameworks like Django or Ruby On Rails effectively reduce core project development (coding) significantly enough, periphery project costs grow in proportion. Communication can become the bottle neck, for example. A time zone difference of a few hours (8 - 12 in the case of US to India) means project decisions have a significant lag. Over the phone or email communications are not as effective as face to face time, especially with cultural and language differences. Even with highly experienced staff the cost of doing business time zones apart is higher than face to face.
Avoid the term “low skill”, and focus instead on the risk of hiring talent you’ve never interviewed face to face. There is a reason Ebay, Google, Microsoft, YouTube, and so forth interview people in person before hiring. The risk of making a bad hiring decision that will cost significant dollars down the road drops after a good interview. How does one interview an individual several thousand miles away with the same level of confidence? You can’t, hence a risk of outsourcing that can be avoided by hiring local, which is made possible by frameworks like Django and Ruby On Rails.
Place emphasis on cheap labor as the target segment. Of course there are expensive developers everywhere, there are also cheap ones everywhere. Here in the US we have both, same as India, China, and Germany. Point is you get what you pay for and the mantra around outsourcing (at least here in the US) is cheap. Its a brand that was crafted by the outsourcing companies, now its back firing. Bean counters think dollars not skills and in US corporations bottom dollar wins out more often than not. So chances are if a US company outsources to India, it will outsource to the lower bidder regardless of skill.
Write a whole paragraph about how it doesn’t matter that developers in India or anywhere can pick up Django or Ruby On Rails. The frameworks have marginalized development to a point where its not the selling point. Communications, coordination, risk, and schedule are now selling points. The risks in those areas only get worse with off shoring or outsourcing across time zones.
Reference some of the frameworks in Java, PHP, and Perl that came before Django and Ruby On Rails. Yes, there were others but none as successful. Why? Ask the developers of Django and Ruby On Rails, they figured it out. For the rest of us, the important question is what does it signal for the future of web development. I’m guessing the end of off shoring, at least for a while.
Emphasize that Python is not Django and PHP is not Cake. Too many comments came back giving metrics for Java vs. Python or inferring PHP is the same as Cake. The discussion is around Django (not Python) and Ruby On Rails (not Ruby). Python itself reduces some development and coding because its an interpreted language with no type casts. Django on the other hand is a collection of functions crafted for the sole purpose of developing web applications. There is a huge gap between the two, thats why the focus is on the effects of Django on outsourcing.
The original message holds. No matter how you dress it up or how much mud gets flung at it, Django and Ruby On Rails are killing outsourcing. There will always be jobs, and like many readers pointed out, good developers will always have them. The difference will be that they will come from down the street instead of the other side of the world.
Outsourcing Killed By Django And Ruby On Rails
By Paul Kenjora | December 14, 2008
The absolute pinnacle of outsourcing madness peaked with the publication of “The 4 Hour Workweek” by Timothy Ferriss. The book was a Bible for starting your own sweat shop. Everyone from one man startups long forgotten to mega corporations like Ebay were looking to India, China, and eastern Europe to cut development costs. There is even a story, famous among cubicle dwellers, of an IBM engineer outsourcing his job to India, then using his free time to get and outsource another job at Motorola.
I guess if 80% of your job consists of writing many lines of code to achieve even the simplest task, like processing a login form, then 80% of it can be outsourced to lower skilled developers at a lower rate. A skilled and novice developer can churn out the 80% filler code almost at the same rate. Thats exactly why projects involving heavy C++, Java, Perl, and even PHP have been at the forefront of outsourcing. Those languages do not have a framework for rapid web development. When most of the work does not require creativity or great skill it will be outsourced. The math makes sense.
Take for example a project in Java requiring 100 hours at $80 an hour for a skilled US contractor. Thats an $8,000 price tag for 100 hours of Java code, not much considering the mundane complexity of getting anything accomplished in Java. Now take a developer from India, China, or Slovakia (formerly Czechoslovakia) for $20 an hour, you get 400 hours for the same price. Even the skill difference won’t be a risk. A low skill developer will be able to churn out 80% of the project in the same 100 hour time frame as a skilled one. Imagine all the basic for loops, form manipulation, and boring HTML boiler plate code written in any given project. That leaves another 300 hours to compensate for the skill gap. More than enough to mitigate risk in most cases. As a matter of fact you’ll probably be able to shave $4,000 off that price tag and still have a 100 hour buffer on a 100 hour project, 100% risk mitigation. Any bean counter will tell you, outsource, outsource, outsource…
Enter Django and Ruby On Rails….
I see it happening already, its subtle, both frameworks are a ripple on the non-corporate pond. In the coming months they will grow into tidal waves, forever changing the economics of outsourcing. The numbers are changing already. A local company, OpenRain using RoR, is able to complete monster projects for a few thousand dollars with a level of testing that would make aviation systems engineers salivate. Entrepreneurial developers at PayPal and Google are producing entire websites every other weekend. Its happening so it has to be possible, how you ask?
Frameworks like Django and Ruby On Rails have removed coding as a schedule bottle neck by removing mundane boiler plate code. That 80% is now gone, developers can focus on the 20% that delivers features for the project. No more assembling forms or creating database queries. The speed of development is now restricted purely by creativity. This works tremendously well for web applications because both frameworks were built with that space in mind. The 80% reduction in development costs shatters the economics of outsourcing!
The same 100 hour project with all the filler code obfuscated by Django or Ruby On Rails now takes 20 hours. A skilled developer at $80 will put the project costs at $1,600. Thats $2,400 cheaper than even the most optimistic $4,000 outsourcing estimates using Java plus outsourcing. That difference makes outsourcing a dinosaur compared to Dango and Ruby On Rails.
Some bean counters will be tempted to take it a step further. Why not outsource Django and Ruby On Rails work to low skilled low price developers?
Its not worth the risk. Outsourcing using Dajngo or Ruby On Rails using the sample 100 hour project, now reduced to 20 hours, will cost $400. Build in a buffer of 20 hours and the price tag is $800. Saving $800 over a higher skilled, more reliable, and more creative $80 an hour developer. That savings means you’ve effectively washed all creativity from your development team. Risk is through the roof, you have all the drawbacks of outsourcing concentrated in the most important 20% of your project development, the user facing features! Its not worth $800, be happy with the $6,400 saved.
This is already happening, its a fundamental shift in development. For corporations, once they catch on, it means huge savings even over outsourcing. For high skilled developers it means creativity and talent will be more important than ever. For low end outsourcing labor it means carving out a space in testing and data entry or being replaced. Oh yeah, Django and Ruby on Rails are exponentially speeding up all of the above!
Clearing Django Form Fields One By One
By Paul Kenjora | December 10, 2008
I just spent an hour looking all over the web for something everyone assumes everyone else already knows. If you’re new to Django and you’re trying to clear a form field on validation then the solution is not intuitive.
Take a common scenario, you have a CAPTACHA image and the user enters it incorrectly, next time around you want to clear it and show an error, the rest of the form should be preserved. How do you clear a Django form field?
Wrong: Create a new form and copy the data across. This is not only overly complex, prone to error, and generally poorly readable code, its too much work. Don’t do it!
Correct: When populating the form from request.POST or request.GET make a copy of it and then clear the data attribute for that field. Here is an example:
The secret sauce is self.data['some_field'] = ”. The form itself does not contain any data, so trying to dig through the form attributes to clear a field is a dead end. If you do dig down deep enough, you will find that the form calls a widget method that goes to whatever data was associated with the form and fetches it. Hence clearing the data attribute works!
This makes sense to developers who’ve been around Django and its methodologies for some time. For novices the intuitive approach is to manipulate the form. Hope this gets picked up by enough searches to save others some time.
Topics: Forms, Tutorial | Comments
Developer Intern Position At Arkayne
By Paul Kenjora | November 6, 2008
Position: Developer Intern At Web 2.0 Startup
Location: Phoenix, AZ
Arkayne is looking to bring on an intern to join our development and quality assurance team, with a future transition to a full time pre-money employee. As an early member of the startup team, you will have the chance to contribute along different dimensions, from conceptualization to research to implementation. You will be using Python, MySQL, and JavaScript to create the next revolution in blog marketing. The ideal candidate should be familiar with scalability design and client-server applications. We want someone who truly loves coding and has a passion for simple and efficient designs.
Arkayne is an early stage blog marketing startup founded in Phoenix, Arizona. Our mission is to change the game for bloggers from popularity to relevance. Arkayne offers bloggers a widget to instantly cross link content and buy or sell links based on relevance.
Your responsibilities include:
- Work closely with the rest of the development team to develop our web application
- Implement new product features using Python and SQL in an Apache/Linux environment
- Applying basic user interface design skills when implementing features
- Work closely with cross functional founding team
- Take on additional roles as needed to help us build a great company and product
The ideal candidate is:
- Entrepreneurial - thrives in a fast paced and changing work environment and willing to wear multiple hats
- Driven - motivated by the ability to make an impact
- Sharp - comfortable with new technologies and a quick learner
- Action oriented - gets stuff done and hitting milestones
- Team player - enjoy being part of a young and talented team
Requirements:
- Degree in Computer Science or lots of relevant experience
- Experience coding in Python, PHP, or C++
- Excellent verbal and written communications skills
The following are bonuses:
- Experience creating web applications
- Experience creating scalable databases
- Experience in Django, HTML, CSS, JavaScript, AJAX
- Experience with Apache, MySQL, XML, client-server applications
- Understanding of object-oriented design principles & methods
Interested candidates, please email your resume to support [at] arkayne [dot] com. Please note where you saw this posting.
Topics: Arkayne, Tech News | Comments
Link Exchange For Tough Times
By Paul Kenjora | October 24, 2008
Advertising on Google is getting expensive, very expensive. This year advertising costs for Adwords rose between 40% and 60% for some advertisers. Companies like eBags.com and Babyage.com have seen the cost of advertising online soar to 45% of the cost of the product they are trying to sell. Margins are diminishing and its only going to get tougher as consumers spend less.
Everyone dropping Adwords seems to be flocking to organic search. Caught in the middle are bloggers where Search Engine Optimization (SEO) competition has gotten brutal. SEO communities like Sphinn.com are soaring in popularity because bloggers are seeking any advantage over the competition. As authors spend more and more time promoting and optimizing, less time is spent on content and post quality. Its a vicious cycle thats going to lead to a blog bubble where the cost of blogging will outstrip most peoples resources.
Take or example a site by Nicholas Aretaki on relationships, Ditching Mr. Wrong. For Nicholas the costs of Google advertising became counter productive this year. He was simply forced out by multi dollar click through costs for the top Adwords positions. He’s shifted his efforts to SEO through an outsourced team with better results. Nicholas is fortunate, not everyone has the resources to hire an SEO team.
As the competition for traffic rises the game will have to change. I think all to often bloggers get caught up in the hype. Following every SEO trick of the day does not scale and cannot work. There are over 112 million blogs and growing on the web today. Webster’s Dictionary defines over 165,000 English words. Add an estimated 500,000 extra names, phrases, and slang words. Simple math yields 168 blog pages per Google keyword. Each blogger is competing for the top ten spots. Add all the other sites outside blogs and the numbers get even more daunting.
The point is that returns diminish quickly, the average blogger does not have the resources necessary to get to the top 10 spot and expect to stay there. As competition for the top spots on Google, Yahoo, and MSN heat up many blogs will simply not keep up in this economy.
The solution is as simple as it is frightening. Find alternatives. Before Google came around Yahoo and Lycos were thought to be the end all. Google changed the game and saved online advertising when it was about to burst by introducing page rank. All signs point to another bubble, crippling advertising costs, an SEO frenzy, and a hurting economy. Page rank is going bust, the saving grace this time will be relevance rank.
The new wave of relevance rank is already starting to swell. The first one out of the gate, Sphere just sold to AOL for $100 million. AOL stock jumped a tenth of a percent as a result of the acquisition. Following close behind is Zemanta which just received $40 million in seed funding from Union Square Ventures. Yet to be funded companies like Arkayne are starting to drive significant amounts of traffic based on relevance. Overall, alternatives to Adwords and Google SEO are starting to emerge for bloggers to take advantage.
The barrier to entry for these new relevance engines is nothing compared to popularity. Take Arkayne as an example. Any blogger embedding the widget creates ten instant links based on post similarity. Every outbound link has one or more inbound links in an Arkayne widget on another relevant post. If a more relevant post with higher relevance rank is added the list in every widget affected is updated. The result is a highly relevant set of links on every post driving traffic within a niche topic of interest.
The new technologies are not just shifting from popularity to relevance, some are looping in social and viral aspects of advertising. In the case of Arkayne, the widget provides an additional one click Get and Put link exchange between any two posts. The feature allows any reader to cross pollinate relevant links between blogs. Readers become a bloggers best tool for building reciprocal links.
Anyone interested in exploring relevance linking tools can request an Arkayne Invite.
New Django Site For Porsche Enthusiasts
By Paul Kenjora | October 22, 2008
Recently I’ve completed a revamp of Patrick Motorsports on the Django platform. The owner, James, has been working with Porsches for more than 15 years. He races Porsches, builds Porsches, and sells parts for Porsches. Overall its a cool shop, every time I’m over I see a dozen cars in various states of rebuilds and tune ups. We started working together over 5 years ago and the site has made some interesting evolutions since then.
2003 - We Met
It all started in November, when I called an ad for "Help needed building website for local Porsche business.", in the Arizona State University State Press. I called in, met James a few days later, I negotiated for beer money, he wanted to grow his business. We agreed and started things off fairly informally.
You should have seen his website, it still makes me chuckle. Imagine a middle aged man kneeling next to a transmission, with barely legible text poorly formatted on a single page as one giant image. That was it, no links, no other content, not even an email. Considering the web in 2003, many small brick and mortars were in the same predicament. The web was still owned by white collar silicon valley corporations and geeky college kids. James knew it was changing, PayPal was starting to catch on and Ebay was booming.
2004 - Starting Point
The first revisions were to create some real content. We took his entire PeachTree database of parts and exported it to a MySQL table. Over the span of a few weeks I layered on a C++ back end and a very simple non-CSS template. It worked for the 10 or so visitors he was getting each month.
He began promoting his website to other shops, at events, and on print material. I’m amazed by how different the small business auto industry web is from mainstream websites. Imagine a world where customers think state of the art is five years ago and whats on some of the most successful websites is not what they want. It was tough going but James and I managed to get some key elements on Patrick Motorsports.
The biggest seller to this day has been the Project Gallery. Its a section of the site where James can document the various stages of a build in photos. From looking at Goolge Ananlytics, over 70% of our traffic came in from the gallery. To improve sales, we added a parts list for every build. It worked sales started to climb.
2005 - Getting Bigger
Initially James and I had planned on linking in with PayPal but decided against it until his internal processes were fine tuned. When sales picked up to a point where customers were asking for online checkout, we settled on a order by email system as a stop gap. Any order you place on the Patrick Motorsports page is reviewed and processed by email.
It actually worked in his favor considering the nature of his business. We’re talking about a shop that builds cars worth many tens of thousands of dollars for specific customers. James had a reputation and a standard of quality to preserve. Rushing into impersonal online sales too soon would have been risky. Email and phone based orders allowed him to fine tune each order with the customer, ensure the parts fit the customers vehicle model, and make each customer understand how absolutely knowledgeable and dedicated he is to his trade.
Late in the year Brian came on board to help with the growing number of parts. The site was beginning to outgrow itself, the old C++ code was getting tough to manage. We needed someone to come in and update all parts, prices, projects, links, and descriptions. Customers would call in and mention how it was difficult to find a specific part. Brian was the young kid who knew about cars, was an excellent graphics artist, and picked up the website super fast. Over months he built up the photo and parts library from a few dozen to thousands. You can now spend days browsing through all the content.
2006 - Taking A Break
Not much happened to the site that year. I was in Tucson working for Tucson Embedded Systems. James was busy growing business and expanding his shop. We made minor changes to the site but nothing huge.
2007 - Going Django
In October, James decided to make the site more user friendly and take ore of an Amazon style approach to product recommendation. The gallery and exclusives sections were becoming hard to manage. Cross linking all the parts was taking more and more time. We decided to redesign the administrative interface.
We quickly realized C++ wasn’t going to cut it. It would take less time to develop the site from scratch in Django and provide us more flexibility down the road. By mid September we had a the new site up and running. Instantly we saw bounce rates in Google Ananlytics cut in half while page views sky rocketed. The revision was a success!
The trick was the extensive product recommendation. We wanted every single page on the site to flow into more options. The Patrick Motorsports site is so heavily cross linked you can browse through all the parts maybe 12 different ways and never get lost. Cars link to parts, parts link to projects, projects link to specials, specials link to catalogs, catalogs link to parts, etc… Basically everything links to everything and the back end alows one person to administer it all sanely.
2008
The past year has seen a shift in focus, all the numbers are good but they could be better. James is focusing his efforts on external marketing. We are taking SEO seriously and going after more traffic aggressively. I see it as another phase in an incredible project that has come a long way since the strange one page website.
Last week we kicked off a whole new design for the menu as well as the home page. With cool cascading menus and improved home page navigation the site really pops. As far as car part sites go, this one has the best mix of navigation, information, and eye candy. The next few months will be exciting as Patrick Motorsports expands projects and part selection even more.
If you’re an interested Porsche enthusiast, James gives tours. You haven’t fully appreciated speed until you’ve driven his 1973 Porsche 911 RSR - 3.8L at full throttle.
Custom Actions In Django Admin Object Editor
By Paul Kenjora | October 7, 2008
I’ve seen many posts asking for the simplest feature in Django admin… the ability to add custom actions next to History and View On Site in the Django admin form. The page where the actual object is edited, not the list pages. Imagine adding actions like:
- Edit Next Item
- Edit Previous Item
- Send Thank You Email
- Export Record As CSV
Thats just the tip of the iceberg. Basically any action can be performed. The concept is simple, create an buton for an action, redirect to a handler with model and id of object, execute any code, then redirect back to the admin page. This would turn Django admin into any application the developer chooses.
I first wrote on this topic in Adding Custom Actions To Django Admin Change Forms, back when Django was in version 0.95. I’m writing this post again to document the code port from 0.96 to 0.96 and above.
Changes To Django
First add code to Django to facilitate custom actions. Working backwards from the template is the simplest way to visualize the changes.
Step One: Add a list of custom actions to the Django admin change form template. I added the for loop…
contrib/admin/templates/admin/change_form.html
You may have noticed that the custom action will call a URL of the format /admin/handler/model/id/. I think its simple and provides enough information to identify the object being edited in all circumstances. There may be some overlap with admin URLs so please be careful or change the URL here.
Step Two: Add a member to the Django admin change form handler to be passed into the template. This is just a one liner, add form_action to the context dictionary.
contrib/admin/views/main.py
Step Three: Add the new custom form_actions field to the Admin class. You’re really adding it to the AdminOptions class, but you get the picture. I added the form_actions to the function signature and the list of member variables.
db/models/options.py
Those three files is all you have to edit. Now you have support for custom actions. I assume you’re OK with the custom action protocol I implemented above. If you want to change it then I leave the edits up to you. If you take me at my word, then all you have to do is add the proper code to your models file and your URL handlers.
Your Custom Handler
All the pieces are in place on the Django admin side. Now to create a custom handler.
Step One: Add a list of actions to your model definition under the Admin class.
models.py
If you refresh your Admin page here you will see the new custom action.
Step Two: Create a handler for your new action in the URL handler. Remember if you use admin as your prefix then place the handler regexp before the one for Django admin.
urls.py
You’re done. Add as many custom actions as please you. I recommend redirecting back to the Django admin page after executing each action. You have the model id and the object id, you can even create generic handlers for any object. In my case I typically only use the object id, each handler is model specific in my case.
Request To Readers
I would really like it if this feature was included in the official Django release. Please leave a comment in support of this code. I would like to approach the Django maintenance group and petition a feature request based on your comments. The more comments in support, the more likely we will see this in the official Django version.
Topics: Admin Revisions, Tutorial | Comments
PayPal IPN Python Code
By Paul Kenjora | October 2, 2008
PayPal has Instant Payment Notification (IPN) libraries with examples for Perl, Java, and even Ruby, but look as hard as I may none for Python. Then again I spent 2 years at PayPal as a senior developer, C++ and Java are the dominant languages. Django and Rails are not even on the radar (well I exaggerate a few people have vision). Point is I couldn’t find any clean and simple IPN code for my Django projects.
Yes, I know, I know…. There are other posts with source code for IPN. For example Google Code has an example. So does Django Snippets. Both are great examples but I don’t need a shopping cart or Google checkout, I just need PayPal IPN.
I decided to roll my own, after all I spent 2 years looking at the source code how tough could it be? Not tough at all actually, it just takes a while to dig through the documentation. Below is the source code for PayPal IPN. Its tested, and deployed on several projects.
The above code is the bare minimum required to correctly process an IPN request. Everything else you can setup through the PayPal sandbox. They even have a testing tool just for IPN within the sandbox.
Looking back on the code, I guess that PayPal does not have a Python/Django library or examples because its so simple. Once you have the IPN code above everything else is fairly straight forward. Assembling the purchase request, cart or single item, is not too difficult. You can do it using a simple HTML form. Encryption on the payment button is nice but IPN is even more secure so I would not spend too much time on the encrypt.
Topics: PayPal, Tutorial | Comments
Calling All Django Bloggers
By Paul Kenjora | September 24, 2008
I’m looking for quality Django blogs to include in a closed invite launch of Arkayne. The posts should consist of at least a paragraph or two, have well formed HTML, and willing to provide feedback on the performance of the Arkayne widget.
The team here at Arkayne will help configure the widget to match the look and feel of your blog. We will initially configure the widget to show only internal (from the host site) links. The Arkayne widget does have allow users to copy and paste links across any two widgets. Links are always ranked by similarity. I’d like to run a test of how well the widget performs at cross linking on the topic of Django. An example of the widget can be found at the bottom of this post (not on the index page).
Did I mention the links are 100% automatically generated by Arkayne, just drop in the widget. No need to mess with tags anymore.
If you would like to participate please request an invite: Arkayne Invite Request.
I will contact you with an invitation code. Thanks!
Topics: Arkayne, Tech News | Comments
New Django Site: Samz Market and Gourmet Foods
By Paul Kenjora | September 24, 2008
For the past 2 years I’ve been looking for a place like Samz Market and Gourmet Foods to open up within 10 miles of my house. I have a 4 mile commercial dead zone, with only a Quick Trip gas station near. At the edge of this dead zone are 2 shopping malls and 2 shopping centers. All containing generic fast food and chain restaurants. I’m not complaining, its nice to go out for a burger or dine at a high end trendy restaurant but sometimes I just want something Mom would make. A nice fresh made sandwich without a any grease in sight…
I knew Samz Market and Gourmet Foods was that place as soon as I walked in. What I didn’t foresee is that I’d be doing the restaurant’s website. Sam (the owner) and I started talking a bit, it was the first week the store was open. I mentioned what I do, create websites for small businesses, and she suggested I create a proposal for her new place.
Within a few days I outlined a basic plan to get Samz Market and Gourmet Foods online and visible to the world. Nothing too dramatic, just three pages for the menu, contact, and directions. Sam had some of the graphics for me, and she had a general idea of look and feel matching her restaurant. The technical as well as business plan was well understood by before we started the site. A few intermittent days of work later we had a finished website.
It was definitely among the smoothest projects I’ve been involved in. I started thinking about what made it so successful. Sam is thrilled with her site, her friends and colleagues have complimented the work. I too am happy with the results but even happier with the process. I think the secret to success was that Sam trusted me to fulfill her vision. She gave me broad goals, we worked together to determine a budget, and set expectations for when things will be delivered. Beyond that Sam was hands off, she trusted me to deliver a solid site and I trusted that she would pay for the work. We mitigated risk by agreeing to incremental delivery and payment. We both met goals for delivery dates and payment dates. Granted it is a simple website, so there is little margin for error but the keys were absolutely trust and accountability. Planning and setting expectations is key.
On any project, Django or otherwise, keep in mind that the customer must feel comfortable about hiring the developer. Avoid the pitfall of being so eager to deliver a technical solution that the business plan does not align with the site two months into the project. Saying no to a feature today may save the project and ensure continued mutual benefit down the road. With frameworks like Django and Rails, developers should have more time to deliver better quality not just quicker implementation. Django should allow developers to start stepping into the roles of consultants. Remember, developers are vested in implementation while consultants are vested in the customer’s success.
