So on the second day of Connect, Microsoft did held two additional events at their New York building – VisualStudio Connect and FSI DevConnect. Based on my interest, I have chosen the latter – here is a small subset of those topics I'm allowed to speak about. In the morning of the FSI DevConnect, I saw ScottGu again – but without his signature red shirt I hardly recognized him, he dodged it for a blue one, I think the cloud finally takes over 🙂

We started with setting up the topics for the day: How to do DevOps in a heterogenous environment. How to do testing in such environment. What is the tooling in such polyglot environment. What to take on from microservices and containers today and in the future. What does service fabric mean on premise. What interop strategy scenarios should be considered. What is the WPF story. What is the client story now with continuum. How to paraphrase mobile first for an enterprise.

As I pointed out in the previous writeups as well, next to having monolith IDEs we should focus on a different approach as well – same applies not only to an IDE, but also generally for the management, operation, development, etc work. As such, we have to consider moving from integrated set of tools to rather pick the best tools and just make them work together more. Considering the new openedness of the Visual Studio marketplace, the number of extensibility options for both Visual Studio, Visual Studio Code and Visual Studio Team Services, Microsoft seems to embace the idea in full. The amount and level of extension points allow us to hedge the path forward, especially in the cloud. With regards tooling, this enables everyone instead of chasing technology, rather to leap forward to new approaching quickly – the power of the community.

We discussed the lack of focus on Microservices both in the announcements, but also on our day-to-day work – as these tend to be not really visual, and it's rather hard to do a nice presentation when you are just showing up a bunch of nice linted JSON files; therefore (the lack of good) presentability is really a capping feat for them.

Coming with enterprise focus, we have had to move the elephant out of the room – it's very nice and we are super proud that Microsoft at last is bringing .NET from a Windows centric world to the wild – but as they haven't started this when the technology was born, therefore there are tons of existing application, knowledge, systems written with it. What should I, the developer, already on Windows take away from the current landscape? Part of that is the changed cadence and delivery by Microsoft – we are already receiving Windows 10 Update 1, we are looking forward to the end of the month when .NET 4.6.1 would be released along with Visual Studio 2015 Update 1. And we know all of these are inplace updates – that is a risk! We should embrace the tooling (APIPort and Analyzer) to mitigate it, and also embrace various smoke tests and UI testing capabilities to make sure we can keep up with the cadence, especially if our applications are used outside the enterprise managed zone.

With this new cadence came also an interesting question – if we look at let's say how HTML5 is evolving, there were many standard that came, changed a few times than vanished forever, and HTML5 developers were fine with this. How should a company like Microsoft do the same – the attack surface of an operating system or .NET is still considerably bigger than the browser. We should someone start differentiating between 'we are committed to doing it', 'we are planning to do it', 'oh, we are just experimenting, but you should still use it, just be prepared we might kill of or resuit this underneath you with little warning' – e.g. this is nice in theory, but how would you get people use the latter? How would you move people off of the 'no longer recommended' function and release, and not letting them stuck forever?

We could not walk next to the other question – should I pick a docker image (or probably rolling my own similar containment strategy) OR should I use full VMs? Is there a need for a new middle ground that hasn't been yet looked at? Same way, we do have those people who are command line enthusiasts, and those who are the GUI lovers – is there a middle ground, should these people come together more? Now that windows became managable with command line (and we have SSH as well), does docker suddenly need a GUI?

Next session was supposed to be how to do DevOps on and with mobile, but we really did go wild with the discussion instead. We did look into how portable libraries became available across technologies and devices without the use of Xamarin, with the upcoming Visual Studio 2015 Update 1. We also discussed the options: if you are a C# developer, Xamarin is the solution for you – native UI, portable technologies, idiomatic C#, calling the native platform. However, if you happen to be a JavaScript developer, Cordova is your tool – high level of code sharing, but not a native look & feel (can be faked with the right amount of JS/HTML/CSS, provided through many libraries; and you need to test your application against many of the browsers (or you have to package the browser along your applicaton with all the security updates on you, as you can do with Crosswalk for Android).

