Chris Impey is a writer based in New York City. He's interested in all things tech, science, and photography related, and likes to yo-yo in his free time.


Follow him [on Twitter](https://twitter.com/chris-impey).

Chris Impey

Emma Hazel is a writer based in New York City. He's interested in all things tech, science, and photography related, and likes to yo-yo in his free time.


Follow him [on Twitter](https://twitter.com/emma-hazel).

Emma Hazel

Thomas Macaulay is a writer based in New York City. He's interested in all things tech, science, and photography related, and likes to yo-yo in his free time.


Follow him [on Twitter](https://twitter.com/thomas-macaulay).

Thomas Macaulay


## ~~Test~~ Example Driven Development

Test Driven Development (I’ll refer to it as TDD from now on) is a software design technique that has been created and sponsored by the mighty Kent Beck, one of the 17 original signatories of the Agile Manifesto.

TDD is quite straightforward, and it’s best explained through an example.

Let’s say we want to develop a function to calculate an employee’s salary by counting the days worked, taking into consideration the holidays taken and sick days used. How would we go about that?

Let’s put ourselves in the shoes of our function’s users. How would they want to use that function? Let’s write an example:

```jsx
const employee = {
	salaryPerDay: 100,
	daysWorked: 250,
	holidaysTaken: 15,
	sickDaysUsed: 10
}

const yearlySalary = calculateEmployeeSalary(employee)
console.log(yearlySalary); // 27300
```

Is this function any good? Maybe, let’s say it is. TDD puts you in the right mindset to create a user-friendly, maintainable design. And when I say “user” I mean your fellow colleague or yourself in 2 years.

Now, this code is going to fail of course, because the function doesn’t exist yet.

```jsx
ReferenceError: calculateEmployeeSalary is not defined
    at <anonymous>:8:20
    at dn (<anonymous>:16:5449)
```

One of the secret ingredients of TDD is **making very small steps**. Always ask yourself, what’s the smallest thing I could do to get some progress? For the code above, we just need to create the function signature, so to solve the error.

```jsx
function calculateEmployeeSalary(employee) {}
```

When I execute the code I now get:

```jsx
undefined
```

Which is fine, because the function is not implemented, yet. We’re expecting the console to print 27300, what’s the smallest step we can take to make it happen? Simple.

```jsx
function calculateEmployeeSalary(employee) { return 27300 }
```

You’ll be thinking, well, thanks a lot for that! I want you to trust me, this will make more sense later in the article. It’s always about making small steps.

Now it’s time to implement our function (thanks ChatGPT for that):

```jsx
function calculateEmployeeSalary(employee) {
  let totalSalary = 0;

  totalSalary += employee.salaryPerDay * employee.daysWorked;
  
  if (employee.holidaysTaken > 40) {
    totalSalary -= employee.salaryPerDay * (employee.holidaysTaken - 40);
  } else {
    totalSalary += employee.salaryPerDay * employee.holidaysTaken;
  }

  totalSalary += employee.salaryPerDay * employee.sickDaysUsed * 0.8;

  return totalSalary;
}
```

You may want to test the function with different combinations of data, so as to hit all the logic branches. In the example above, we’re in a situation where the employee has taken less than 40 holidays. Let’s create an example for the opposite situation.

```jsx
const employee = {
	salaryPerDay: 100,
	daysWorked: 250,
	holidaysTaken: 50,
	sickDaysUsed: 10
}

const yearlySalary = calculateEmployeeSalary(employee)
console.log(yearlySalary); // 29800
```

But wait… it prints `24800` instead 🤔 ChatGPT, you naughty robot!

The problem is that even if the holidays taken are more than 40, only the excess is subtracted from the total salary, but the initial 40 paid holidays are skipped.

Let’s fix that:

```jsx
function calculateEmployeeSalary(employee) {
  let totalSalary = 0;

  totalSalary += employee.salaryPerDay * (employee.daysWorked + employee.holidaysTaken);

  if (employee.holidaysTaken > 40) {
    totalSalary -= employee.salaryPerDay * (employee.holidaysTaken - 40);
  } 

  totalSalary += employee.salaryPerDay * employee.sickDaysUsed * 0.8;

  return totalSalary;
}
```

Now it works! We also have to run again the first example where the employees have taken less than 40 holidays. And da daaa, we get `27300`. 

Our job is not done, you can continue testing for edge cases, but I’ll keep them out for the sake of simplicity and to not bore you to death. 

Something that I’ve done differently here compared to a more “traditional” way of programming, is **starting from the example, and not from the implementation**. Starting from the implementation may lead to bad design because we’re ignoring the users of the code and the context within the function is being created.

## ~~Example~~ Test Driven Development

TDD will require us to create a test that automates the execution of the examples we wrote above so that you don’t have to run them manually every time. The test framework you’ll using is most likely capable of watching changes for the files you’re testing and re-executing them accordingly. Here’s an example of how the tests could look like. (I’m using the `node-tap` framework for Node)

```jsx
test('calculateEmployeeSalary - correct salary calculation with less 40 holidays', (t) => {
  const employee = {
    salaryPerDay: 100,
    daysWorked: 250,
    holidaysTaken: 15,
    sickDaysUsed: 10
  };

  const expectedResult = 27300;
  const actualResult = calculateEmployeeSalary(employee);
  t.equal(actualResult, expectedResult);
  t.end();
});

test('calculateEmployeeSalary - correct salary calculation with over 40 holidays', (t) => {
  const employee = {
    salaryPerDay: 100,
    daysWorked: 250,
    holidaysTaken: 50,
    sickDaysUsed: 10
  };
  
  const expectedResult = 29800;
  const actualResult = calculateEmployeeSalary(employee);
  t.equal(actualResult, expectedResult);
  t.end();
});
```

The next steps are the same as above, but this time we start from a broken test, then we try to make it pass by working on the function implementation in small steps and without caring much about clean code. Once you get it right, it’s time to refactor it. 

This is the famous red, green, refactor cycle that TDD lovers like to brag about.

![Untitled_Artwork.png](/images/blog/user-driven-development/Untitled_Artwork.png)

Note that TDD can be extended for any component of the system you work on. For example, I use it extensively to design WEB APIs using “component testing” ([you can find an example here](https://github.com/peppesilletti/tdd-talk/blob/main/__tests__/api-tdd.test.js)) (create something, get it, updated it, get it again to check the update, delete it, get it again to check it’s not there). You can also use it to design the API of UI components.

## Benefits of TDD

![Untitled_Artwork 2.png](/images/blog/user-driven-development/Untitled_Artwork_2.png)

### Increased Productivity

TDD boosts productivity by automating the execution of the code you’re writing and giving you immediate feedback on your progress. Breaking the code? You’ll know it. Doing a good job? Don’t be so happy, because you still need to do some refactoring!

### Better Software Design

TDD it’s a powerful tool for designing software because it encourages developers to focus on the behavior of the system, rather than its implementation. Writing tests before writing code forces developers to think about the inputs and outputs of the code and how it should behave in different scenarios. This helps to ensure that the code is designed in a way that is easy to test and understand, and that it meets the needs of the users.

### Improved maintainability and living documentation

Even though TDD is not really a testing strategy, but a designing strategy, we get a set of automated tests for free which help us create **"living documentation"** I’ll for the system, making it easier to understand how it works. As a result, making changes or updates to the code is less risky, because the tests can be run to ensure that the changes haven't introduced any new bugs.

 A good test suite makes it easier to refactor the code, as the tests are there to ensure that the system functions as intended, and developers can make changes to the codebase with more confidence, knowing that if something breaks, it will be caught by the tests.

Maintainability is also improved thanks to the creation of modular, well-organized code, which is less prone to errors and easier to understand. 

### Working with legacy code

TDD is a great tool when working with legacy systems, which we may have no clue how they work, may not have a good test suite and so makes us afraid to change even one line of code. By writing some tests around the existing behavior BEFORE making any change, we can preserve the current behavior of the system and avoid hours of suffering trying to understand what we broke. 

### Communication

TDD could be used during planning with your team. Let’s say you’re in a discussion about a user story and you start writing down a series of scenarios that need to be implemented. You could write a test with an example of those scenarios WHILE doing the planning, and then use it as a base to start designing the technical solution.

### Reduced costs for the business

All the points above clearly bring a reduction in costs for the business, wasting less time chasing bugs, reducing the time developers use to understand the code, and also speeding up onboarding for new joiners.

### Fixing bugs

To use TDD to solve a bug, the first step is to write a test that reproduces the bug. This test should be designed to specifically target the problem and when it is run, it should fail because the bug exists. Once the test reproduces the bug, the next step is to write code to fix the bug. The goal is to make the test pass by writing minimal code changes.

Once the bug is fixed, the test should pass and the developer can ensure that the fix works correctly and that the bug doesn't reoccur. Additionally, once the test case is added to the codebase, it will ensure that the same bug won't happen again in the future by catching it early on if it reappears.

## Cons of TDD

![Untitled_Artwork 3.png](/images/blog/user-driven-development/Untitled_Artwork_3.png)

### Difficulty in testing specific types of code

TDD may be difficult or impossible to use for certain types of code, such as code with complex logic or code that is tightly coupled to external systems.

### Challenges in testing legacy code

It may be difficult or impossible to test legacy code because it was not originally written with testing in mind, which can make it hard to write automated tests.

### Challenges in testing edge cases

In some cases, it can be hard to anticipate all possible edge cases, so some bugs may go undetected by the test suite, especially if the developer doesn't have enough experience.

### Increased development time

Writing tests before writing code can add extra time to develop, as developers must write and run tests in addition to writing code. But aren’t we supposed to write tests anyways?

## ~~Test~~User Driven Development

![Untitled_Artwork 2.png](/images/blog/user-driven-development/Untitled_Artwork_2%201.png)

TDD is not a testing strategy, but a design strategy. Tests are nice side effects and they are not to be thrown away, but the real protagonist is the users. For users I mean:

- The product’s users
- The code’s users
- The API’s users
- The business

*We design the external APIs of our system by interacting with them as if we were the user of the product*.

*We design the internal APIs of our system by thinking about how easily they would be understood by our fellow colleagues or by ourselves in the future.* 

*We design our system to have a testable architecture so that it can be maintained easily and avoid the business wasting time and money on chasing bugs.*

Is it a surprise that we develop code for someone else, and not for us?


Follow me on Twitter: [@peppesilletti](https://twitter.com/peppesilletti)

Test Driven Development is not about testing, but it's about designing great software by focusing on the user.

User-Driven Development (my take on Test Driven Development)


**This article is for those software developers who dislike being treated as code monkeys.** The ones that love to create products and see the impact of their work on the world (a.k.a. making a segment of the human population happier).

This article is also for developers who love to be told what to do, write some code and call it a day. I’m not judging you, I just want to show you a different perspective and hope that you find it insightful.

Let’s start with the question: **What is a software developer?** Stop for a second and answer it before going ahead with the article.

---

I tried to answer that question, and that brought me back in time to when I was 14 (I’m 30 now). At that time I was editing my MSN blog to look pretty and impress girls with my poems and short stories. It was just simple CSS, but man, IT was powerful! After that came HTML, and then PHP and MySQL, and I went all-in building websites from scratch. What came out of that period was a series of failed projects: my personal website, a social network, and a browser game. I wasn’t alone during those adventures, one of my dearest friends also got into “the web stuff” and created a fantasy football app that he used for several years with his friends. We loved technology, we loved building products with it, and we were dreaming big!

We were amazed about what you could achieve with such technologies. And we didn’t care about clean code, best practices, design patterns, and Agile. We just wanted to create something great.

So, what was a developer for us? **Someone who knew how to use technology to build cool stuff that they thought could be useful for the world.** We failed miserably in the last part.

Fast forward 15 years and I’m now working as a software engineer, and I’ve been doing so for the last 7 years. How did my opinion change during that time?

### The product thinkers

I may be wrong here to say that nowadays developers fall mainly into two categories: the ones that love to be told what to build and the ones that love building software, but also have at heart the impact on the final users and business. I’ll call them the “product thinkers”.

**Product thinkers see technology as a means to an end, not the end itself.** They take joy in product discovery, suggesting improvements for new features or how to improve the existing ones. They weigh every technical choice against the impact on the user experience or on the business. They want to see their work being used by real people, see how they react and be happy to know that they’re making their life better or worst and act on it. They don’t go all-in in developing a feature, but they like to understand the why behind it. They like to have the big picture, and understand the domain within the product works, so they can make good decisions. They like to prototype, they like feedback. They are product thinkers!

**There’s nothing wrong with the “tell-me-what-to-do-type”.** Some people love the tools more than the problems they solve and that’s fine, but IMHO there’s so much potential wasted. They thrive in feature factories (someone creates requirements ⇒ developers build them without many questions asked), which are usually agencies, but also product companies.

The “product thinkers” find those places mind-numbing after a bit. That spirit that brought them into the industry is caged and trying to get out constantly kicks in, forced to be quiet by common beliefs (developers should only focus on code) and managers who don’t understand software development (a highly collaboratively set of activities aimed to make people’s lives better)

I have the feeling that product thinkers are a minority in the industry, or maybe they haven’t just gotten a chance to speak up and express what they think since it goes against the common belief about what a developer should be.

I don’t have a solution for that (but I have some ideas I’ll be exploring), if not writing about it in the hope to reach more people that feel the same. In my everyday job, I try to act as a product thinker as much as I can, asking questions, challenging assumptions, and caring about the impact of the work. It can be uncomfortable sometimes, but change is never comfortable.

Follow me on Twitter: [@peppesilletti](https://twitter.com/peppesilletti)

This article is for those software developers who dislike being treated as code monkeys. The ones that love to create products and see the impact of their work on the world (a.k.a. making a segment of the human population happier).

The Rise Of Product-Minded Software Developers


As a software engineer I've realise how important is having empathy for everyone involved in the process of developing software: business people, product people, designers, other developers and most importantly, the users of the product.

In the last month, I've had the pleasure to interview 8 non-technical business owners who have built, or are building a software product. Also, I had experience with helping 3 startups to create and/or grow their product.

I found many interesting insights, which I can group in the following categories:

 1. Challenges with developers
 2. Challenges with outsourcing
 3. Challenges with product management
 4. Challenges with scaling up teams
 5. Other challenges

### **Challenges with developers**

-   It can be frustrating to work with developers because they are generally stuck in their own ways and they are not very keen to change
-   Selfless developers who have a business mindset, who want to understand the why behind a feature, and are proactive, are the ones business owners love to work with
-   On the other hand, it is challenging to work with very technical developers who just want to get the specifications and develop them like without asking questions
-   The first hire is essential, it could make a difference between wasting tons of time and money in building low-quality software and having a robust, successful first version of the product
-   Communication with developers is a big issue:
    -   It isn’t easy to communicate exactly what you want, and that is often misunderstood
    -   It isn’t easy to communicate the vision of what you want to build
    -   Having a great written and spoken English definitely helps

### **Challenges with** **freelancers and agencies**

-   Freelancers are not always reliable and if they disappear, they take with them the core of the business, the most important asset: the software itself!
-   Working with agencies can be frustrating because you need to wait in line for features to be developed and bugs to be solved
-   No one is passioned about your idea as you are
-   If a customer is pissed off, and a problem needs to be fixed asap, that’s not their priority. Unless you’re willing to pay more!

### **Challenges with product management**

   - Biz owners usually act as product managers, giving directions to the in-house/outsourced team. It did work well with people with some knowledge in the field, but it didn’t for others who just improvised: one of them wasted 70k in building useless features, and 20%-30% of the feature built. Another one spent 2 years developing a product, just to find out that no one wanted to use it afterward
-   Some biz owners believe that talking with users is a waste of time and that they have everything figured out

### **Challenges with bigger teams**

   - When the product is launched and the team grows, a lack of good software development culture slows things down, creates tension between the devs and the business, the devs and the users and the number of bugs / wrong features increases
-   It is beneficial to think about culture and processes from the beginning, not when the company has already multiple teams

### **Other**

   - Some biz owners love no-code, they would rather start with that and only if necessary hire a developer
-   Biz owners never worry about internal software quality, but they just accept that “it works”
-   Some biz owners understate to effort it takes to build features right and that always came with more time/money spent than initially planned

Follow me on Twitter: [@peppesilletti](https://twitter.com/peppesilletti)

In the last month, I’ve had the pleasure to interview 8 non-technical founders who have built or are building a SaaS product. Also, I had experience helping 3 startups to create and/or grow their product.

Software development

User-Driven Development (my take on Test Driven Development)

The Rise Of Product-Minded Software Developers

The challenges of building SaaS for non-technical founders