Why I Love UX (or How to Piss Off an Entire Department!)

Last Friday, I tweeted something which was badly worded, and managed to piss off much of our UX team (not to mention a few UX people far and wide):

Pissing off UX

Now I ask you, how could that post possibly offend anyone (note sarcasm)?

So, I would like to clarify what I was thinking when I posted that (and again ran into the problem that most of my thoughts do not fit into 140 characters).

First, I had been reading a number of posts and other articles by so-called UX experts, thought leaders, and others (all off whom shall go nameless, as I do not need anymore flames – well, actually I enjoy flames, but am full at the moment). Like many fanatics, they have (in my humble opinion) some fairly radical beliefs that are not well grounded in the real world. These are the “UX people” to whom I was referring in my post. Yes, my choice of words was bad.

Secondly, I have a great deal of respect for the UX process. I even have a lot of respect for most of the UX people I know (even the ones with whom I disagree). Frequently it is the UX department with whom I have an issue. I have the same issue with Marketing (the department) versus Marketing (the process), and with Architecture (the department) versus Architecture (the process).

The comparison with architecture is particularly relevant, as I have had many arguments over the years in software organizations as to whether “architect” is a role or a job title – should there be an “architecture group” separate from the development team. My belief is a resounding NO! I tend to believe that “architect” is a role which and individual with the appropriate skills and training assumes on a specific project. On another project, that same person may be a senior developer. My concern with architects in a group by them selves is that I have frequently seen these groups (a) become extremely elitist; and (b) become too far removed from the reality of implementation, leading to architectures which are elegant, beautiful, and difficult to impossible to build on-time and on-budget. Often, the 99% philosophically correct, current-best-practice architecture is not necessary, when the 80% solution can actually be implemented on-time and on-budget.

I find that UX groups is some organizations, and UX thought-leaders in the world at large, are falling victim to much the same challenges I described for architecture. Too much separation between UX and implementation creates certain challenges.  And, there is often little willingness to deviate from the “philosophically correct vision” in favour of practical reality.

And as a final thought, I definitely do not have all the answers in these areas – I just have some very definite questions about how we (in the global sense) do things.

SharePoint Governance a bad Idea?

Wow! Just wow! I was reading this post by Paul J. Swider, and I kept waiting for the punch line that never came.

I have a great deal of respect for Paul – I have seen him speak, and follow his posts and tweets regularly. While this presents an interesting counterpoint to conventional thinking around governance, I am afraid he lost me on this one.

First off, lets look at the comparison to Y2K. Is he saying that no one should have invested in fixing Y2K issues, and that no systems would have failed if nothing had been fix? That seems to be what he is saying, since he is comparing Governance to that, and obviously governance is only good if it does not cost anything.

Then there is this statement:

“Many companies haven’t had governance and compliance features in place for there information systems for years. This has been true since I started working with software in the early 90’s”

This is like saying “for many years, most companies did not have software development processes”, and using this as justification that no investment should be made in such processes. Ditto for QA, or project management. We survived without much investment in any of these silly processes.

Just because lots of organizations are using SharePoint and do not have governance, does not mean that they are doing so effectively or the best way they can. It is also still too early in SharePoint’s lifetime to truly assess the long term costs of doing it wrong.

Finally, lets look at

“Most CIO’s and managers I speak with are tired of hearing about soft dollar calculations and want hard dollar cost savings immediately, after all these are complex and challenging fiscal situations they are managing.”

It is true that most CIOs and managers are being pressured into short-sighted approaches to many things. That does not mean that they should abandon meaningful and appropriate processes just because times are tough.

(would you suggest abandoning corporate governance and controls because money was tight? oh wait, I think many on Wall Street did)

Paul’s example needing a new purchase process to respond to funding cutbacks is a good one, and provides a good segue to what I see as a more positive takeaway from this discussion, which is the appropriate use of process.

Through much of my career, I have been involved heavily in process – whether software development, QA, test engineering, innovation, or otherwise. For many years, I worked on military and aerospace projects, which are noted for extremely heavy processes. What I learned from all of that was that you can invest in all the process in the world, and still fail miserably. And even when you succeed, the overhead involved in such processes makes them untenable.

This has led me to what I have referred to previously as just enough process (I know I am not the first to use the term). The software development process must match the context – the type of organization, the type of solution, the potential impact of failures of the system, the potential lifetime of the system, etc. A software development process appropriate for a social networking web app is hardly acceptable for medical devices.

The same is true of SharePoint governance. Cookie cutter approaches will not do. Off-the-shelf consulting processes will not do. This is not a one-size-fits-all kind of thing.

Rather than encouraging the total abandonment of governance processes, or treating governance as a “nice to have” luxury that you do away with in favour of short-term perceived cost savings, it is far more appropriate to encourage clients to find the level and type of governance process which suits their situation.

After all, isn’t that what a good consultant does? Helps the client find the solution that is right for them, rather than applying the same solution to all clients?

RE:Lean software development using Kanban

Nice post. Before I write anything critical about it, I want to make clear that I think the Kanban approach is very interesting.