As we have seen on the previous day, Visual Studio is in progress on catching up with non .NET developers – Python is a good example for that. Generally, according to the surveys, Visual Studio is a good brand that resonates well within non Windows developer communities too, and now with Visual Studio Code, and with the free Visual Studio Dev, and with cloud subscription, and with Visual Studio Team Service, and with Community edition, etc. it's really opening towards being a not-just-Microsoft-tech IDE. On the same topic, we could see on day 1, how the Visual Studio installer is leaning now towards to work very much like how battle.net or Steam is working in the way of delivering the actual IDE(s) to your machine, having a better update mechanism, different channels, shared and replayable install experience, etc. cross many platforms and scenarios. We learned about how Visual Studio supports TextMate bundles (TextMate being a very powerful and widely used text editor for the Mac), which is currently focusing on more the visual parts of the editors and only if you add the relevant wrapper around them, but we are getting closer to a more open ecosystem here. Also, if we look at some of the recent open sourced extensions by Microsoft, we can see how simple writing extensions could be, and can learn best practices on how to make these extensions well behave and to isolate well from the others.

A question related cloud and development was next – if we want to be able to use the cloud services for compilation and more, can we (and if yes, how) to encrypt the cloud source/storage for end-to-end SDLC and DevOps – this can only reliable work now if the compilation steps are happening at your private nodes, otherwise there would be a point you would need to uncrypt the sources in the cloud. But generally, we agreed on that our industry is on a (long) journey to the cloud. Data in motion is encrypted. Cloud domains (like Azure AD) is for your authorization and authentication. You can even use IP fencing, or depend on custom leased lines – as it was announced a little while ago, the custom country specific azure zones are also there with no insight into them from outside authorities.

But than, how you can do Agile and DevOps in a highly regulated environment, like a financial company? You need to depend and you need to give a strong role to your QA, but if you start to go in the over-prescriptiveness way – what is the tradeoff there? What benefits you having, are not the barriers overshadowing the gain? So, the idea here might be is to push testing even more – to the earliest point in the technical and also in the business development (prototyping tools, anyone?), this should result in decreased time for testing per release (example for this is the Visual Studio Team Services approach – used to be months of testing, now down for a few days due to the small level of incremental changes and high agility to pull back releases and redeploy). Which all depend on – what kind, level, amount of bugs you can tolerate? You do need to optimize along your feasible constraints here. And counting, measuring is not enough – an example for this: if you decide to measure your developers based on number of user stories being done – you will get lot of user stories done. If you measure based on number of bugs fixed – there would be many bugs, and they will be fixed. None of this measures are really true, only business success count, but you need to reflect that in your system and measurement policies through – which is hard, how does business success show up in a microservice that you just modified?

Also, based on Microsoft's own journey into it – having a workflow for easily and quickly consume opensource packages, with the right level of legal, packaging, building, etc. happening under the hood with an automated system is something everyone should aim to have (probably this is a market nieche, anyone have a sparkling idea for a startup? 🙂 ). On a similar topic – how should you grow your organization, your team, how you should nurture the people? Microsoft did switch to the 'yellow sticky notes process' for a while in some of the teams, which shows good results.

What is the 'yellow sticky notes process'? Actually from time to time you ask people which team they want to be in, have them write this down as option 1./2., and than try to match it with the budgets, project constraints, etc. Based on their experience for running this process for a while, a whoopping 80% of the people are just happy from the fact that the choice was given to them, but not actually asking for a change. Therefore you are only left with 20%, which save for some extreme cases when you have to ask someone to stay with a team for one more iteration, is usually working out nicely. This approach might be not feasible for many organizations missing the agility to do this, but still would worth start be thinking about.

Next post would be focusing on the FSI DevConnect afternoon sessions; here I commence the morning part.