Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
Die, AOL, Die
The new plan is for MSN to become a software and services company, a model that Microsoft is definitely familiar with. Rather than running its own ISP company, MSN will work with telecomms companies to package a branded broadband service.
In my book, I provided a description of each of the properties of the System.Web.HttpBrowserCapabilities class. The original draft explained the .AOL property "Indicates if the client machine has been infected with a virus that propogates itself in CD form. This virus tricks the user into installing it, offering 1000 free hours of connectivity." The editor noted "do we really want to say this?" and took it out of the final edit. Self-preservation...
AOL is really the portal concept moved to the client desktop. I'd like to see MSN take this same approach, just one step further. The concept looks just like a news aggregator: Provide customized XSLT skins for your ISP with preconfigured "skins" on the client's desktop. Instead of MSN.com's layout being fixed with a couple customizable sections, make the whole thing customizable with a couple logo requirements. Then MSN Explorer could have some semblance of utility. Better yet, make the desktop portal integrate with Office 2003's InfoPath, and yield the ultimate blogging tool.
Self Preservation in Blogging
I have so much I want to say, but self-preservation prevents me from saying it here. I think I'll have to start a personal blog that requires a password for readers to read it (which I'd probably not give out due to laziness or a certain....humility?). Its not that I care who reads it, just that I care who doesn't read it.
I typed out a rather lengthy diatribe this weekend on management practices, "How (Not) to Manage Software Practices." As most folks do, I drew from personal experience of pointy-haird-bosses who were promoted beyond their competency into project management. That diatribe never made it into the blog, largely out of self-preservation and the recognition that pissing off any potential clients in a questionable economy can lead to career suicide. I would love to mention the number of times a manager told me "we don't have time to figure out the requirements, we have a deadline in 2 weeks", and provide context for the manager's other "measure once, cut twice" decisions. But providing such context would leave little ambiguity to a happenstance reader that worked on the project, and I am not willing to risk testing the 6 degrees of separation rule.
I had also begun a similar work on "How (Not) to Write Software", inspired by the Lazy Programmer's virtues. As before, I started to draw from experience. I thought of considering what I have seen that was atrocious yet was delivered on time. I wanted to offer several project post-mortems, examining the impact of the combination of shortcuts 6 months, 1 year, and 3 years down the road. I have not given this title up, but cannot help but recognize the same issue: be careful who you anger in the short term, as they may ask you to help rewrite that same poorly written software in the long term. From the comic ("Storing a 3 meg recordset in an ASP Session variable per user seemed like a good idea at the time") to the frightening ("It's highly extensible and configurable" translating to a brick house without mortar).
One client team-lead even insited that Microsoft transactions implementations were "too complex, and besides, I haven't worked with them yet... I think we should just use a file to control transactions." I still contemplate mailing him a copy of Tim Ewald's "Transactional COM+", but I know the binding would never get broken on that book. Which takes me back to the Lazy Programmer and why I vehemently disagree with the concept: while lazy programmers may get the job done quickly and easily, they are typically responsible for core components of software that are rewritten within a very short period of time due to lack of functionality or improper handling of exception conditions.
Maybe one day I will decide to write a diatribe railing on both inept managers and lazy programmers alike, but for now, I should stick more closely to XML related topics. Back to the XML article on why the DOM sucks for server applications...