File > New > Project: Developing a New MSDN Magazine!!

For some while now, my colleagues were asking me about my plans for the magazine. In other words, my editorial line, editorial style.

This post is all about it.

While I’ll plan to keep magazine’s main structure composed by regular columns and featured articles, and I have no intention to touch the current technical depth (explicit coding in articles, downloadable code samples, etc.) I’ll put some emphasis based on five mindsets that I'll explain shortly.

  
Figure 1. A typical N-tier, layered architecture.

This is a simplified diagram of a typical multichannel architecture. Real-world architecture diagrams share some similarities and possibly some few variations with this diagram. I assume you are already familiar with this schema; if that is not the case or you prefer a more detailed explanation, I posted a 101 here. But the important thing to know here is that when you already have a blueprint to base your application on, adding new end-user functionallities (i.e. use cases) is a straighforward job: the blueprint already prescribes you which spots must be filled, which components must be provided and with which responsibilities each. This makes me come to the first mindset:

1st Mindset: Architectural Consciousness

ASP.NET won’t prevent you to issue a database command right from the page itself, or it’s code beside however… it’s that good? It may work in small, controlled, non-mission-critical applications but the design principles that are being violated there are a basic two: high cohesion and low coupling. In that sense, dear reader, it's my intention to show you technology usage under the frame of a diagram like the above one. Thus you'll find where is the right place to put data logic, how to deal with cross-cutting concerns like security or quality attributes (performance, user experience, and so forth).

For sure, we’ll still keep code examples lighter in that sense, as samples are to help you focus on a detailed aspect of a given technology. Once you got the point with code samples, we’ll help you understand where that technology or technique fits in a typical world-class scenario. Thus, application architectural consciousness is the first mindset I’m taking into account for my editorial line.

But application architecture is just one aspect. The diagram above is oversimplified and doesn’t show details on how tiers communicate. For that diagram, was intentionally made like that to help you focus on functional aspects. Once you got those, you’ll need sooner or later to be aware about other aspects that are present when you want to put all these pieces together.

Let’s imagine for a while that we are talking about a deployable desktop application (a desktop client-tier above or, simply, a desktop channel). We may focus just on presentation aspects like new Silverlight features or data binding in WPF, but in order to complete the panorama for that kind of applications, we must also consider deployment conditions, subsequent releases, coexistence of different versions, coexistence with other applications in the same workstation (with possible incompatibilities, resource allocation issues, etc.) and a long list of potential issues that may arise.

It may be argued that several of those issues must be solved from the infrastructure, being therefore part of the TO-DO list of an IT Pro, not a developer. I admit it. It’s not my intention to make you an IT Pro expert and we already have a prime magazine for IT Pros: TechNet magazine. But just to broaden your vision about certain tactics beyond the scope of the development camp, that may save you a lot of man-hours in trying to tackle the issue by coding. So, if the first mindset was “application architecture consciousness”…

2nd Mindset: Infrastructure Awareness

We (Microsoft) realized that we were not doing a good job these last years in the strong, all-or-nothing content segmentation we delivered through either MSDN or TechNet but almost never through both. We were segmenting our audience in developers and IT Pros, assuming that any possible intersection between those two sets was, in the best case, pretty thin. Occasional.

In the times to come, dear reader, this won’t keep being the norm as reality has shown that, depending on the size of organization, its IT departments, etc, two or more roles may be played by a same team member (for instance, in my personal case, I played at the same time the architect role while taking care of the IBM WebSphere application server in production).

We won’t merge MSDN and TechNet, for sure. We just want to avoid developers coding low-level components like tracing and monitoring logic in their applications because they ignore that they may generate events to be captured either by the operating system or a system management tool like Microsoft System Center or its competitors. We want you, developer, to know that despite ClickOnce is a smart, easy way to deliver applications, it's not the only one and in certain scenarios it could have limitations. For those scenarios there exist other techniques not-based in Visual Studio but in other products in the Microsoft platform. We won't explain those techniques in detail for you but we make sure that you can find more information about those techniques easily if you want.

In fact, in real-world applications, strategies comprise a series of tactics. Some being developer practices, some being IT pros ones. Which one is easier to apply, more cost-effective, etc. will depend on the context, but being aware about all those is a great starting point to understand your strengths, your limitations and be ready to raise your bar and get ready to grow.

Enough, for the moment, with application architecture and infrastructure. Let’s now talk about about problem solving. It’s pretty common to say “who only has a hammer, thinks that every problem seems a nail”. A friend of mine also told me “if you learn that a developer just read GoF book on design patterns, don’t let him/her design your next applications.” What my friend meant was that the degree of excitement everybody got after reading that one or any other book on application design was a bit damaging in the short term. Indeed, the anxiety to put in practice those concepts just acquired betrayed us pretty soon, making us adopting a supposed solution for what was not exactly a problem. Or at least, not the problem that solution solved.

