(Update: My view is starting to change from when I first wrote this article. Thanks to numerous people who have pointed out many things I overlooked and have helped me to understand what responsive design really is and what goals it is trying to achieve, I am getting a better understanding of why it may indeed not be a waste of time. There are still some valid points that I brought up in this article, but I don’t stand by my original blanket statement that it is a waste of time. It especially seems like responsive design may be worth the “trouble” for ecommerce sites where you are more much likely to make the sale if someone can easily purchase and browser your products from a mobile device. Thanks everyone who has been giving me great advice and resources for better understanding responsive design and for mostly doing it in a “nice” way.)
Response design seems like a good idea.
At first look, it makes sense. Why wouldn’t you want your same website to scale down to a mobile device and display differently?
For example, there are many WordPress themes now that offer responsive design baked right in. If you are using one of those themes, you might as well take advantage of the hard work someone else has put into making the design responsive.
But, if you are creating a new website or you are considering converting your existing website to a responsive design, I’d suggest you think twice before making the plunge.
The extra work of responsive design
The biggest problem with responsive design is the extra work involved. Sure, there are frameworks and tools to make responsive design easier, but no matter how good those frameworks and tools get, to make a site adapt from the desktop to a mobile device, it is still going to require significant work.
If you have a really simple site with just a few pages or pages that pretty much all use the same layout, but just differ in content (like a blog for example,) then the work might not be that much, so go ahead, make it responsive.
But, if you have a website of any considerable size, you’ll probably find that responsive design is going to add a non-trivial amount of extra work to your project.
It actually turns out the adding responsive design to a web site can add more work than creating a separate desktop and mobile site, because you are creating a user interface that morphs or adapts to the mobile form factor–which, by the way, is ever-changing.
The problem with one-size-fits-all
Consider this. Which is more difficult to create: a car that turns into a motorcycle, or a car and a motorcycle?
Here is another one. Which is more difficult to create: a multi-function printer or a printer and a scanner?
When you try to make a product that can do multiple things, the complexity of creating that product increases exponentially. It is almost always easier to create two separate products that do two different functions or have different form factors, than it is to create an all-in-one product that is able to do many things.
Besides the increased difficulty, trying to create products that do more than one thing usually results in them not doing either function that great.
I’m not saying you can’t design a great responsive website that serves desktop clients and mobile clients wonderfully and makes their eyes light up with joy every time they see your beautiful site. I’m just saying you won’t.
I’d also rather not be handcuffed to my original design because changing anything will incur the cost of making changes to the reactive layout as well, that scales down to mobile.
The reuse fallacy
What are you really trying to do by creating a reactive design, instead of just creating a desktop version and mobile version of the site? Reuse some HTML and CSS?
When you think about it, it doesn’t make much sense. I’m all for code reuse, but responsive design is like putting ifdefs all over your code base. Are you really saving much time and effort by reusing your front end code for both platforms?
It seems to me, that if you have to have your site display differently on a mobile device you are better off just forgetting about trying to reuse the HTML markup and CSS, and instead focus on reusing the backend code for both the mobile and desktop versions of your site; that is where you’ll actually get the biggest bang for your buck.
Again, I don’t know about you, but I’d much rather maintain two front end codebases that are simple than one monstrous complicated front end codebase.
It is good enough already?
Most desktop websites actually look fine on a mobile device without any reactive design. To me it makes much more sense, in most cases, to focus on just creating a desktop design that looks good on mobile or even a mobile design the looks good on the desktop as well.
Sure, responsive design is pretty cool, but do you really need it?
It is the browser’s responsibility anyway
Aside from the practical reasons I’ve talked about so far, there is another major reason why responsive design might just be a waste of time anyway: this should all be the browser’s responsibility, not the web developer’s.
This is even already starting to take place. Consider the special input types in HTML5, like the number input type. On a mobile device it brings up the numerical keyboard in mobile browsers.
I predict as more and more websites are viewed from mobile devices, the types of things that web designers are doing to make desktop sites responsive right now will be incorporated directly into the HTML markup and the browser itself. So, creating a responsive design manually might end up being a big waste of time.
I’ll leave you with one final point, then I’ll get off my responsive design soapbox.
We are in a time of constant flux right now
Things are changing rapidly. Mobile devices are getting bigger screens and higher resolutions and becoming much more powerful. While two years ago it was a pain to visit a desktop site from a mobile browser, it is much less painful now. With my new Galaxy S4, I hardly feel the difference at all and I even find myself specifically requesting the desktop version of a mobile site from time to time.
The trend says that mobile browsing will eventually take over desktop browsing as the main source of visitors to websites. If this becomes reality—which I see no reason to doubt—responsive design won’t make much sense at all. In that case, it will make much more sense to build websites optimized for mobile and not really worry so much about desktop.
If you are going to do responsive design, at least get a good book on the subject. There are many subpar books floating around, because responsive design is so hot right now.
What do you think? Am I off my rocker? If you have a convincing argument as to why responsive design is worth the effort or why it isn’t as much extra effort as I have painted it to be, I’d love to hear it. Let me know in the comments below.
The goal of software development is to solve problems.
At its heart, software development is really about solving problems through automation.
Many times we have the tendency to make software development about creating solutions. It may seem that these are the same thing, but there is a subtle difference.
The difference is the focus
When we are trying to solve problems, we are obsessed with the question of why. It is only by understanding why that we can know what to build.
When we are trying to build a solution, we are obsessed with the question of what. We want to know what to build so that we can build it.
This is fairly natural for software developers since the what is something we can control. Any fairly skilled software developer can build any what you can describe to them. Just like any skilled carpenter can build any type of wooden furniture you desire.
The difference is that software development is about more than just building things. A carpenter doesn’t have to focus so much on the why, to build you a piece of furniture. But a truly skilled carpenter will ask you why. A skilled carpenter might make a house call to the project to custom build an entertainment center suited to your needs.
A truly skilled craftsman of any craft, needs to know why.
It is odd that we constantly seem to neglect the why when building software (at least I do), primarily because we think we don’t have time for the why, when in the end solving the why is the only thing that really matters.
Do you really want a carpenter to build you a perfectly crafted entertainment center with plenty of custom shelves for all your music CDs when you don’t own any music CDs?
Why focusing on what doesn’t work
Consider for a moment what would happen if your GPS system stopped showing your route and the directions you were going to take ahead of time, but instead abruptly told you to turn right when you were supposed to turn.
One of the early GPS systems I used for navigation did exactly this. It was very frustrating! I would constantly shout at it that telling me what to do exactly when I am supposed to do it wasn’t any help. I needed some forewarning so I could switch lanes and prepare to turn.
Also, have you ever asked your GPS the question “why are you taking me this way?”
Focusing only on the what results in split-second decisions and avoidable mistakes. When you are focusing on the what you are not thinking, just doing.
Contrast this with a good GPS navigation system.
What makes a good navigation system good?
I’ve found that good systems will alert me far in advance to what my next move is. This gives me time to switch lanes or to have a better understanding of the bigger picture of the trip.
Now this allegory won’t carry us very far in the software development world. You don’t really need to know why your GPS system is taking you a particular route in order to get there, but it does demonstrate how focusing only on the immediate what can lead you astray.
Perhaps a more direct analogy related to software development is outsourcing.
If you’ve ever worked on a software development project that has had a portion of its work outsourced, you may have felt the pain of what happens when oftentimes perfectly competent programmers focus completely on the what and might not even have the slightest clue about the why.
I’m not trying to knock outsourcing, and I’m not even specifically talking about outsourcing to different countries. (The same problems exist in outsourcing whatever the conditions are.)
Oftentimes outsourced projects are treated like a set of blueprints that need to be built. The poor developers working on the outsourced project tend to get thrown under the bus when they build something based off just the what and can’t anticipate the why.
Why focusing on why is better
Focusing on the why is focusing on providing holistic cures to software development problems rather than treating each symptom individually.
Just like you’d like to have a doctor set a broken leg and put it in a cast so that it can be wholly cured, rather than give you some pain medicine to manage the pain, give you crutches to help you walk, and send you to therapy where you can learn to live without the use of your leg, your customers would probably rather you built something that actually is focused on solving their problem, not something that makes their symptoms easier to live with.
If we start building software from the what that is given to us, versus the why, we are at a distinct disadvantage because we only have the ability to treat the symptoms of a problem that we don’t even understand.
Focusing on the why is vitally important because it helps us to better think about and design the what.
Reuse is also much more likely to be present on why focused solutions than what focused ones.
Which software component is more likely to be adopted for reuse: a component that addresses a specific set of account balancing steps or a component that addresses the general problem your customer has of doing accounting?
Why focused solutions are much more likely to be shared across many customers, while what focused solutions are often very specific to a single customer.
Let’s not forget one of the most important reasons why it is important to focus on the why.
Missing the why is costly!
You can build the what someone is asking for, and you can do it perfectly, but at the end of the day if what you built doesn’t solve the problem (the why,) it’s going to have to be redone or thrown out completely.
You may think you are saving time by starting with the what, and you may actually build your solution faster by not taking time for everyone on the project to understand the why, but chances are you’ll build the wrong thing, and when you do, you’ll lose any time benefit you may have accrued.
It is very hard for a team to focus on the what. Focusing on the what tends towards segregating the responsibility of the team. The team members end up only having ownership for their own parts of the solution, rather than solving the problem at whole. So, when a team that focuses on the what ends up with a problem, finger pointing a shirking of responsibility inevitably ensue.
By instead focusing the team on the why, every member of that team becomes responsible for solving the problem rather than solving their part of the problem.
The most compelling reason to focus on the why?
For many problems, just having a thorough understanding of the problem takes you 90% of the way to the answer. I have spent countless hours trying to design and architect a clever solution to a problem without having a really good grasp of the problem that I’m trying to solve, only to find that 20 minutes spent actually fully understanding the why of the problem resulted in the answer becoming completely apparent.
How to know if your focusing on what
I’ve got a pretty good idea of how to know when I am focusing on what instead of why. Not because of any special wisdom on my part. No, it is because I fall down in this area quite a bit myself.
I’ve learned the hard way, and I am still learning how to identify when my focus needs to shift from what to why.
Here are some simple questions that you may find helpful to evaluate your own situation. I’d be glad to hear any others that you can can think of or use routinely yourself.
- Do you’re backlogs, stories or general work items state a solution instead of a problem?
- Do you know how to actually use the thing you are building? (Whoops, I am so guilty of this one so many times.)
- Can you define in simple terms the problem you are trying to solve? (Einstein said “If you can’t explain it simply, you don’t understand it well enough.”)
- Can you clearly define why the what your are building is needed and what purpose it will solve?
- Can you walk through the manual steps of the process you are automating, understanding each step and why it is necessary?
Taking the time to focus on the why instead of jumping into the what can be difficult to get accustomed to, but it is worth the effort. You’ll find much more satisfaction in your work when you understand the purpose it is going to serve, the true problem you have solved. In addition your customers will thank you!
I worked on an interesting problem this week that might have looked like I was running around in circles if you just looked at my SVN commits.
The problem, and the eventual solution, reminded me of an important part of software development—of building anything really.
Sometimes you must tear it down!
No really, sometimes you build a structure only to tear it down the very next day.
It’s not a mistake. It is intentional and productive and if you are not doing it, you very well might be making a real mistake.
That is highly illogical
Imagine for a moment that you are tasked with the job of repairing the outside walls of a 2 story building.
There are of course many ways you could go about doing something like this.
Use a ladder and just reach the part of the wall the ladder allows you to. Then move that ladder, repeating the process as needed to complete the repair to the entire wall.
Try to lower yourself down from different windows to reach as much of the wall as possible.
Tear down the entire building and rebuild the building and walls.
I am sure there are plenty of other methods besides what I listed here.
Yet, a very simple approach would be to build a scaffolding.
A scaffolding is basically a temporary construction used just to help repair or initially build a building which is built for the very purpose of eventually being torn down.
Software is different, we don’t contend with physics!
You are absolutely right!
We contend with a much more powerful force…
Conceptually anything you can create in software could be created without any kind of software scaffolding. Unfortunately though, the complexities of the logic of a system and our abilities as humans to only contain so much of it in our brains impose a very real limitation on our ability to even see what the final structure of a metaphysical thing like software should be.
So what am I saying here then?
I’m just saying that it sometimes helps to remember that you can temporarily change some code or design in a way that you know will not be permanent to get you to a place in the codebase where your head is above the clouds and you can look down and see the problem a little better.
Just like there are physical ways to repair a wall on a 2 story building that don’t involve wasting any materials by building something that will be torn down, there are ways to do build software without ever building scaffoldings, but in either case it is not the most efficient use of time or effort.
Don’t be afraid to take a blind hop of faith
Source control is awesome!
Source control lets us make changes to a code base, track those changes and revert them if needed.
Working on a code base without source control is like crawling into a small crevice in an underground cave that has just enough room to fit your shoulders—you are pretty sure you can go forward, but you don’t know if you can crawl back out.
But, with source control, it is like walking around a wide open cave charting your trail on a map as you go. You can get back to where you want to any time.
So as long as you have source control on your side, and especially if you are using a distributed source control where you can make local commits all day long, you don’t have to be afraid to step out on a software ledge and see where things go.
Oftentimes I will encounter some problem in code that I know needs to be fixed and I know what is wrong with it, but I just don’t know how to fix it.
When I encounter a problem like this, I will often have an idea of at least one step I could take that should take me in the direction I believe the code needs to go.
A real example
To give you a real example, I was working recently on some code that involved creating a lot for a product. (Think about the lot number you might see on a box of Aspirin that identifies what batch of ingredients it came from and what machine produced it when.)
Up to the point in which I had been working with my teammate on refactoring this code, there had only been only one way to produce the lots.
We were adding some code that would add an additional way to create the lots and the labels for those lots. We also knew that there would be more additional ways in the future that would need to be added.
Well, we knew we wanted to have a generic way of specifying how lots should be created and labeled, but we didn’t know what the code that would do that would look like.
We could have rewritten the entire lot handling code and made it generic, but it was quite complex code and that would be equivalent to tearing down a building to fix a wall.
It was apparent there were some parts of the existing code that were specific to the way that the current lots were being produced, so we knew those parts of the code had to be changed.
So what did we do?
We started with what we knew needed to be changed and what we thought would move us in the direction we wanted to go, and we built some structures to allow us to refactor those parts of the code, knowing that we would probably end up deleting those structures.
The scaffolds that we created allowed us to have a midway point in the long journey across the Pacific ocean of complexity in our refactor trip.
The point here is that we had to take a bit of hop blindly in a direction we thought things needed to go and part of that hop involved creating some scaffolding type structures to get that code to a place where it still worked and we could examine it again for the next refinement.
The final refinements ended up deleting those scaffolds and replacing them with a more elegant solution, but it is doubtful we would have been able to see the path to the elegant solution without building them in the first place.
Show me the code!?
You may wonder why I am talking about code in such an abstract way instead of just showing you a nice little “scaffold pattern” or a real code example.
I’m not going to show the code, because it isn’t relevant to my point and it is so situational that it would detract from what I am trying to say here.
The point is not what our problem or solution was, but how we got there.
There isn’t a “scaffolding” pattern that you can just apply to your code, rather it is a tool that you can use and shouldn’t be afraid to use in order to move your code forward to a better design. (To its happy place.)
Are you really sure you want to create the cancel button for your application?
You know, I might click it.
Not only might I click it, I might click it at the most inopportune time.
I might click it right in the middle of that large file that you are copying, right after you spun up that 2nd thread.
Cancel is a commitment
The next time you consider creating a cancel button, I suggest you think of it as a commitment.
In my world the cancel button has two promises.
- Stop what is currently happening in a non-destructive way.
- Stop RIGHT the F NOW!
I’ve been encountering a good deal of cancel button which don’t obey the basic laws of cancelling that any user would expect.
I have actually been randomly clicking “cancel” whenever I see it, much to my coworker’s dismay.
I started doing this, because I wanted to see how widespread the cancel cancer is.
And it is pretty widespread. A majority of cancel buttons I have been testing neither stop right away or prevent destruction.
I found instead that clicking the “cancel” button in most programs is sure to hang that program for an extended period of time, ultimately causing you to kill the process, and it tends to leave processes half done without rolling them back.
Clearing things up
Let me be a bit clear here. I am not talking about cancel buttons you see in an “Ok / Cancel” dialog. Most of the time those cancel buttons actually work, because they are really operating as “back” buttons, they aren’t actually cancelling a process that is happening live.
I am talking mainly about cancel buttons that cancel an active ongoing activity. For example, cancel buttons in an installer or during an SVN update.
We could call these kinds of cancel buttons “asynchronous cancel buttons.”
But, I need to provide a way for the user to cancel
Good, but don’t lie about it.
There are certain things that just can’t be cancelled.
When I get on a plane, I can cancel my trip when I am sitting there waiting for the door to close. I can even cancel my trip while the plane is taxing to the runway, if I yell “I have been RAPED by a BOMB that is on FIRE!”
But, I can’t cancel my trip, once the plane has lifted off the ground. If I try to cancel it then… well, bad things would happen. Very bad things.
So how come when I am installing your software, or your software is updating its database, I have this shiny little cancel button I can click at any time during that process?
Surely I cannot cancel just any time!
Surely there are parts of the process that cancelling would be fatal or it is too late to rollback.
My point is, if the user truly can’t cancel, don’t present a button that says they can. More specifically, if you can’t obey the laws of cancel 1 and 2 from above, don’t even show a button. Just say “sorry, you can’t cancel this process at this time.”
I don’t even need to know why I can’t cancel. I mean, it will make me feel better if you tell me that the Unicorn Glitter Engine is in a critical state and any disruptions could end life as we know it, but I’ll settle for you just greying out that cancel button or not displaying it at all.
Putting back on the developer hat
I’m guilty of it myself. I know I have created cancel buttons in the past that have caused pain and anguish.
But what can we do about it as developers?
First off, we should be thinking carefully about breaking a long running process into steps. At each step of the way we should consider if it is conceivable to cancel that step without destroying data and hanging the application.
In any long running process, we should be able to identify certain parts which are cancellable and those which do not make sense to cancel.
It is your job as the developer to ensure that if you decide to allow for cancelling that the cancel undoes the existing process and work immediately.
I cannot stress this enough!
This is the behavior that most users expect and the very meaning of the word cancel.
To do this might take extra work. You might have to think a bit more about the threading situation of your application. You might have to think about rollback situations. But, if you don’t do it, your cancel button will become just like the boy who cried wolf and no one will believe them.
And if you’re not willing to go through this effort, at the very least, be kind enough to your users to just remove the cancel button, because you can bet I’ll be clicking it!
I’ve previously talked about why I think Scrum will eventually die and I am still pretty much convinced of that point. Scrum has become something you sell through training and consulting. If you make your living off of doing this, sorry, but you may be part of the problem.
What this post is really about though is the problem of good architecture when implementing Scrum. In my experience, it is very difficult to create or maintain a good architecture and do Scrum. There is one very simple reason for this: mobs don’t build good architectures.
Let me give you an example that helps to illustrate my point. Let us take a second to think about real physical engineering and architecture. Let us say we are going to put together a team to design and build a custom home.
So we get together a plumber, an electrician, a couple of framers and an architect. Now, let’s have them start building the house. What do you think the architecture of the building will be like? What if the plumber and electrician know a good amount about architecture because they studied it in high school? They outvote the actual architect. In general the team is going to benefit from the real architect’s experience and guidance, but when he understands a critical component which the other team members do not see, he is going to be overridden and that will spell trouble down the line.
Now, obviously this parallel does not completely apply. I am just trying to take one aspect of it for the point of this illustration: you don’t want a group of people, as intelligent as they are, to make a decision which could be better left in the hands of an expert.
At this point you might be thinking “what an arrogant jerk!” You think a so called “software architect” knows so much better than the average developer? No, that is not exactly the point. The point is that there is a difference in level of experience and ability in software people, roles and labels aside, and when you use a democracy of team based decision-making methods, you get an average of the skill level and experience of the whole team as a result. It is a mouthful, but read that over a few times until you get my point. I think it is pretty hard to argue against, but let me give one more illustration.
Let us say now that you are going into a hospital to get heart surgery done. Now, this kind of procedure is not a one man operation. You would typically have a surgeon, an anesthesiologist, several nurses, and other doctors involved. But let’s say for this instance that we let this surgical team operate like a Scrum team. Instead of the surgeon or chief medical officer ultimately calling the shots, the team will make a decision as a whole. Would you be ok with that? The nurse has the same vote as the surgeon? Two nurses can override the surgeon’s decision? I think I would be a little bit alarmed, especially if I sat in on their design session.
I’m not trying to pick on anyone here or devalue anyone. I am also not trying to destroy the concept of team. Teams and teamwork are very important in the development of software. But I hope you can see the point that Scrum can tend to lean towards a mob built architecture for a system, and that architecture is only as good as the average of the abilities of the team members. Although more often than not it’s really just as good as the most vocal and assertive member(s) of the team.
Where Scrum and Scrum-like processes fail
I don’t see how a resolution to this problem fits inside of the Scrum framework, and that is a problem. The idea of a completely self-managing team is ok for making construction type decisions about building the software, but it has no solution for the overall architecture and general best practices for the development of the application. As much as we can despise hierarchy, it really has a value that is completely missed by Scrum. You really want to have the more senior highly skilled developers technical people with more power over decisions and direction than your less skilled. This isn’t mean, it isn’t spiteful or power-mongering, it is common sense. The problem with the self-managing-everyone-is-equal team is that it levels the field.
So what is the solution?
Would I offer up a problem without offering up a solution? There are several ways of dealing with this problem. It depends on how far you are willing to step outside of Scrum.
Solution 1: Scrumminess Factor: 9
Appoint a small team of technical and business architects that have the responsibility of:
- Overseeing the general architecture of the system
- Creating development best practices and guidelines
- Attending design sessions for other teams
- Stepping in when needed to steer a team back on the right course
This solution works only if you have several Scrum teams on the project, where it would make sense to have a team dedicated to architecture. This team is also a good one to be creating developer tools. I have actually been part of a team doing this kind of role, and I think it worked out pretty well. It doesn’t really violate Scrum because that team is a separate Scrum team with a different kind of backlog.
Solution 2: Scrumminess Factor: 6
Appoint a technical architect to the project. This person is in charge of the technical people on all of the teams for technical direction, but not HR duties. This role would have the ultimate authority on any kind of development and architecture decisions for the project. They would be a floating resource that could help teams at times where needed. This person would be thinking about the bigger architecture picture that is being created by each of the teams.
Solution 3: Scrumminess Factor: 3
Appoint technical leads on the teams which are responsible for the architecture and ultimate technical direction of the team they are on. If you have multiple teams the technical leads should have a technical lead for the technical leads. This allows for a unified vision when there is dissent among the technical team leads. It has a low Scrum factor because it puts a direct leadership role on the Scrum team, but it allows for the solution to the mob architecture problem, while still keeping the architecture within the team.
One final word here. If you are still thinking that a central authority is not important to a business, consider this: every company I know of has either a CEO or a president. I have never seen a company with a Chief Executive Committee. Sure, there is a board of directors, whom the CEO ultimately is accountable to, but you have one person setting the vision and business direction of the company.