Fast and Slow Questions

I like going to art galleries and am genuinely impressed by at the skill and creativity of the artists showing their works. I'm typically drawn to the more technical works that, in my mind, highlight ability over expression. Photorealistic pieces are my favorite. Sometimes I like the abstract or minimalist, but that's just less often. Everyone has different tastes, because we are all a little different, and that's great!

The one thing about art galleries is that it does not take me more than five seconds to know if I like a piece or not. I do not need to, or care to, stand and ponder. When it comes to engineering projects, there are fast questions and there are slow questions. Certain times or certain clients might require one over another, and the questions you are asking will drive the outcome.

Slow Questions

A typical slow question might be "What do you want?" or "What do you need?" Generally this could be called brainstorming, and whether that session takes an hour, or even more sessions, the question is slow. The feedback takes times to think about. The big picture is not fully formed. Everyone has different ideas and goals in mind.

Sometimes slow questions are needed. Requirements need to be generated. Technologies and processes need to be evaluated. Requirements need to be updated. 3rd Parties need consulted or included. Maybe it becomes painfully slow! Yet by the end, you have a well designed system and everyone is on the same page with the outcome expectations.

Fast Questions

Fast questions have fast answers. "Yes or No?" "What don't you like?" The fast question will demand fast feedback, and is often iterative. This is not a single question and then everything is done, but one question leads to the next iteration and the next fast question, yet things keep moving and people remain engaged.

Experience plays a huge factor in being able to ask a fast question. Knowing what is out there, and how to apply tools or technologies. Knowing what has worked and what has not. Proof-of-concepts with a demo project. This type of experience allows for questions that can be answered and acted upon quickly.

What Questions Are You Asking?

If you work with the DoD or for a large enterprise, often you'll be asked (or asking) slow questions. A lot of people, risk mitigation and contract preparation needs to be set up prior to the work. It can feel slow, yet often is necessary.

Smaller teams and those trying to get an edge (first to market or finding new business) cannot afford the slow questions. Either a client is not willing to pay for the perceived delay or they do not have the answers to your slow question anyway ("What do you need?"). Having a prototype could be key for faster situations, because it allows for a fast response. "Is this what you meant?" "What changes before we go live?" These are fast questions and can accelerate development and interest.

The types of questions we ask are the types of answers we will receive. At the art gallery, I'll still ask the fast ones.

Prototype Rocks Are Better

A common analogy with my bosses is "Bring me a rock." This fictional conversation between an "idea person" and "engineer" would go something like:

Idea Person: "Bring me a rock."
Engineer: "Here is a rock."
IP: "It is not dark enough."
E: "Here is another rock."
IP: "Why is it so jagged?"
E: "You want a darker, smooth-ish rock?"
IP: "Yes, obviously."
E: "Here is a rock."
IP: "...it's too small."

We are not geologists, and this conversation is not really about rocks.

Ideas are not bad. Quite the opposite, they are necessary! People who come up with ideas are vital from an entire organization down to a small development team. New products or features were not written down long ago and rehashed; they were new ideas at some point and through many steps, and sometimes many iterations, became reality!

Ideas are hard to pin down, and sometimes they are fluid. When a person has a great idea, there are steps involved to make that idea real. Many steps. Rambling off a few sentences of the idea and thinking it will be done to any vague expectation of success is hard to achieve. Especially to an engineer who needs (lots of) details.

And yet, this happens all the time. Which is normal in a lot of cases, and idea people and engineers work together to make it happen. It's called "design."

This  situation becomes a problem when the idea person and the engineer are not working together. Suddenly the idea person wonders why their simple idea is not done yet, and the engineer is frustrated at wasting time on undefined "requirements." Two or three iterations of "Bring me a rock" can wear someone out! Compound this with an idea person that changes their idea before the engineer shows them anything, already invalidating some of that engineer's work! Aaaaarrrgh!

That why you need a prototype.

Having a prototype type is the place to really start a conversion with those idea-person-types. It is tangible. It is something to talk to and point at. The dev team needs to get that prototype ready as fast as they are able (keeping in mind their process and maintainability goals), and the "idea people" need to wait until the prototype is ready before making any new suggestions or changes. Unless something is drastically wrong, or some data proves otherwise, stick with the prototype and discuss when it is ready.

Beyond shortening the "bring me a rock" exchange, a prototype clarifies ideas. When five people leave the idea meeting thinking of a rock, more often than not they are picturing five different rocks! Looking together at a prototype may result in a long list of changes, but the changes are defined and everyone is clear on what is being done and what to expect as a result.

Prototypes are also handy when people do not even know the type of rock they want You might explain the rock five different ways, but until someone sees it, it might as well not exist!

E: "It's a round, smooth, gray rock about the size of a grapefruit."
IP: "I've never seen that before."
E: "I haven't built it yet. Just try to imagine it."
IP: <blank stare/>

Great explanations and ideas will only go so far. At some point it needs to be tangible. And once it is tangible, people can actually engage in the conversation.

Hopefully bringing rocks and asking for rocks will be part of you future. Just remember that prototype type rocks are better. For everyone.

