Issues With The Tool-First Approach to Technical Presentations
If you scan the events calendar of your local Microsoft-related user groups and conventions there's a pretty good chance that a large proportion of the presentations involve one of the following scenarios:
- A rundown of all the cool features in a product or tool
- A demonstration of a subset of a product or tool's features, usually presented as a contrived example with no real world equivalent
No one seems to be complaining about this either, which could be a good indication that the "tool-first" approach to technical presentations is exactly what the public what they want.
I would argue, however, that it is not what they need.
We get enough of the sales spin and demo-ware from the companies that make these tools. There are plenty of resources out there on the Internet for us to learn about the specific features offered by a product, with companies often employing an army of evangelists to create articles, videos and sample applications for you to digest in your own time. I mean, why give up time that you could be spending with your family/loved ones/pet projects/gaming consoles/guitar collection to hear someone read out a feature list from a product's website or run you through what amounts to a TechNet article that you could have read yourself in a fraction of the time? I just don't see the logic in it.
When I attend a presentation I want to take full advantage of having a real live human being in front of me. I want debate. I want opinion. I want war stories. I want to interact and have a conversation with the person presenting to make the experience worth my time. Ideally I'd want to walk out of the presentation with an altered outlook on how I approach work, having just had my methods questioned, changed or reaffirmed.
You simply can't get this from a straight "happy-days scenario" tool presentation where everything just works. There needs to be an underlying message and purpose of some sort; a purpose other than, for example, evangelising version 10.3 of IBM Pokemon WebSphere Black Sapphire Ruby Edition. Marketing material simply does not do this. Presenters shouldn't be afraid to do things like:
- Show the failings of a product as well as the happy scenario where everything works
- Offer an informed opinion based on experience rather than marketing material
- Discuss theory and process, either in relation to a product or tool or not
- Present on a topic that is not tied specifically to a product
- Use their technical example as a means to proving or stressing a point they wish to make, e.g. SharePoint + InfoPath + Reporting Services demonstration could be used to discuss how composite applications can provide a viable means to expand the scope of existing line of business applications to a new set of users without increasing training costs
If we don't get away from this tool-first approach then the audience are going to leave presentations believing that downloading/purchasing a product or tool will solve all of their woes, which as we all know is never the case. We get enough of this junk from software vendors; we don't need to be perpetuating this myth for them.
Which Type of Architect Are You?
This article is part of a series of posts that originated in a talk I did at the 2011 Perth SharePoint Saturday event.
Around 10 years ago, when the IT industry needed to pinch another fancy title for itself after engineers got sick of us using their professional title, the term "architect" started popping up in job ads and an entirely new career path for developers was born. Sure, we annoyed real architects, but who cares about that? We had something to look forward to after being promoted to Senior Developer! Skip forward to today and we now have a bunch of job titles that sound posh but have no solid definition. Some of the generic, non-product specific "architect" roles include:
- Information Architect
- Business Process Architect
- Solution Architect
- Application Architect
- Systems Architect
- Software Architect
- Enterprise Architect
- Computer Architect
- Technical Architect
- Infrastructure Architect
- Technology Architect
Then comes the product-specific architect titles:
- SharePoint Architect
- Oracle Architect
- Cisco Architect
- SAP Architect
- Citrix Architect
- Active Directory Architect
- .Net Architect
- Java Architect
- COBOL Architect
- World of WarCraft Architect
OK, so I made the last two up, but my point still stands. There's a lot of different positions out there and a lot confusion about what these roles are actually responsible for.
As someone with the title "Solution Architect" on their employment contract I have a vested interest in clearing up the confusion around this issue. In a recent presentation I even went so far as giving "rough definitions" to some of the more common types of architect that you'll find in the wild just so I could have a common vocabulary with the audience. Here's a slightly augmented version of the list I used with a few other terms thrown in:
| Type of Architect | What I Think of When I Hear This Term |
|---|---|
| Application Architect | "I'm connecting SQL to WCF using EF (Magic Unicorn Edition) and showing with WPF" |
| Solution Architect | "I'm connecting your CRM to your ERP using an ESB in the ACT" |
| Enterprise Architect | "I'm synergising your benefits by leveraging the power of The Cloud" |
| Infrastructure Architect | "Use a VPN to connect to our LAN to access LDAP and IMAP" |
| Information Architect | "Organise the metadata in the site structure using taxonomy and folksonomy" |
In an ideal world I would love to see the general architecture titles standarise on something like the list above and the product-specific architect roles go away. When I saw "go away", I mean that I'd love for people to stop calling themselves things like "SharePoint Architects". Each one of the general architecture roles I mention above has a core set of skills associated with it that apply regardless of the product space being worked in. "SharePoint Architect" tells me nothing; do you build specific applications, set up infrastructure, define taxonomy? It's much more useful to define the skillset and say that someone has a specialisation in a particular product
Using the non-product specific roles would also solve the problem of having no standard set of expectations to compare different architects. A new product being released shouldn't be a trigger for a bunch of unqualified people to start calling themselves architects just because they want to hit a certain pay grade. It would also stop Application Architects who know how to build an application on a certain platform (e.g. .Net or SharePoint) from calling themselves Solution Architects or Enterprise Architects when they don't know the first thing about orchestrating a process between different systems in an organisation (i.e. Solution Architecture) or waving their hands and spouting buzz words at the CIO (i.e. Enterprise Architecture).
I honestly think that our professional vocabulary needs to be updated to include common definitions of what we think these roles involve, and there needs to be some control over the tasks that a person has to be capable of before they can call themselves an architect. This is especially true given that we are stealing the term from a rather well organised profession that does have standards and guilds and all that other funky stuff that legitimises an industry. We don't necessarily have to go so far as having guild fees and written exams, but it would be nice if people stopped calling themselves "Enterprise Architects" because they "know a lot about Lotus Notes".
The Many Faces of Workflow
As previously mentioned, I spoke at the Perth leg of this year's SharePoint Saturday. The slides I used during the presentation are below:
I had originally intended to present a light overview of what Business Process Management is, list some of the tools then do a deep dive into how BizTalk 2010 and SharePoint work together as an example of how you can still use SharePoint's workflow as part of a larger process management solution, but a few things happened that day that ended up making me rethink the content I was going to present on the fly:
- I had been put on the developer track as there was no architecture track, making a discussion about integration scenarios and design patterns a hard one to have
- Most of the presentations that day had been presented from a "tools first" point of view, which I generally find unhealthy
- I had a LOT of business users and non-coding SharePoint folk in the audience, meaning my intention to deep dive into the BizTalk SharePoint Adapter was off the cards
I was pretty happy with the resulting presentation, and judging by the feedback so were the vast majority of the audience (There were a few haters in there that basically wanted me to do a tool rundown like most other presentations, but that's a topic for another day...), so I thought it would be a good idea to collate some of the thoughts in the following series of blog posts (links will be added as I complete each post):
- Which Type of Architect Are You?
- Issues With The Tool-First Approach to Technical Presentations
- The Fallacy of End to End Process Execution
- The BPMS Jigsaw Puzzle as it Relates to SharePoint
Hopefully I'll finish these posts soon. If not, I'll leave this post up as a testament to my slothful ways.
Consulting Contracts and the Behaviours They Encourage
In a recent post I spoke at a high level (and at length, it seems) about the things developers need to know about different consulting company contracts they might encounter in the workplace. After reading the article, fellow Perthie and all round awesome guy Mike Minutillo pointed out that there's some good information in that there about what different contracts cause people to do, but it's hidden in a big sea of text.
To that end, here's a list of the key things that each contract incentivizes the different parties to do. If you want a more in depth explanation of each contract type then check out the aforementioned post. It should be noted that these are not things that you're guaranteed to get; it's just that typically these contracts encourage people to act in a certain way in an attempt to "win the contract". It's by no means complete, but it should be a good start.
| Consulting firm is more likely to... | Client is more likely to... | |
|---|---|---|
| Fixed Price - Fixed Scope |
|
|
| Fixed Price - Variable Scope |
|
|
| Time and Materials - Capped |
|
|
| Time and Materials - Uncapped |
|
|
The Potential of LightSwitch
When Microsoft LightSwitch Beta 1 first came out there was a huge uproar from the development community. People were angry for various reasons; some thought that it would lead to non-developers "stealing our jobs", while others were sure that it would lead to a flood of poorly architected applications whose very existence was bound to cause offense to any respectable developer.
The recent release of LightSwitch Beta 2 has thrown the product back into the limelight, although the exposure is accompanied by mixed marketing messages around exactly who the product is targeted at. Microsoft are in the middle of a marketing campaign trying to convince the community that LightSwitch is a tool for end users to crank out forms over data applications (we even had the always friendly Andrew Coates over here in sunny Perth to put forward that very view), but as Tim Anderson points out, the product somewhat misses that mark. Tim prefers to liken LightSwitch to a modern day FoxPro or Visual Basic, but I prefer to see it in a slightly different light.
The real potential with frameworks and tools such as LightSwitch is not to enable the end user to create applications; the very fact that IT need to be involved to deploy the application puts a stop to that. Also, it doesn't replace VB or FoxPro, both of which allow the developers a large degree of freedom and potentially allow them to run up a fairly large development bill. No, the potential is to turn the $100k internal IT project into a $10k project with repeatable results and reduced risk. This will hopefully result in IT being able to help the users who currently turn to Access and Excel for their data capture needs after being turned away by IT due to lack of funds or resources.
Think of the number of projects that get created by internal IT shops that go through full architecture and design phase, most of the time by people who haven't really built an end to end application before, and in the end they just give CRUD access to some data. There are plenty of tools in the Microsoft space already that let us build cheap, CRUD-oriented apps including:
- ASP.Net Dynamic Data
- ASP.Net MVC Scaffolding
- SharePoint 2010
- Microsoft Dynamics CRM 2011
The problem is that, even with these tools and applications, someone still has to put effort into thinking about how the application is put together. How are we going to implement business rules? What patterns do we need to use? How will we persist data? Who's going to sit with the end user while they create 3 months of work the customise the look and feel of an application that's used by 3 people?
LightSwitch is different. For me it's a piece of opinionated software much in the same way as SharePoint 2010's Access Services feature. Developing an application in LightSwitch or Access Services involves very few architectural decisions, as most of the thought has been done for you. With LightSwitch you just pick a database and decide whether you want a thick client or web based application. It's almost Paint By Numbers for enterprise software development.
It also takes the question of UI design out of the picture. Users can't argue about button placement, font size and the amount of padding on a field simply because there is no direct editing of the UI in the product. LightSwitch generates the forms from a tree view representation of the data and allows you to apply a theme, but that's pretty much the extent of it. To me this is one of the biggest selling points; adding UI design to a project is a fantastic way to kill a small IT project and would be counter-intuitive if the aim was to allow IT to assist more users.
You may think that this in some way "threatens the purity of software development", but quite frankly who cares? The users asking for the applications are currently developing their own solutions using Excel, Access, SharePoint and various other technologies that allow them to get past IT red tape. Wouldn't it be better to at least be able to bring them into the fold so the data can be backed up, the application can be supported and IT know what the application is for and how critical it is to the business?
I would love for LightSwitch to succeed in spite of the current marketing message from Microsoft. Backing the "user created applications" horse on a product that requires interaction with IT for deployment is the wrong idea; their other self-service application platforms such as SharePoint, Excel and Access have succeeded because they allow the user to bypass IT altogether. Still, I hold out hope that enough people understand the real potential of LightSwitch and other tools like it. The technology may not be there yet, but the idea of having a cheap, uniform approach to developing applications in an enterprise IT shop is one that's filled with promise.
MineCraft Modding Resources
My 8 year old is an enthusiastic MineCraft player. It's basically modern day Lego without the expense of buying thousands of dollars worth of plastic blocks. Over the last few months she has built up a fairly impressive town and is now approaching the point where she wants to do more. The various MineCraft video podcasts she watches on YouTube opened her eyes to the world of modding.
We installed a few pre-built mods for her to play with, but things have now gotten to the point where she wants to create her own. I'm still not clear on whether she wants to actually learn Java and cut code for the mod, as she may be perfectly content scribbling instructions for me in her notebook. Regardless, I thought it would be a good idea to start collating resources on how to actually go about modding MineCraft.
Before you start anything, make sure you're familiar with where MineCraft stores it's application data; things like your save files etc. On a Windows 7 machine it generally uses %AppData%/.minecraft. Be sure to back this folder up before doing anything funky with your MineCraft install, lest you end up with a bunch of corrupted save files. You can always replace the MineCraft executable, but it's a bit harder to re-create the hours of work you may have spent building your own in-game version of the USS Enterprise:
Firstly, you'll need a copy of the MineCraft Coder Pack (MCP). Essentially MCP is a Java toolkit that decompiles the MineCraft .JAR files (the packaging format used by MineCraft to wrap up all the Java class files, metadata and resource files needed by the application in a format suitable for distribution) allowing you to edit and recompile the app. It also has a bunch of helper classes, batch files and a bunch of other fun stuff to make the experience more pleasant.
Next you'll want to check out the list of MineCraft Modding Tutorials on the MineCraft forums. If you scroll down in that forum post you'll see an excellent guide to setting up Eclipse to use the MineCraft Coder Pack. My 8 year old appreciated this as she has never seen Eclipse before; her only development experience so far has been with Python using IDLE and LOGO using KTurtle.
The list also contains some basic tutorials that get you started with cutting code against the MineCraft codebase. There are more tutorials like this on the tutorials section of the MCP Wiki
There are also a number of options for playing around with MineCraft that don't involve cracking open Eclipse. Be sure to check out the following:
- MCEdit, a MineCraft Map Editor
- The MineCraft Wiki article on Skins has some great info on modifying player and NPC skins. It also has quite a few sample skins and links off to a few external skin repositories. This is really handy for getting your head around what a MineCraft skin needs to look like before creating any of your own.
- INVedit is a MineCraft inventory editor that my 8 year old is currently using to give herself all the items she needs to create a world of her own.
- The MineCraft Wiki Mod page has a list of third party mods as well as links to various Mod managers that let you install mods without cracking open the .JAR file and recompiling it yourself. As with all development endeavors, it's worth checking to make sure that the feature you're trying to add hasn't already been written by someone else, making this a good place to check before you open up Eclipse.
- The Single Player Commands Mod gives the player access to commands that add a whole lot of functionality to what you can do in-game. Here's a cool explanation of what the mod can do:
- You can download save files (maps) that other people have created or distrubute your own.
Something cool that's mentioned on the MineCraft Wiki is the possibility of server-side Lua scripting coming to MineCraft. Notch, creator of MineCraft, mentioned it in a post way back in 2009, so I'm not sure if it's still on the cards. Still, he does mention that it will be coming during the beta, and MineCraft has only recently reached beta. If they do introduce server-side scripting then I'd imagine the barrier to entry for MineCraft modding would be significantly reduced. Still, for now it's a good excuse to teach my 8 year old some Object Oriented Programming concepts which she hasn't been exposed yet. Just a pity it has to be in Java.
Headshot
About Garry
Me On The Web
User Groups
Post Calendar
Tags
Who's Online
7 visitors online now
0 guests, 7 bots, 0 members
Map of Visitors
Blogroll
- Coding Horror
- Cup(Of T)
- Haacked
- Joel On Software
- Otaku Software Blog
- Rands In Repose
- Scott Hanselman’s Computing Zen
Archives
- April 2011 (7)
- March 2011 (4)
- July 2010 (1)
- May 2010 (1)
- January 2010 (1)
- July 2009 (1)
- April 2009 (1)
- February 2009 (1)
- January 2009 (6)
- December 2008 (2)
- October 2008 (1)
- August 2008 (1)
- July 2008 (3)
- June 2008 (4)
- May 2008 (5)
- April 2008 (12)