A dialog of thoughts and ideas about software, usability, and products, with random science and wacky ideas thrown in for good measure.

On March 15, 2010, Alan Skorkin wrote an interesting article, "The Difference Between A Developer, A Programmer And A Computer Scientist." While there are overlaps in our opinions, there are some shades of difference that I wanted to address in a post of my own.

Here's my take on the difference between a Computer Scientist, a Software Engineer, and a Programmer.

Computer Scientist
I'm with Alan on this one: a true computer scientist (as opposed to so many developers who have computer science degrees) is interested in the nature and theory of computation, the development of new languages and new ways to process information. People who are working hard to improve search engines, vision systems, and artificial intelligence techniques are likely a mix of computer scientists and programmers, or computer scientists and software engineers - particularly when such solutions are expected to work in real-world applications, like photo applications with facial recognition algorithms.

Software Engineer
A software engineer, also known as a developer, is an expert in developing, refactoring, debugging, and building applications. Software engineers need to have people-facing skills, so they can communicate effectively with managers, customers, and team members. They use software engineering tools, like Mercurial and Jira. They may share their knowledge with other developers, whether at lunch, on StackOverflow, or on their corporate wiki. They need to be concerned with the usability and utility of their product (whether the product is a UI, an API, or something else). A Software Architect is an advanced Software Engineer who can envision a complete system, and anticipate the pitfalls that may be encountered in its development. Some Software Engineers may become Project Managers.

I'd argue that there's a difference between an application (e.g., a full-blown product) and a program (e.g., a standalone piece of code). A programmer writes programs - perhaps quite amazing programs that do some remarkable things - but does not have the breadth or opportunity to develop a product. Programmers can learn how to program from a book in 21 days; advanced programmers can create awesome programs by combining their insights and imagination with their knowledge of programming. A programmer may be able to integrate existing software components together to solve a problem and produce an amalgam that works, despite some roughness around the edges, without a requiring a deep understanding of the components.

These are the connotations that I've become familiar with over the course of my career. I freely admit that the actual terms could differ based on one's locality, experience, or other factors.

Makers and Solvers
I also believe there are other dimensions to consider. For example, some people enjoy software because they're Makers - they like to build new things, explore new ideas, create something that the world has never seen. Others enjoy software because they're Solvers - they view a problem as a puzzle, they want to fix it, they want to know why something doesn't work and they want to make it work. These are two types of passions that I can think of; perhaps some other people enjoy software because of the money, but I think most of them left the industry after the dot-com bust.

