Agile

Driving Development Without A Governor

In agile development, you hear a lot words like “lean”, “velocity”,” extreme”, and well… “agile”. They evoke an image of speed – nimble and fast, like a cat. With agile we’re supposed to be moving quickly and responding to change easily. These are both good things for sure, but is there such a thing as moving too quickly?

Speed limiters in automobiles are termed governors. One use of the governor is to limit the rotational speed of the engine to protect the engine from damage due to excessive speed. So is there such a thing in Agile development? Do we need such a thing? Agile development’s major benefit is to get continuous feedback from your customers as you build. You are continuously planning, testing, integrating, and refining as the requirements change and grow. The faster you build and deploy, the sooner you’ll get new feedback, but the rush to completion can cause its own problems.

The same way that the governor in a car prevents you from wrecking your engine, and limits how fast you could recklessly drive, an agile governor should help prevent making major errors in your code and accruing technical debt.

Technical debt can occur in several forms: pieces that were meant to be refactored never are, not enough brain cycles are put into the initial design, code gets copied and pasted more than it should. Then, when the customer gives you an approval of a feature, there is always the temptation to close the feature and move on to the next without having one last look to fix things you promised yourself you would at the end. You may end up with a feature that on the surface appears to work, but internally is hard to test, hard to read, inefficient and impossible to enhance without the fear of introducing bugs.

So we still want to deploy features fast to get feedback, but without hurting the integrity of the feature. What is the governor in agile development?

As you develop you should be writing unit tests. (You are writing unit tests, right?) This is one kind of governor.  The benefits of unit tests are well known, but it’s more than  testing correctness and finding regressions. It’s when you stop and think about the use cases and how they will be handled. In essence, it forces you to think through the problems you will encounter and design solutions to those problems. It forces you to slow down and think a little instead of just head-down code.

speed-limit

For a long time, we thought unit testing was enough. In the past 10 years, testing has really become mainstream, so it should be assumed at this point, right? But is there more?

We’re a small team, with a lot to do. Revolutionizing lending takes a lot of work. This isn’t a project management tool or the next wannabe social network. We can be as agile as possible, but our minimum viable product is still not very minimal. We feel the constant pressure to get the next feature checked off before we can hit our 1.0.

We have really good quality code and we were testing, but a few months ago, we put our need for speed aside, and wanted to make sure our quality was even better. We devoted even more time to our deployment process and quality assurance.   What we found is that we could improve even more. The unit tests and  testing were not enough.  A more robust quality assurance process was a speed limiter for us, but again, that might just be a good thing.

With the increased QA, we found that it would probably be worthwhile to do more code reviews. Not just sometimes. Not just when someone asks. Always. We held off on this one longest, worried about the cost in terms of productivity. What we found is that code reviews are just as important as unit testing and even more important in many respects.  Code reviews create accountability for the feature. There is something about knowing someone else will be looking at your code that encourages you to design and implement a feature well. This is the time where someone with prejudice attempts to find all flaws in the design or implementation. So it behooves the requester to look at things one more time before the code reviewer starts. It is not meant to embarrass, but an opportunity to catch issues upfront, exchange ideas, and learn the feature. It also gives the developer and reviewer an opportunity to learn from each others strengths and weaknesses. The code reviewers must not rush and just skim the code, as this bypasses all the benefits of the code review.

It is tempting to develop without tests, code review, and thorough QA, the same way some gear heads love to get rid of their speed limiters to see if they can make a car go faster than it was ever meant to. What we found, though, is that its better to get there in one piece. We can continue writing code in a fast pace but as long as we don’t rush unit testing, code reviews, and quality assurance, we’ve created an agile development environment that limits how much we can rush, which keeps us at a safe speed.

What about you? Do you drive development without a governor?

Web Platform

Bootstrapped up with nowhere to go

or: How I Learned to Stop Using Twitter Bootstrap and Love LESS

