content/posts/2016/2016-05-16-people-focused-software/index.md
---
title: "People oriented software"
cover: "https://picsum.photos/1600/800/?image=395"
date: 2016-05-16 23:11:32 +0200
category: "tech"
tags:
- Mindset
- Relationships
---
> The art of making software for people with people.
Today the words "people oriented software" materialized in my mind. It's not
a new (I Googled it) but it is new to me.
As a software developer I naturally felt obligated to write about code and
technical implementations. I didn't follow through on that. To me, writing code
is a small subset of software development.
We write software for a reason. What that reason is depends on the people who
will be using that software. I have a lot of fun writing code but I have more
fun making software with people for people.
There are interesting challenges that materialize when people start working
together. Especially so when there is a lot of
[unnecessary complicatedness](#side-note) in an
organizational structure. We all want different things for different reasons
with our own ideas, past experiences and understandings. Tackling these
challenges to make for better software, delivery and happier teams & users is
what I love thinking about. This is the crux of what I want to write about.
The people we make software with are the:
## User
We can argue about the best technologies and implementations to use then write
code everyday until we turn into code writing zombies. What is the point if
people don't like it or even worse, don't want to use it?
To me, truly understanding the significance of the problem being solved and
exactly who it is for is a fundamental part of creating software. I want to
relate on a social level and almost "feel" the impact it will have on the users.
## UX & Design
This step is often abstracted away from developers but lucky for me, we
all sit in the same room.
I like to know why decisions are made so that I can paint the bigger picture
in my mind. This communication is a two-way street of insight into the user,
the strategy, consistency throughout products and the technology.
## Developers
Writing code for a computer to understand is easy. Writing code for humans is
a challenge. Many [software craftsman](#software-craftsmanship) save the day with insights
to write clean, testable and maintainable code.
<small>I don't advocate "Fear-Driven Development" but this tweet is both funny and
true on some level:</small>
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">"Write code as if the next maintainer is a vicious psychopath who knows where you live."</p>— Jack Franklin (@Jack_Franklin) <a href="https://twitter.com/Jack_Franklin/status/275921461661822976">December 4, 2012</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
Regardless of the process, patterns and practices that we choose, we should not
forget what is important: writing code that can be understood and changed to
have a continuous delivery stream that produces value. How we do it is up to us
but we need to take responsibility and think ahead.
When you make a mistake, keep this in mind:
> Blame is not for failure, it is for failing to help or ask for help.<br/>
> ~ Jorgen Vig Knudstorp, The CEO of the Lego Group
## Testers
Testers take your work and rip it apart. They look for flaws, loopholes and
issues that may arise while a user is interacting with your software.
This is a good thing. For 8 years I didn't have a safety net. I know that I
am human and make mistakes. And I did.
I believe [communicating with testers](/blog/bonding-with-testers/)
is essential to understanding how something is tested and what could cause a
feature to fail in this verification step.
## Business
Business can be the entity, stakeholders, clients, customers and even our users.
Understanding the financial and strategic impact the software has on business
is important to me. It helps with the bigger picture.
Behind the term business are people we can talk to and engage with.
## My final thoughts
It's easy to get strung up in complicatedness that we fail to remember why we
started writing code in the first place.
By understanding what other people do and the decisions they make I have a
better understanding of the code I need to write and the impact it has on our
users. I never want to lose sight of my goal: **making software for people
with people** and having fun while doing so. To me, this is what people
oriented software is about.
### Side note:
Sometimes it's not easy to communicate and engage throughout the SDLC
due to certain organizational structures. Structures and rules
that govern such environments make for unnecessary complications,
clunky processes, bottlenecks, back-and-forth and disengaged employees.
This is a different challenge but if you want to see **Yves Morieux**
talk about simplifying this, check out his brilliant
[TED talk](https://www.ted.com/talks/yves_morieux_as_work_gets_more_complex_6_rules_to_simplify)
titled "**As work gets more complex, 6 rules to simplify**."
* * *
<a id="software-craftsmanship"></a>
Some technical resources for software craftsmanship:
- [Code Complete](http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670):
A Practical Handbook of Software Construction, Second Edition 2nd Edition
- The Robert C. Martin Clean Code Collection [Clean Code Collection](https://www.amazon.com/Robert-Martin-Clean-Code-Collection-ebook/dp/B00666M59G)
- [Clean Coder](http://blog.cleancoder.com/) - A blog by Robert C. Martin (Uncle Bob)