When a software development team builds an application, the graphical user interface (GUI) is an important part of that application. Hopefully, the software design team has conducted extensive assessments with users to understand how users conceptualize, understand, and use the application. Unfortunately, it seems many applications (and websites, but that's a different matter) suffer from a severe lack of usability analysis or insight.

Regardless of whether a GUI is designed well or poorly, there may be situations in which the GUI does not support the workflow or needs of a specific group of users. For example, a team could develop a word processor, but people in a particular user community may have very specific needs that are not supported by the original application; or, the functionality they require may be built into the application, but based on their workflow, it's too tedious for them to use.

What does not exist today is software applications that can allow their user interfaces to be modified by end-users. Preferably, end-users who can perform usability assessments within their own community.

For example, perhaps I need the ability, in my word processor, to quickly and easily:
  • Paste in some text
  • Automatically convert that text to sentence-case (suppose, for example, it had been all upper-case)
  • Bold-face some keywords in that text
  • Pull out the keywords into a separate clipboard or document that I can copy from
All of these steps are possible in modern word processing applications, but they can't be rolled up into a single toolbar button. Some applications do let you customize toolbar buttons, and assign tasks to those buttons, but that capability provides no means of customizing parameters (for example, "select the first word from the pasted text, and search the document for that word").

I'm not sure if there's a compelling need for a capability like this, but isn't it an interesting idea? What if an application could be developed from the perspective of its capabilities, and anyone could develop a GUI for that application? To use a website analogy, it would be as if the design of the application were done in CSS, and the underlying functionality of the application were expressed in DIV's.

And, to take the idea further, what if there were an easy-to-use, end-user-focused "CSS Designer" for re-designing an application - for recombining the functional building blocks into new UI components that can be tailored to specific end-user communities?

Think, "Microsoft Word for Bioinformatics," or, "NASA WorldWind for Petroleum Geologists," or, "Adobe Photoshop for Rich Client Developers."

(And, to take this even further, a new market of application designers would emerge. These consultants would charge for their services to tailor applications to specific user communities.)

Remember 2006? That was a fun year. The airlines introduced discount carriers, like Song and TED (the airline, not the conference) and JetBlue, that had TVs in every seat (on Song, you could even play trivia with other passengers) and awesome snacks - I'm so thankful that JetBlue is still around. Also in 2006, SecondLife came to life. Virtual reality seemed a bit closer to reality. Companies like Adidas and Toyota, universities like Ohio U, and conferences like JavaOne would even create in-world representations to widen their appeal and reach out to new customers, learners, or attendees. Virtual advertisements were big, and people made real money from selling virtual goods.

I logged into SecondLife occasionally (before its software exceeded my video card capabilities - I can be such a Luddite at times), but I don't think I actually enjoyed it. There wasn't a whole lot to do. And the things you could do may have looked fun, but really weren't. I remember going to a dance club. To dance, you'd click on your avatar, select a dance script, and watch your mini-me jitter away. How fun. Another time, someone took me for a ride in their dune buggy. Had this been Real Life, that would have been very fun! But watching my avatar ride around was quite unfulfilling. I remember typing, 'Wheeeeee' without really feeling it.

But someday, SecondLife could be really exciting. What if to dance, you actually dance, and your Project Natal sensor bar (or something similar) converted your physical movement into your avatar's movement? Ooh, and what if you could get actual advice on how to improve your dancing, because an algorithm could see your movement, and recognize that you're not doing that twirl quite right, but if you could just time your arms slightly differently... there, now you can do it! You could learn all sorts of things: Dancing, tae kwan do, yoga, piano, guitar - the list is limitless. I'd like to call this idea Computer-Assisted Performance Instruction, or CAPI.

In the past, I would enter SecondLife, and leave minutes (seldom hours) later, not feeling any better for the experience. But what if I could enter a virtual environment and learn something, or perfect something, or (and this will require its own spin-off blog post) engage in meaningful relationships with people who have actual knowledge, experiences, wisdom, or friendship to share (and aren't dressed like 6-foot-tall furry squirrels)... now that would be something that could augment my life!

As a puzzle creator, I'm interested in what makes puzzles fun. Two things strike me as particularly important to a successful puzzle: The way that solved answers begin to reveal other answers, and the ability to solve a puzzle without resorting to guesses or brute force.

Crossword puzzles and Sudoku are two types of puzzles that demonstrate the progressive revelation of unknown answers - and these are two of the most popular puzzle formats around today! Every answer helps narrow down the choices for other answers, eventually leading you to a solution for the whole puzzle, followed by a feeling of puzzle-solving elation. There are other puzzle types that do not embody this principle, including word searches and anagram games; each answer is found independently of the others. When you're done with a game like this, there's less of a spark (that "puzzler's high") than in a game where the answers build off each other. There could just as well be 5, 10, or 20 more or fewer answers to the puzzle, and the puzzle wouldn't feel any different. In fact, a sufficiently large puzzle with many independent answers may start to feel boring pretty quickly.

Good puzzles also give the solver a starting point from which to begin finding answers. Maybe the starting point is some filled-in squares, a sample answer, answerable clues, or a limited number of starting positions. There are some puzzles, however, that lose a lot of points in the fun department by starting with too large of a space of possible answers. I have recently seen puzzles in which you have to spell a word, given the telephone keypad numbers that would be used to spell it if you were texting the word. For example, given 2 = ABC, 3 = DEF, etc., you need to find out what word can be spelled from "2478475223". Looks like "agr," "bir," "bip," and "chr" are all good starting points, but finding the right answer for the first couple of characters doesn't help reveal rest of the puzzle, aside from simply being the beginnings of words in the language (for example, solving 2 = 'a' doesn't mean the other 2's are also 'a'). Just because a puzzle reflects something people do today (texting, in this case) doesn't mean it's fun.

Do you remember playing with spiral graph toys, like Spirograph®? In those types of toys, you'd have fun drawing spirals with toothed gears that fit inside rings (or that sometimes rode on the outside of a ring).

What you probably didn't think at the time was, "Gee, I wonder what would happen if we create an abstraction of this toy, then extend it to simulate the combination of many gears, some of which don't even need to be bound by the realities of physics - they can be larger than the gears they sit in, or they can rotate in any direction."

It turns out that if you do think this way, and then develop a bit of software to test your ideas (using the hot-off-the-press HTML5 and ProcessingJS, in this case), you'd have an interesting new toy on your hands.

You'd also be able to create some pretty cool spirals:

Try my Advanced Spirals application, and see what you can come up with!

I believe that collaboration will be a foundation of almost all software in the near future.

I've used Google Docs, particularly Google Spreadsheets, in a collaborative manner as part a puzzle hunt competition. We'd have anywhere from 2 to 15 people working on a puzzle at any given time, and everyone is making updates to the spreadsheet simultaneously - entering answers to clues, arranging the clues, creating new columns for listing interesting aspects of the answers, and so on. After an experience like this, it can be almost painful to head back to the office and work on single-user document tools, like desktop word processing tools, when my team is all taking notes at the same event. Maybe I should get the team to use Google Docs more frequently.

I believe that collaboration is powerful and useful; once the genie of collaboration is let out of the bottle of our collective software experience, it will be impossible to push back in. There are many software applications that will benefit from collaboration.. I think that, for most types of software, the ability to support collaboration will be a critical piece of a software's architecture.

Welcome to the newest incarnation of idea2product!

I intend to use this blog to spread the joy of transforming fascinating ideas into outstanding software products.  I will cover best practices and new innovations in the software lifecycle, the ups and downs of business and marketing, and most importantly of all, the travails and the glee of the end-user. I'll also expound on the thoughts, ideas, and projects that keep my mind churning and make me who I am.

This ought to be a fun and informative ride!