> 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. I don't advocate "Fear-Driven Development" but this tweet is both funny and true on some level:

"Write code as if the next maintainer is a vicious psychopath who knows where you live."
— Jack Franklin (@Jack_Franklin) December 4, 2012

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.
> ~ 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**." --- 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)