Tips for Technologists is a series aimed at teaching you to engage with technology in best way possible. You can see all the Tips for Technologists articles here.
By Nick Ruffilo
There are many wonderful books out there about the power of positive thinking. If you’ve spent even a few months on the business side of things, you’ll know how much work can get done when people focus on what is possible and not what is not. The same is true in technology.
Software has nearly no limits. Very small teams of software engineers (3-5) are doing wonderful things at research institutions, startups, and big companies alike. The dilemma is, how do you know you can do something until you’ve done it already? When it comes to software, if you’ve done it already, and you have to do it again, you’re essentially done as soon as you begin. You take your code from the previous project (or process, if you’re using a set of tools) and replicate. But, when faced with something you’ve never done before, it can feel like you’re staring at a blank canvas, blindfolded, not knowing exactly what colors you have, or how your art will look.
Most Tech Problems are Like Jigsaw Puzzles
Unless you’re trying to create a truly revolutionary process or piece of software, chances are that every piece you need is already done for you. Want to build an e-commerce website? Depending on how much money you’re willing to spend, there are complete turnkey solutions. There are WordPress plugins to enable e-commerce, or you could explore platforms like Shopify, Magento, or a whole host of others. Where I see issues is when the business and IT sides do not agree on what the final picture of the puzzle will look like.
Each bit of functionality you want is a piece of the puzzle. Large multi-purpose software acts like one large piece. While it may save you time, its size may make it difficult to fit other pieces around it. But, if your project turns into a 1,000-piece puzzle, you’re going to need a very special team to to figure out how those pieces fit together in the right way. Unlike a manufactured puzzle where it is guaranteed that all the pieces fit together, in the software world, this is not true. Often, two pieces don’t quite fit, and one must be modified. But not all software lets you make changes.
Back to the big picture — literally. If you don’t know what the final image should look like, the outcome will never be right. The business side needs to know what the final image will look like to determine if it meets the needs of the customers or the company. The technology side needs to know what the final image looks like or it will be very difficult to make the right architecture decisions or deliver the right project.
UI and SDLC had a Rebel Child, and His Name was UX
UX, otherwise known as User Experience, is probably the best way to sketch that final image for all consumer-facing applications. UX design takes into account more than what is literally on the screen, but also how the user interacts with it. There are many ways to do UX modeling — from using UML to user flow models, to annotated screen mockups. Five years ago, UI (user interface) designers would have said something like, “Buy button will be placed below the cover image.” Today, UX says things like, “Users browsing a page with a cover image on it will want a buy button. The buy button needs to provide links to all the market places we are listed on, as the users may have any number of devices.”
Focusing on UX allows technologists to make the appropriate technology decisions and business managers to make the appropriate business decisions. Technology isn’t saying: “With this software, we can only do X, and Y, not Z.” and the business isn’t saying: “you must use software B.”
Break Down the Pieces to Achieve Your Goals
It doesn’t matter how good you are with any tool or programming language, there are always going to be a few pieces of the puzzle that are new to you and possibly intimidating. Start easy and figure out what pieces are done exactly as you need them. Go through your code/process and acceptable open source projects to find perfect matches for as many pieces as you can. Then, look at the pieces that may require just a little bit of modification. Finally, try to figure out the difficult pieces.
Thanks to a search engine, some wonderful programmers providing their code for free, and your copy/paste skills, you can complete the challenging project with two weeks left to puzzle out the last one or two interactions that you need to code from scratch.
For the Advanced Crew
The better we get at something, the more we know about we can’t do. This is bad. If you had the requirements to build a system that would take an audio book and sync it up with text (and find possible inaccuracies) you might look at that as a hugely daunting task. In fact, if you’re a PHP coder, you might even say that the audio libraries to do such a thing just aren’t there – you’d have to write your own speech-to-text. Since you know this, you’ll be firm and push back on those requirements. Before saying anything is not possible, or too hard, give a search. Did you know there is a new Google API that does speech-to-text (with confidence levels)? Also, while your programming language may not have the APIs, there are external server-side software that could bear the brunt of the work. Basically don’t let yourself get in the expert trap where you become too confident in what you can and can’t do.
Bringing It All Together
No matter if you are new to something or an expert, there will always be requirements that seem impossible. But, with the following steps you can turn that impossible into possible:
1) Do a web search for a solution
2) Break the requirement down into chunks and search for solutions to that chunk