I have a few thoughts though, as I always do when considering agile versus "heavy" processes for software development.

First, there seems to be a bit of confusion regarding "heavy processes" and "waterfall models". Heavy processes do not necessarily imply a waterfall approach to development. I was working 20 years ago on heavy (really heavy mil-spec projects) which were employing iterative, incremental development models with frequent releases and continuous integration, nightly builds and test-driven-development, before so-called agile approaches became popular.

My second thought is around development speed and quality. The post makes a significant claim regarding the performance improvement achievable without sacrificing quality. I would love to see real stats on this across a broad spectrum of projects. It also depends upon how you define "quality", and what level of quality is acceptable. Most applications developed today for the public (especially mobile apps and web content) have very low quality requirements, as the implications of a "glitch" are not that severe. On the other hand, banking and online payment software have significantly higher quality needs. Moving on to military, medical device, and other software upon which lives depend, definable, demonstrable quality objectives are required.

Over the years (over 25 years now – man I feel old suddenly) I have led or been involved with software projects following a large number of different processes, from no identifiable process at all, to heavy mil-spec processes, to modern agile processes.

Each approach had its own value, even the "no process" model, and each had its weaknesses. The challenge I have with many proponents of agile processes is that they promote agile as inherently superior to heavy processes (of course, heavy-process oriented folks do much the same towards agile folks).

In my experience, no model works for all situations. Much like selecting a technology or a programming language, it is important to select the right approach for the right job, without being too enamoured with any one approach. While a mil-spec approach is not appropriate for a small team in a start-up, an agile methodology is equally inappropriate for a 10 year, multi-billion dollar, life-critical military project employing hundreds to thousands of developers.

Recently (well, in the last 10 years), I have become a big fan of what I term "just enough process" (which I talked about in a previous post). Always use the right tools and processes for the right job.

Thoughts in the Middle of the Night

I am just coming off an all-nighter – it has been a long time since I got so wrapped up in coding that I worked all night.

After I got to tired to code effectively, I got reading some blogs and thinking on various topics. One the things I was thinking about (obviously not for the first time) is the whole open source software movement. As always, there is a fair amount rhetoric out there regarding the superiority of open source software, the TCO of OSS applications, the advantages of development under the open source model, etc., and even conjecture about the ultimate demise of all non-OSS development.

A number of questions have always nagged at me about the claims of OSS:

  1. Believers frequently claim that OSS produces better software, with “better” defined in various ways – fewer defects, better functionality, more secure, etc. Is there empirical data to support this on a broad scale? Yes, there are examples frequently given, but usually it is a comparison of one or more highly successful OSS project against one or more bad examples of commercial, closed-source applications. Is there any broad, unbiased comparison of large numbers of OSS projects to large number of non-OSS projects?
  2. Similarly, Believers often claim that the process of open source development is much more efficient, effective, and innovative that its non-OSS counterparts. Again, OSS success stories are frequently compared to horror stories form the non-OSS world. Is there any large scale, unbiased comparison out there? For example, it is often quoted the a very large percentage of software projects are late, over-budget, or complete failures. Is the open source world any better? People always talk about the successes of OSS, but take a browse around SourceForge some time – there are a huge number of projects there that are never completed, never deliver anything, never get past Alpha, etc. The OSS statistics always seem to be somewhat selective.
  3. Many people predict the demise of closed-source development (and have for a long time). Are there any clear statistics out there as to the number of developers working on OSS versus non-OSS development (I know, many do both). Or is there information as to the economic force of OSS versus non-OSS – how much economic activity in the IT world is driven by OSS?

I don’t have answers to any of these right now – just some thoughts which occurred to me through the night – hopefully I will have time to dig deeper into this over the next while.

Re-focusing

So, the time has come to re-focus my blog a little around what I am currently working on. In the last year, I have gone through a fairly significant transition in my career. After close to a decade in a product-oriented startup, I have moved into a consulting role at T4G. This is a big change for me, at least it feels like it – the mental shift from focusing on products, product features, and product life-cycles  to focusing on client engagements and project-oriented work. My mind tells me that in many ways the two are not so different – they just feel very different.

The main focus of my work (at least initially) is on portal technologies, specifically SharePoint. In addition to the engineering and mechanics of implementing SharePoint solutions, I am focused on a number of other related topics:

  • A repeatable approach to delivery of SharePoint solutions
  • Process/methodology models for SharePoint implementation
  • Estimating models for SharePoint projects
  • The art of the possible – what could clients be doing with SharePoint

I will also be spending a significant amount of time establishing a Moncton office for T4G. By the way, if anyone knows any SharePoint resources (or good .NET or ASP.NET resources in the area, send them my way 🙂 ).

While my new role is as a consultant in an consulting company, I do not plan to abandon my roots in software development, software development processes, and programming. I also maintain a strong interest in innovation processes. Finally, there are a number of technology areas I am continuing to investigate, including Tablet PC applications, Silverlight, Office Business Applications, Social Networking, etc.

I am also hoping to have more time to blog a little more regularly 🙂