Aug 26, 2014
Apr 10, 2014
About 18 months ago my Visual Studio 2012 Cookbook was published by Packt Press. Fast forward to a few weeks ago (March 25th in fact, I’m a little tardy on getting this post out) and an updated version of my book has been published, the Visual Studio 2013 Cookbook.
I’ve been a little time poor over the last 12 months so I need to give a big shout out to Jeff Martin who made a large contribution to the book and without who it wouldn’t have happened. Thanks so much, Jeff!
For those wondering what’s new, here’s some of the major changes in this version:
- Updates throughout the entire book to keep it in line with the various VS2013 changes (no surprises there!),
- A major update to the web development chapter based on the ASP.NET changes, editor improvements and new tooling such as Browser Link,
- A major update to the Team Foundation Server chapter, with particular focus on the new Team Explorer and git source control integration, and
- A new chapter on using TypeScript and Python with Visual Studio.
As with the previous edition, this book isn’t for everyone. It’s for those people wanting to get up to speed with the changes and improvements in VS2013 and is going to be more suited to those coming to VS2013 from older editions of Visual Studio, or those who are used to Eclipse or XCode and are wanting to know how to get to grips with an unfamiliar, and very powerful, IDE.
Go buy yourself a copy from Packt or your favourite book selling web site today!
Mar 10, 2014
I just ran across the sad story of yet another failed software project (I missed it first time since it happened across the Christmas period). In this instance we see Avon writing off a $125 million project to revamp their sales systems and doing so after the initial pilot deployment was met with so much hate and derision from their people that sales staff were resigning from the business in massive numbers rather than working with the software.
This is a project that was started in 2009 and it wasn’t until December 2013 when the project was (mostly) killed off. That’s a 4 year investment of hard work and sacrifice from so many people to produce, well, nothing. Actually, not quite true. They did produce the software world’s equivalent of anti-matter, a substance that destroys everything it comes in contact with. It damaged corporate reputations for both Avon and SAP (well, maybe not SAP since their reputation is already heavily tarnished), it’s decimated Avon’s largely voluntary sales force, strangled sales revenue and cash flow, and burnt through $125 million and 4 years that could have been spent on building something that was actually valuable and useful for the business.
The culprit? It’s hard to point fingers anywhere other than Avon’s poor management and the poster child for expensive enterprise software that’s almost impossible to install and use without bus loads of specialist contractors; SAP. Of course, SAP aren’t taking any blame. No sir! They’re blame shifting to other vendors and trying to throw them under the bus instead. No doubt the same bus that is now shipping out all those expensive SAP contractors, of course. SAP are saying that they only built the back end and it was those other incompetents who people built a front end with poor usability that is at fault. Sure, SAP, you sit there and pretend that a back end doesn’t define the business processes and doesn’t impact usability.
"Many representatives couldn't even get logged into the new website, and once you got in, the system was not accepting orders, it wasn't saving orders properly, and it wasn't reserving inventory."
- Karen Edwards, Avon
Yep, sure SAP, that sounds like a ‘usability problem’ right there.
With so many people leaving, there’s a sadly high human cost to this failed project but combine it with statements like these, I start to get really upset with just how delusional Avon management and SAP must be:
"While the pilot technology platform [in Canada] worked well, the degree of impact or change in the daily processes to the Representative was significant, this resulted in a steep drop in the active representative count."
- McCoy, Avon’s CEO
“Head office kept insisting that the system was working, but it was not”
- Edwards, Avon
“[the] software was working as designed, despite any issues with the implementation of the project”
- SAP media statement
Hang on?! The CEO is trying to tell us that the project and the product are successful, even though it’s an obvious, abject failure? Could the management team’s collective head be stuck any further into the sand? Could SAP be any more uncaring as to the result of their product? I’m staggered!
We can add to this evidence of the ‘Failure is not an option” mindset within SAP. There was obviously no Plan-B. No rollback if things went pear shaped as they did. Instead, they’ll just keep pushing on with their rubbish.
“The company reported it would continue to use the software in Canada to avoid further problems in that market”
- Information Week.
Further problems? Like what? Putting the old system back in place and trying to bring back at least some of their disgruntled sales people? I’m crying right now.
Now, if this was a one-off then maybe it’s forgivable as a $125m rookie mistake. But they’d already failed this way before. In 2011, they screwed up with Oracle, and a logistics ERP rollout in Brazil that contributed to Avon’s then-CEO resigning.
“The roll-out of an Oracle ERP suite underpinning core supply chain and finance operations has posed huge challenges for the company’s operations in Brazil”
The troubles around the implementation have resulted in large numbers of IT staff leaving the company in the last 18 months, according to the source. […] a separate large-scale ERP project was launched recently with a view of transforming other customer service areas. SAP was chosen to supply products for that body of work.
”The [SAP] project will be significantly more complex. And if we work on the assumption that the same difficulties around change will remain, it would be fair to say that this project will take six to seven years to complete”
- IT Decisions
2 years to learn from that failure and adjust how the SAP project was progressing and they did nothing. When will people learn that when it comes to building software, and especially complex software, that the failed methods of the past simply don’t work anymore? In fact, they’ve never really worked in the first place.
When will people learn to stop building large systems over many years and attempting to do a big-bang deployment, without a fall-back plan, and without ever genuinely engaging their user base first instead of just selling them on the promise of something awesome.
Sure, I get it. I’ve lived it myself. Large and complex systems are hard to build, but let’s not make it harder than it needs to be. Start by building something for a small subset of the end solution and prove it works. Incrementally grow from there to meet your goal. Get user engagement and feedback early, not just from the management team. If you do go down the wrong path and build something that turns out terrible you’ll know about it early and have time to adjust rather than forcing your steaming pile of effluence down people’s throats and watching them quit.
Identify the value in your system and deliver on the key high value items first, your minimum viable product. After that pile in all the other features you want over time and subsequent smaller releases. Who knows? Avon may have been able to save up to $50m if they’d failed with a much smaller product first. If they’d done that though, I suspect that we wouldn’t be talking about them at the moment.
Finally, be brutally honest and transparent with where a project is at. I can’t image the number of times people on the SAP project said there were problems and it was going to fail. I can’t imagine the countless times that project managers and senior execs who wanted to report that things were ‘green’ shut down anyone who voiced problems. I can, on the other hand, imagine the ego, politics and bluster that drove this project off the road, through the guard rails and over the edge, resulting in the disaster that somehow execs still believe is a success.
Oh, and for the love of all things good in this world, please stop using SAP and the horrible waterfall based project practices that seem to go hand in hand with that shambling behemoth.
- Avon to Halt Rollout of New Order Management System (WSJ)
- Avon Pulls Plug on $125 Million SAP Project (Information Week)
- Inside Avon’s Failed Order-Management Project (Information Week)
- Avon’s Failed SAP Implementation (Forbes)
- An insider’s view of Avon’s ERP troubles in Brazil (IT Decisions)
Mar 6, 2014
There’s a funny/strange behavioural difference when clicking the ‘Edit in Visual Studio Online’ link in the Windows Azure management portal between Internet Explorer, Firefox and Chrome.
In Chrome you will be taken straight into the development environment and the Monaco editor as expected. That said, if you watch the network trace in Fiddler you’ll actually see that there’s an initial failed initial authentication request before a second attempt is made with a different set of request headers.
On Firefox you get a slightly different behaviour and will be asked if you want to log in using an account based on your site name with a $ prefix, as shown here:
But in Internet Explorer it’s different again and you get prompted for your credentials.
If you try and log in by entering your Microsoft Account (Live Id) details it won’t work. You could try using the $ prefixed account that Firefox asked you about, but what password would you use? I’ve got no idea.
So what’s going on here?
It turns out that this is an IE security behaviour that occurs when the first auth challenge fails. Because Monaco in VSO uses same infrastructure as Azure git deployments (the Kudu project) to connect to the web site’s host virtual machine, it’s not your Microsoft Account but your Azure deployment credentials that you are being prompted for. I presume it’s your Microsoft Account details used in the first, rejected, request and then after that you need to put in your credentials. Why Chrome allows you to connect with a different account on the second request, I’m unsure. I’d expect that a security nerd could fill me in on all the gory details.
In any case, if you can’t remember what those Azure deployment credentials are (why aren’t you using a password manager!) then you can always reset them from the Azure portal. Be aware that this changes the credentials used for all your git based deployments on all your Azure sites.
I’m hoping that this is only a temporary difference in behaviour and that future updates fix the inconsistencies. Until then, enjoy using VSO and Monaco! :-)
You can find his post about it on his blog, and I've embedded the video here for your benefit. Enjoy!