U2I Blog

  • The u2i way
  • Services
  • Acceleration
  • Our clients
  • Careers
  • Contact
  • The u2i way
  • Services
  • Acceleration
  • Our clients
  • Careers
  • Contact

October 13, 2022 by zibmedia Leave a Comment

Coming from a Ruby on Rails background, I appreciate solutions that become community standards of solving problems. One example is DatabaseCleaner, which ensures that your software projects tests run in separation and there are no data leaks between them.

Recently, I was looking for a similar solution for Python, but was unable to find one. However, it’s easy to leverage what SQLAlchemy and Pytest offer to wrap tests in separate database transactions. Below you will find a take on the problem that you may find convenient to use.

Setting up a DB connection

Before we’re able to use a database with transactions in our tests, we need to set up a separate DB instance exclusively for tests. Then, from our test suite, we need to connect to the DB. Here’s an example of how to establish a connection with a MySQL database: [insert image]

If you use another database engine, head to SQLAlchemy documentation for information on how to build different connection strings.

Table creation and DB seeding

Next, we need to recreate our database structure. Let’s assume that all models in your app are declared in the models.py file.

SQLAlchemy offers methods to easily create and drop tables declared in the schema: create_all and drop_all. We will use them at the beginning of the test suite execution to ensure that all tables are in place. After a full test run, we will drop all tables so that the next execution can start with a clean slate.

If you need the database to be pre-configured with some data, you can run a method seeding the database.

Wrapping tests in transactions

As a final step, we need to establish a way to use transactions in our test suite by building a fixture that creates a new transaction for each test. You can then inject the fixture into your test cases. At the end of each test execution, all data created will be wiped out, ensuring test case separation.

Summary

It doesn’t take much time to set up working transactions with Pytest and SQLAlchemy once you know how to do it. I hope that you will find this solution convenient and easy to use, helping you to avoid software mistakes.

For future reference, below is a full code that you can reuse in your projects.

If you need any help building technology as you are scaling up, u2i.com is a tech company with over 50 developers that understand how businesses work. We have diverse skillsets: back-end, front-end, full stack, mobile, UX design, DevOps. Whether you are looking for healthcare software, education software or other solutions, we build applications with you, not just for you. Medtech, Edtech, Health tech and everything in between – we can do it all. Get in touch and tell us your story and let’s find a solution together.

Filed Under: Uncategorized

July 22, 2022 by zibmedia Leave a Comment

You’ve got a great idea that you want to build on, or an existing business looking to expand your operations online and at some point, it’s going to need tech.

No doubt you’ve done your research, spoken to clients, and you’re building knowledge on where your market is, how to maximise your opportunities, and plan to build a framework that will bring you success. You’ve listened, you’ve had valuable feedback and data, and this has been used to improve your project. You’re quick to change and can adapt to meet your market…

So, why is it that when it comes to businesses building tech, the emphasis moves from understanding the business to understanding the tech?

When tech agencies and businesses get together, there often becomes a rationale that “we know everything we need to know, so let’s now build it”.

The thinking stops, the listening stops, and the build begins.

People stop listening, instead of asking “what can we learn from this?” and continuing to explore.

Recently, I was asked to observe a journey between a client and its tech agency from the first meeting to the end. The result was not positive.

  • The client was annoyed they had lost time and did not get what they asked for.
  • The agency was shocked as they thought they understood the brief.

The failure was not obvious to the client until the end. So, wanting to understand how it happened, the client and I held a retrospective (thanks retrotool.io !) to identify when the project passed the point of no return. We reviewed the planning sessions, communication flow, the build, and the final presentation to the client. We were shocked by the findings…

Projects going wrong is not uncommon, a survey of professional Project Managers (2017) found that 49% of projects experienced scope creep and/or increased cost. It also found that the failure rate of IT projects is 14%. What is confronting is that this survey was taken amongst professionals who have experience in handling this type of work, and yet even they get it wrong.

The illusion of understanding

So, how and where did the project go wrong and who is to blame? Did the client properly brief the agency? Did the agency not understand the brief? Both client and agency believed they had understood one another.

Are they talking the same language?