Choosing The Right Technology

"He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever." - Chinese proverb

The development space is changing quickly these days. Open Source software and easier collaboration is producing a large amount of new software libraries and frameworks at a very rapid pace. Which is awesome!

However, you can't keep up. Fundamentally, maybe you can follow the concepts or general principles of the software in question. But getting hands-on time on everything out there? Impossible. Too much to learn, too little time. Maybe you could slice a small piece off the Java/C#/NodeJS/AngularJS{{insert your favorite here}} pie and get really good at it, but you'd be getting further behind everywhere else.

Take the database space for example. How many types of databases could you name? (relational, key-value, document, graph, etc.) How many products or engines could you name for each type you could name? 1-3? Have a look at db-engines.com. Could you name half of the categories on the left? Would you have expected over 200 listings of DB systems? If you needed a database in your next system, which one do you pick? Certainly nothing below ranking 100, right? . . . ranking 50? . . . ranking 10?

And there are many parts to a software system. And each project is different.

To jump to the point, I'll just ask the question I want to answer...

Can you pick the wrong technology? 

No.

Not really, anyway.

You might pick a solution that is overkill for your task. Or maybe one that doesn't do everything you need so you have to bolt on extra bits.

Most software languages are capable, especially with the right library. And most software can be used for a variety of purposes, even if not intended. You see, developers are creative and industrious. They will find solutions no matter how poorly the technologies line up. When it needs to get done, it is surprising what comes together. (Or how the definition of "done" changes ; ) Coming from the defense industry, there is some old and crusty software that has been working for a really long time and continues to perform.

It is better to have an approximate answer to the right question than an exact answer to the wrong one.
- J. Tukey

So while most software languages, frameworks or systems could be used to solve your problem, there could be a "more right choice". The right combination of software can make your life easier, but as of yet there is not a "one size fits all" solution to every project, every time.

Consider the following questions as you start your next project and are choosing the technology. Hopefully these, and the many side questions they produce, can guide you to a "more right" decision and avoid some pitfalls.

How fun will it be?

I ask this first because it's probably the #1 reason you're considering changing software. Read a good scrolling marketing landing page? Did some other company manage to use this software in a cool way? Is it trending on some google search or stackoverflow question list? 

Honestly, these are not bad reasons to try something new. Like I mentioned before, it will probably work out for you (at least initially). But be careful. This question could get you into a lot of trouble and suddenly isn't so fun, yet too late to switch.

Can it do what you need?

Now here's a good question. It involves knowing what your new project is doing, and is especially meaningful if there are boundaries to your requirements. The project that has a fixed list of features has latitude in terms of technology choices than the project that "will start small, but we'll grow it into our business for the next 3-5 years."

Have a web page that will be about 4 pages and 10 components with 5 API calls to the server? Pick any framework you want! Every web framework can do that. How about 10 pages with 15-20 components, that fully drives an API? Better think about what it is you're trying to do before jumping in. 

What can't it do?

The opposing side to the previous question. Identify where the limits exist, and there will be limits. Are those limits crucial to your project? Will it be a problem in the future? (Is that future 2 to 3 major releases away?). Just knowing what problems may come up will help you be ready and help you think more about what you're doing (design). You don't need to solve them all now, but don't go in blind. 

Can you afford to learn?

I worded this question to emphasize that learning is important. Different concepts and approaches will be useful for sure, and also builds the options for following projects (or resumes). 

But learning takes time. What kind of schedule are you under? What is the learning curve? A new framework will have a large curve while a new library or component will be smaller. How much new stuff are you using? New language, new framework, new database and new deploy tools all at once? Careful there . . .

There is a cost to learning and some projects will be able to afford it, while others will not. Is it worth the cost this time? Tried and true technologies that your team is comfortable with will go a long way and add speed and consistency to your development, though be aware of the changing landscape in case your stack gets left in the dust and you're playing catch-up.

How strong is the ecosystem?

Remember how Open Source software and collaboration are changing the landscape of software these days. Use that to your advantage. It's not like a new software technology is thrown at you and you have to go read an O'Reilly book or standards document to even get started.

Is the software documented, and does it contain examples? One command install? Are there blogs? How many questions are there on stackoverflow? How many issues and pull requests on its github pages? These are just a few questions to help determine if the existing ecosystem is mature, because it basically comes down to time. Will it take hours or days to fix that bug or get something setup? Chances are you're not re-inventing anything and the question has already been asked, or the problem already looked at. Think of where you can go for advice.

The other side of the software ecosystem is longevity. Will your technology choice be around as long as you need it? Will updates happen that fix your problems? Will too many updates happen that cause you problems because it's release 0.3.45 beta? It is easy to start a library these days, but will it be maintained?

Of course, if you only use mature and stable software, you might be missing out on getting a technological advantage of trying something new, or miss the chance to be part of something from the ground up. Is that important to you?

Wrap Up

A lot of rhetorical questions flow through my head when choosing software. I do not want to dwell too long on the choice, but cannot afford to blindly choose or forego advice when picking something new. There may not be a perfectly right technology out there, but for your team and your project, it is possible to pick one that is more right than others.