Category Archives: Process

How People Defeated the Open Web

The Internet began, first and foremost, as a collaboration tool. ARPAnet was designed for scientists to be able to connect with each other via asynchronous text message (aka e-mail) and change the world with discoveries.

Then, as networks of networks began cropping up and coming together, the promise got even broader. By the 1980s and early 1990s, you could e-mail someone (or many someones) all over the world even if you weren’t a scientist — even if you were a home hobbyist with a slow modem dialing up into the night.

The promise was great — the Internet was a communication tool that could Democratize, that could bring populations and communities together. When the web came along, it wasn’t very long until the technology was adapted for bulletin boards (web-based BBSes, essentially) and threaded discussion systems.

It seemed as though the promise was becoming real — anybody with a computer could participate in open discussions about a variety of topics, learning and sharing knowledge along the way.

Today, though, where are we? There are some pockets of such discussion around. But the far more common trend is the other direction. As an example, yesterday, Popular Science announced they were shutting off comments altogether on their site.

Their logic? Comments were bad for science. Why? Because anybody with a computer could participate in open discussions about a variety of topics, not learning but sharing opinion along the way.

Almost the same as the promise, but not exactly. And herein lies the conundrum: Everybody is entitled to their opinion, and in our country at least, they’re entitled to speak it. But there is no entitlement to a forum, and no entitlement to having other people listen. When we are increasingly self-selecting our information sources to conform to our own worldview, we have less and less patience for viewpoints diametrically opposed to our own.

So what does this have to do with technology? Part of it is unintended consequences — building a system that allows for basically unfettered communication in order to break down barriers for learning also breaks down barriers for opinion.

But another part is a reminder about technology’s limits. Few would argue (certainly not me) that the fault here is the technology, or that widespread networked computing is a bad thing. Rather, there’s something more societal that gives us values that permit (if not encourage) anonymous sniping and/or closed-minded trolling.

And there’s not much that technology can do about that.

What Do You Do?

From time to time, we’re all asked that standard question: “What do you do?” And as I start to explain what Square Lines does, it often gets summarized thusly – “Oh, you do tech design and development and stuff.”

Well, yes and no.

Yes, we do those things. In fact, we bill ourselves as “Design & Development,” specifically so that people get a quick sense about what part of the world we occupy. But that’s not really the best description of the scope of what we do.

We are, in the truest sense, solution providers. Over the last decade or two, that phrase has become so pervasive as to be meaningless in the tech world (which is why we don’t really plaster it all over our website). But for us, it really is the case.

So what’s the difference? Well, if all you want is a quickie web design, you can get that for free. Just find one of the tons of templates out there and call it good. Of course, your site will be from a cookie cutter, may not work the way you want, and certainly won’t represent your brand as well as it should, but hey — it’s free. You get what you pay for.

What we do starts with listening and thinking – two skills that the cookie-cutter chop shops don’t have. What is the problem that you’re trying to solve? Who are the audiences? What do you want them to do and to feel? How will this work be changing over time?

By getting a sense of the big picture, we can look at a whole array of options — some might even call them solutions! — whether it’s web design, app building, or something entirely different. The goal is to meet the client’s needs and solve the problem, not just to churn out another bland product that looks and works vaguely like everything else out there.

So what do we do? Design and development, yes. But really? We provide solutions.

Scope: It’s Not Just a Mouthwash

A decade or two ago, I worked on a project team to lead the development and implementation of a statewide data and reporting system. It was very visible and high-stakes, and we had the luxury of creating from scratch. It was the best kind of situation: we had a big, hairy problem to solve, but the way we solved it was up to us to decide.

One of the members of our team, Bill, a database guru who also could be a bit irascible at times, would get agitated every time some new idea or feature was brought up. “Scope! Scope!,” he would cry. After several times of this, we began to take with a grain of salt and some friendly chuckles, but his fundamental point was a sound one.

Scope creep is one of the biggest dangers in our work. We’re building a web application that does x and y. Why not just spend a little more time and do z as well? It’s all related, and it’s not that big a leap. It won’t even take too much extra time. What’s the harm?

Well, to channel Bill for a moment, there are several harms. First, planning to accommodate that extra feature wasn’t done from the beginning, so it’s unclear how many other parts of the system it touches, and what other adjustments need to be made. Also, how does it affect the testing and release processes? And what sort of additional back-and-forth conversations will there be with the clients about it all?

Having allowed the scope to creep on projects large and small, I can tell you that those extra bits of functionality or work are often the ones that end up being a time vortex – not because of implementation, but because of the client discussions and fixes. Because they weren’t covered in the initial planning, all of those upfront conversations have to happen at the end, where they are longer and more costly to make work (and when everybody is, frankly, ready for the project to be done).

Bill was pretty good about helping us stay close to our outlined scope. And when the multi-year project was done and we were disbanding and exchanging end-of-project gifts, what did Bill receive? A giant bottle of — what else? — Scope.

Getting Better (Or: We Used To Be Worse)

I’m a bit of a pack rat. Somewhere, I have encomia that goes back decades. And in the digital world, this is true as well.

So when I got a new computing device recently and needed to migrate a bunch of data, I had an opportunity to look back at projects we’ve done over the years, and that I had done for at least a decade before. What I found wasn’t all that surprising, but it was instructive.

Starting with my early work, it was, well, fair. I mean, it worked and all (in fact, one web application I wrote a decade ago is still in production use on a public website – think about how much on the web has changed in that time!). But it wasn’t coded all that well, and the emphasis was on getting it done quickly and briefly. (In other words, the code was hard to read and not well documented.)

Then I look at a project from five years later, and it’s all different: sure, sure, it works – that much is the same. But under the hood, the code isn’t just quick, it’s efficient. And there are actual comments throughout. The front-end design and the ‘look’ of the work is leagues better (by that time, I didn’t do it myself, and we had a team with expertise in that area). It’s a professional product.

Then I turn to a project we finished last year, and it’s more advanced yet. The amount of growth isn’t as dramatic, but it’s still there. Development patterns are being used effectively and both programmatic and business logic is easily intuited from the code (and its documentation), and the separation of functions allows for easy manipulation of pieces and parts. It’s a great result.

This progression is hardly unique, I think – every person and every firm, if they’re stretching themselves and striving for self-improvement, has something similar. But we don’t talk about it much, because we worry that clients (or, more specifically, prospective clients) think “we get better all the time” means the same as “we aren’t really ready for prime time yet.”

But that’s pretty shortsighted thinking. Even the best sports pros are always working on their game. We can always improve – after all, that’s the whole point of professional development, right?

It was heartening to see that transformation over the last couple of decades. Who knows what the next project will bring?