This is where the feedback from our retrospective (thanks Retrottl.io !) got very interesting. We identified that critical failure happened in the first 30 minutes of the very first meeting.

In this case, there was a moment when the client and agency reached an illusion of understanding of what they are going to do together, and the build started.

Both believed that no other questions needed to be asked.

The retrospective (shout out again to the online retrotool.io guys for a great product!) showed clearly that the path of failure started in the very first meeting. Every action from the point of agreement led to failure, so what could be done differently?

3-dimensional thinking

Don’t ask ‘how’, ask ‘why’. You are in a world of conceptual thinking. In our experience, planning any new project is totally conceptual. It takes creative thinking, vision, understanding of business, and expertise in technology to work. You are moving into unknowns and the key is to gain understanding in your journey.

Your project also must work today, work tomorrow, and be planned well enough to be improved and updated in the future without becoming unstable or slow.

Many projects we see come to a full exploration-stop without questioning in the planning, or during the build.

And here lies the rub. Earlier I talked about the retrospective and in it we saw:

Height – The client framed the build from the point of their business. They believed they were clear about what they believed they wanted to build.

Width – The agency translated the client brief into build features and applied it across the width of their tech stack knowledge.

But there was no Depth, and depth is where business experience, technical experience and project-build experience comes together to build a holistic strategy that continually questions whether the build remains relevant to the client’s business.

“You’ve got to start with the customer experience and work back toward the technology – not the other way round” – Steve Jobs

Steve Jobs also said that one of the first things he learnt was, “what we were missing was to provide benefits to our Users.” So the ‘why’ needs to include ‘is there a benefit to users?’

Agencies asking business questions is ‘push back’ to better understand ‘why’. In our mind, the project is not an endpoint in exploration, but rather the test-bed for exploration that will provide ongoing data which we will all (client included) be able to make knowledge-based decisions as we progress.

Depth results in becoming a better business

A really keyword in Steve Jobs’ quote was ‘benefits’. Too often this gets confused with features. Agencies love to build features, but the question is, does the user value them?

How do you identify ‘Depth’ in an agency? Having left us over price, a client once told us that they had returned to us their replacement agency did exactly what was asked of them, and that wasn’t good enough to give the client the edge in business.
As an agency, we spend about 80% our time talking potential clients out of starting to build anything.

Here’s a checklist to evaluate your tech. journey:

  • Exploration is critical: can you run your project manually? Here is where you will learn what users like and dislike about your project.
  • Exploration does not stop when a build begins (it is not a hard stop).
  • Pile up everything you know and label it ‘the why’, then ask yourself ‘does it benefit the users?’
  • Don’t think MVP, build a MEP (Minimum Economic Platform) What is the simplest, stripped-down version of what you need?
  • Ask your clients and prospective Users and keep asking them – not just at the beginning, but continuously. Their feedback will shape the product into its best iteration.
  • What journey is the User going to take? Avoid the Qantas $40m platform that no engineer used. Guess who Qantas didn’t consult during the planning and build?
  • Test your intuition and get feedback from your Users – you’ll quickly know if you are right or wrong.
  • If you run out of questions, you have either stopped asking, or actually have enough data to make a knowledge-based decision – which is it?
  • Lastly, what are you learning about your business and your project? As you start your build, you should be continuously learning.

Choosing an agency

An agency should work as a bridge between business and tech. It should interpret your needs into tech, but also push back and demonstrate Depth – what questions are they asking you? Do they focus on the tech or the user journey?

It takes 3-dimensional thinking that goes beyond the high aspirations of the client and the width of an agency’s technical stack. It takes a depth of understanding to answer the questions that have not yet been thought of from the information we do not yet have.

Does the agency understand ‘the why’ of your project? Do they get what you’re trying to achieve?

“The important thing is not to stop questioning” – Albert Einstein

Jonathan Castletine-Jackson is the doorman into u2i, a bespoke IT Development agency that builds relationships to understand your business before it builds your tech.

Filed Under: Uncategorized

  • Twitter
  • Instagram
  • Facebook

Services

  • What we do
  • How we do it

Our Clients

  • Our Clients

Careers

  • Our mission
  • Jobs

Contact

  • Privacy Policy

© 2022 u2i LLC. All rights reserved.