Octane (our product) has been around for a while – we’ve watched the trends in UI design, frameworks, and developer mindshare changing along the way. We’ve been from jQuery to YUI back to jQuery, with a brief consideration of Dojo along the way. At this point our codebase is mostly custom css and mostly custom javascript widgets, with some great third party libraries where they  met our standards and fit our needs exactly. I remember when Bootstrap first came out – it was fresh, and had a lot of good ideas. We were doing some new development work at the time in a separate part of the app – something which would be more public facing and could use a bit of a fresh start with new choices. We took a leap of faith on Bootstrap and followed it through 2.0, investing in LESS and integrating it into our build.

Recently, we’ve started a pretty large UI overhaul, with fresh design work, heading in a slightly new direction, we were going to try to build something more cohesive across our projects. It was a flat design, going along with the trends, and we found the Flat UI theme built on bootstrap which matched a lot of our design. It seemed like a clear win.

When work began, I devoted some time to getting up to speed on what the current best practices were in the CSS world. I knew we had built up some cruft, and I wanted to clean it up along the way. I found OOCSS and SMACSS and decided to give it a deeper look. I watched some presentations and read the SMACSS book, and it all clicked pretty well. Many of the ideas I was familiar with, such as the technique of using multiple classes to refine styles, but I hadn’t really gone through the level of structural rigor that OOCSS and SMACSS prescribe. It made sense to me, though, so I wanted to use it during our overhaul in conjunction with Bootstrap, which didn’t seem to conflict too much…

Well, long story short, after really digging in and trying to make it all work – to make the app work the way I needed it to, and look the way I needed it to – I found that the number of overrides I was making became much more than the value proposition of Bootstrap to begin with. Combined with the Flat UI theme, I was writing overrides of overrides. I had two sets of variables and mixins, plus my own. I was dropping entire chunks of functionality like grids and forms because they were doing more harm than good. In the end, I ultimately used some code from Bootstrap and the Flat UI theme, but I condensed it all without overrides, and really just used it as a scaffolding for the final design.

So what’s the conclusion here? Should people avoid Bootstrap? Would I do it over again differently? This is my final takeaway:

  • I’m glad Bootstrap got me into using LESS (judiciously).
  • Bootstrap helped me figure out a good way of organizing my LESS files.
  • Bootstrap has some good ideas about breaking down some of the fundamental components of a page and figuring out what those pieces are. What the vocabulary is. A lot of that I kept even if the css, classnames, and even html changed.
  • I’m a snob and I think the dropdown and tooltip widgets (the only two I even tried using) are kind of crap. They work fine in prototyping, but have fundamental flaws.
  • Bootstrap makes tradeoffs to have nicer looking html. We take a different approach to get nice view code, and don’t need to make those tradeoffs.
  • Finally, I realize that not all apps or websites are like Octane. Other people may have no time or talent for design or implementation of custom CSS, in which case, Bootstrap is a pretty good foundation. It also works pretty well for just prototyping or scaffolding.

Before I made the final decision to remove our dependency on Bootstrap, I looked around to see what others were saying. There’s a lot of praise for Bootstrap out there. Given that my ideals had shifted to OOCSS/SMACSS, I was curious about that intersection. I got my answer here. To pull some choice quotes:

“Yeah, my initial impression has been that design is too tightly coupled to structure. You can’t easily reskin w out ripping out or overwriting their styles.”

That was from Nicole Sullivan, creator of OOCSS and well respected authority of good CSS.

“I’ve used it for 3 projects now. At first I loved it, but now I think that I live only a few aspects of it – the mixins, icons and buttons.

It is an amazing project, but I actually prefer the lightness of the OOCSS framework.

While you can customize things in bootstrap, you ant take it too far before things start to break.

In the end, what it’s taught me about LESS is what I appreciate the most. I’m building a LOOCSS project :-p”

That was from another person in the thread, and it really echoed my own experience.

I’ve got more thoughts and experiences on OOCSS and SMACSS, and where we’re going with it, but I’ll just leave that for another post.