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 🙂

Fred’s Law #2: Requirements, we need lots of them!

As I have already said, doing away with requirements altogether is a really, really good way to ensure that your project will fail in a spectacular way.

Another really good approach to being bad is to try to capture every possible requirement that anyone might ever want, ever. There are a number of advantages to this approach as compared to the “no requirements approach:

  • You can create the illusion that you really know what you are doing
  • You look like you are being extremely diligent
  • You always look like you are extremely busy
  • You create huge amounts of documentation to support the illusion that you have been both busy and diligent

Unfortunately, you may never actually get to the end of the requirements gathering process. If you do, you will probably either have missed the window of opportunity on whatever you wanted to build, or you will have produced a set of requirements so convoluted that no one will ever implement them.

On the upside, you will have greatly reduced the risk of the actual development failing, since you probably will never get there. You will save huge amounts of money on developers, as well as computers and tools for them.

So you never actually have a product to sell, or software to use. You will have done your job well, it will not look as though your project actually failed, and it will look great on your resume as you look for a new job.

 

Share this post :

 

Fred’s Laws #1: Requirements, who needs ’em?

Well, I guess it is fitting to start out Fred’s Laws at the beginning of the process – with requirements.

If you really want to start of on the right foot, and get your project well on its way to a spectacular flame out, this is a fantastic place to start. Remember, the best way to figure out what your software needs to do, how it should do it, and what it should look like, is to get your coders right in there coding. After all, who knows what the user wants better than coders?

This is especially true if you are building something new and innovative, or if you are short on resources or time. Just think of all the time you will save by not having to talk to users up front. And, all those resources you would have wasted talking to users can be redirected to more important things like coding (whether they know how to code or not). Just imagine how far ahead of schedule you will be right from the beginning!

Now, estimation and scheduling may be a challenge without some definition of what you are building, but you probably will not be doing any real estimation or scheduling anyway (see later laws). If you need to have estimates and schedules to show to management, you can always make something up out of thin air (but make sure not to talk to your developers about it!).

(and just think how much time you will save talking to users later on, since you won’t have any!)

To be really specific, make sure you avoid any of the following activities, which are known risk factors which could lead to success:

  • Set up a system for capturing requirements, using Access, Excel, file cards, or any other tools
  • Establish a process to review and prioritize requirements, and assess their value versus cost
  • Define a process for managing changes to requirements
  • Involve users or user representatives in the creation and/or review of requirements

All in all, avoiding requirements definition should save a great deal of time up front, and allow you to focus on the important work of trying salvage your failing project.

Share this post :

 

Fred’s Laws (again)

Some time back (late September) I promised a series of posts on what I term “Fred’s Laws”, a set of rules you can follow if you are determined to have your software development project fail miserably.

Back in September, I promised I was going to post a law per day until I ran out of things to say. That lasted, well, zero days :-). For various reasons I felt it prudent to delay posting these for a couple of months.

The laws I am going to post are in no particular order in terms their impact. I am not sure how many of these laws there will be, and I am not even sure that they will not end up being self-contradictory.

(hey, I am doing this like a typical software project!)

I think the laws will fall into a few main categories:

  • Requirements
  • Project planning and tracking
  • Process, methodology, blah, blah, blah
  • Working with management
  • Working with marketing
  • Quality, testing, etc.
  • Technology and tools

Something to keep in mind here is that I am a big fan of process in software development. Not of big, heavy processes, but of some process. If you are going to go from A to B, you have to follow some process to get there. There is value in having some level of predictability and repeatability in that path. You may vary the path with the circumstances, but you should at least know what path you are improvising around.

Also, I do not believe that there are any rules which you can follow which will guarantee perfection in you software development efforts (at least not if you are building anything interesting). All of the rules, and process, and other magic spells can do is to improve your probability of success, and allow you to see when you are heading down the path of failure, allowing you to make some intelligent decisions along the way.

On the other hands, the are a few rules you can follow which can almost guarantee that your project will fail. Combine a few of them together, and you can make your failure truly spectacular. Stay tuned…