When building a new software product, founders are typically laser-focussed on building a product that meets their immediate business needs for launch. With limited time and money to bring a product to market, that’s wise. Just be aware that too tight a focus often leads to rigid software & systems and can cause significant pain after launch.

The high level characteristics of a software system, such as its flexibility, scalability and stability become increasingly hard to change as the system is developed. They’re hard to retrofit, so it’s important to think about what’s important up front, and plan for it.

Yes, building to flex, grow, scale and be reliable will take more effort up front. But the up front effort pales in comparison to the effort to achieve the same once the system is developed.

If you’re building a tech business, you need a product that will grow with you & let you achieve your business goals.

Pixiotix specialises in working with founders to make pragmatic system, software and database architectural and design decisions that will give you a clear path forward to an awesome product. Check out the site & get in touch to see how we can help.

When it comes down to it, there’s a lot of commonality between SaaS products. Signup, login, user management, dashboards, integrations. There’s a myriad of ways you can access / buy / build this functionality and there’s little technical risk involved in getting it working. A key question early on is: “What’s your intellectual property”?

Your IP is key because it’s what differentiates your product from others - having strong IP is key to not being overtaken by a bigger, better funded competitor.

But developing your IP will be harder, slower and carry considerably more technical risk than developing the rest of the product. Finding engineers who can build what you need will be harder too. 

Ask yourself early on what’s unique about your product? What’s the fundamental technical core to what you’re trying to do? How can you increase your understanding & decrease the technical and resourcing risks so you’re not surprised down the track?

Look after your IP and your IP will look after you.

Pixiotix specialises in consulting for founders developing innovative software / hardware products with critical IP. Check out https://pixiotix.com and get in touch to find out more.

The saying “When a measure becomes a target, it ceases to be a good measure” applies very well to software development. If you’re trying to measure output / quality in software development using any simple measure you’re doing it wrong.

Measuring lines of code? Expect verbose code...
Measuring tickets closed? Expect smaller tickets…
Measuring features completed? Expect a drop in quality...

Pushing harder on these metrics when the going gets tough is only going to lead to developers gaming the metric, consciously or unconsciously.

The golden rule? 

Build a team you can trust... and trust them.

Got a technical problem to solve? Analysing data? Machine learning! Deploying code? Spin up a Kubernetes cluster! Need a web app? Jump into React! Sharing information? Crank up a blockchain!

Not so fast! All technologies have their positives and negatives, and their applicability, costs and benefits vary greatly based on the problem they’re applied to and particularly the scale of that problem.

So consider the options carefully - Cassandra vs RDS vs MySQL vs sqlite? Kubernetes cluster vs EC2 vs hosted server? Each decision is critical - avoid the lure of the cargo cult.

Having trouble making a call on which technologies to use in your startup? Need some help evaluating the options, keeping costs low while you start, while being ready to scale? Get in touch with Pixiotix and get considered, independent, practical advice on these problems and more.

Software developers, your job *isn’t* to make your work easy. Software development involves a lot of tradeoffs, and if your thought process is “what’s the easiest way to solve this problem?”, you’re not going about it the right way.

Think longer term, bigger picture. Understand that all those fiddly little decisions you need to make day-to-day add up to significant impact on the customer, the team and ultimately the company.

If you hit a bug while looking for some other issue, figure out what’s going on and fix it! If adding a small new feature would make the code unwieldy, restructure. Make sure columns in tables sort correctly - not “technically correct” - but “as the customer would expect”. Think through those frustrating corner cases and deal with them, Expect things to fail and handle errors appropriately!

Day to day micro-decisions from engineers have a massive impact on customer experience, product quality, code quality, and ultimately on the company bottom-line.

When I’m called over to help out with a tricky problem in a complex software system, I’m typically hit with lots of detail on how the problem is manifesting. Typically my go-to response is “let’s take a step back”...

In a lot of instances, issues that manifest in a very specific way are in fact symptoms of a larger scale problem, so it’s important to put them in context. Pull back far enough, and the bigger problem should become apparent - staying micro-focussed can obscure the view.

It’s an unfortunate fact of Software Engineering that failure modes are typically the worst tested code paths, so a failure at one level will often manifest as a subsequent failure at another level. Make sure both (or all!) problems contributing are identified and fixed.

When problem solving, make sure you don’t miss the forest for the trees.

Having trouble finding Software Engineers who are experts with years of experience in the exact technology you need? Well I’ll let you in on a secret - you need to stop looking for unicorns…

Software languages, tools and systems move so fast that if an engineer isn’t continually learning, they’re falling behind. But great engineers aren’t just trying to keep up - they’re driven to experiment and learn. They’re always looking for ways to make their projects more efficient - whether that’s by tweaking their working environment, automating mundane tasks or learning whole new languages.

An engineer with three languages and two web frameworks under their belt is going to have no problem getting up to speed on some missing experience if they’re sufficiently motivated.

Look for evidence of passion, learning and experimentation and use this to help your hiring decisions.

🦄 🌈 

When I, along with so many other professionals suddenly started working from home last year, I thought it would be awesome. And it certainly had its advantages - no commute, less interruptions, more flexibility to exercise & spend family time. Many tech folk rejoiced and declared that this was the way we should all work, all the time.

But work-at-home is no panacea. Many people simply don’t have the space / separation to do long term focussed work at home. Many have kids, family and house-mates around. Internet access varies wildly across cities and suburbs. Bad ergonomics can have a massive impact on people’s health when they are subjected to them full time.

It is also considerably harder to collaborate effectively remotely. Even with instant messaging, teleconferencing, virtual whiteboards etc, the ease of collaboration that can be obtained standing around a whiteboard in a meeting cannot be matched.

I’m about to take my business out of the small space I have carved out at home and full time into a co-working space. I’m looking forward to the change of scene, the separation from family, the tea room, and yes, even talking to other occupants of the space!

Even the short commute is appealing - a little bookend to the working day. 

Long term, I’d love to see companies experimenting with hybrid office/remote working setup. Where “remote” could mean home / paid co-work / or a satellite office. This could be a killer combination that balances flexibility & lifestyle with employee health and in-person collaboration which is so important.

Also published on LinkedIn

Significant pieces of engineering work can benefit greatly from design review. The review process can be as simple as an informal chat between peers or follow a formal process with a proposal document and written feedback or an in-person review session.

Design review is particularly valuable when a problem is highly constrained through user requirements or technical difficulty.

Design discussions often swing wildly between a number of proposals which all seem reasonable at first glance but are discounted due to various deficiencies with respect to requirements. Ensure the team feels empowered to challenge proposals, and not threatened by having their ideas challenged. 

As a leader, prepare for your proposals to be found wanting by the team - it can hurt but if they come up with better proposals, you’re winning.

Strong collaboration requires strong communication. Building a culture of strong, open communication is critical in the success of teams.

Good communication is clear & concise - it gets to the point and stays on the point. 

Good communication is correct and consistent - it’s fine to not have all the answers, or be confident about something. Giving a solid answer may require some research and it’s likely everyone will benefit from it.

Encourage participation in discussions, and ensure contributions are heard and considered.