The GoF is just an example, but this happened with almost every new concept we acquired (AOP paradigm, MVC presentation pattern, Composite Application Block, …) The third mindset, in that sense, is all about taking right technical decisions.

3rd Mindset: When and When Not, Why and Why Not

The problem of applying wrong techniques or technologies is very often complemented with the overdose symptom: applying a right solution but in excess. An example? Web services. They are an adequate solution to make interoperate distributed applications, mainly when they were coded in different platforms. However, calling methods between different tiers implies a reformulation of the communicational model. In other words, while we can make applications “converse” we shouldn’t make them “chat”. Otherwise, message marshalling/unmarshalling, serialization/deserialization steps will undermine the latency and users patience. Worse, we may later extract the wrong conclusion if we end up by believing that we should have get rid of web services.

To avoid misunderstandings, we’ll tell you not just the what and how-to of technology. We’ll now put some emphasis in its when and why. And for sure, we’ll do that same regarding their negatives: what not to do, how not to do, why not, when not.

Enough said regarding architecture, infrastructure and problem solving. Let me share now some thoughts about the environment.

4th Mindset: We, the People of the Project Team

Are we, the developers, the only people in this world? In world-class projects, aren’t there other stakeholders in the value-chain? Certainly not: there are not only more people but also processes in place, intended to estimate, measure and control the application lifecycle. We, the developers, are a substantial part of that process and without us no software can be delivered. But as we are not alone, we must be conscious that other stakeholders in the value chain might take decisions that could affect the way we develop software.

Examples are several and I’ll tell some here but I can imagine that you will immediately remember your owns.

A DBA prevented me to use an object/relational mapper (those days the most evolved one, with several books written about it) because its lack of support for stored procedures obliged him to open the database security not just at a table level (increasing, thus, the surface attack and consequently the risk) but also accepting commands generated on the fly by the O/R-M. As that data-access strategy was generated by the application on-the-fly (during runtime), he had no chance to tune the commands the same way he did when already enclosed in stored procedures. We had a bitter discussion. Each one, explaining the benefits of his own approach. I told that the O/R-M was helping me save lots of hours of data-access logic development. He said that we were to pay that saved time forever when the application was in production, plus the security risk. We escalated the problem to the management. No matter who was right, he won. If we were discussing about development techniques, the management would have probably supported me. But we were discussing about the database and that guy, coincidently, was the database administrator (where you wondering what "DBA" stood for?).

In that same project I tried to apply an agile approach. It seemed to be the perfect environment to do so: a small team, everybody coding (including me who was playing an architect and project leader role, all at once). Users were fascinated with the dynamics of the methodology: prototypes that were at the same time executable and incrementally incorporated new features (user stories, in the jargon). We were forced to stop and switch back to a waterfall approach. Why? Because despite the support of mid- and low-level users, not just the IT management but also managers in business departments were anxious to get a fully detailed project timeline with deliverables, milestones, etc. To make things worse, one of them swung by one of his subordinated and saw a running prototype. The same that users were excited about. It was just that this guy was not only not excited, but he also made a very bad publicity about the project and myself as a development manager, telling that what we were delivering was tremendously far different than what they were expecting and I had promised during early phases. The more I tried to justify and explain the methodology, the more the board got scared. Checkmate in that scenario.

The moral of the story is not that you shouldn't apply an agile approach: the moral is that whatever you do, you'll find other stakeholders and everything may be subject to a negotiation. So be prepared to negotiate, to convince and to conceal, as clearly we, the developers, are not alone in world-class development projects. MSDN Magazine will provide as part of the coverage on technologies, impact on other stakeholders and potential conflicts of interest.

And last but not least…

5th Mindset: Solutions for Today and Tomorrow

Regarding the timeliness of our stuff, not just the magazine but Microsoft in general, we got some criticism based on the fact that we make extent coverage on technologies that are still evolving, in detriment of the ones that are already out there. As evolving technologies are not yet released, readers can’t do too much but wait until that happened. Coming back to the previous point, in several organizations we, developers, are not allowed to deploy betas, CTPs or any other early-access bundles (at least not in mission critical applications). I'll take that into account so while I won’t completely remove that kind of upcoming stuff (as we want you to get a glimpse about roadmap and future of the .NET platform), I’ll narrow the amount of such kind of information per issue, making sure that most of the core is immediately actionable in your rolled out projects.

Wrapping Up

I told you, dear reader, about the mindsets I’ll apply while directing MSDN Magazine content plan. We’ll try at any time to put technologies under the frame of a broader scope, in terms of application architecture, infrastructure platform and the project team. We’ll do also emphasis on best/bad case scenarios of technologies and techniques, taking care about a reasonable balance between released vs. upcoming technologies.

In upcoming posts, I’ll describe a tentative column lineup, community participation in the content acquisition process and changes in the magazine website.

More to come!! Keep in touch!!

Sincerely,

Diego Dagum
Editor Director
MSDN Magazine