People Over Software

As a developer do you ever feel like you’re just advocating for technology for technology’s sake without ever producing anything that makes society better?

Have you ever used a piece of software and realized that it was a terrible user experience. Are you a programmer who has a terrible developer experience?

There something seriously wrong with just building software as a means of job security without ever evaluating the goodness it does in society. How do you measure the benefit of software to society? Anyone can read The Daily WTF and easily conclude how everyday technical decisions made by developers produced insane results at the cost of dollars, I’m sure. It bothers me that we’re spending a lot of time and energy on software that ultimately frustrates users and leaves them with a negative picture of the promise of technology. I feel what can make me a more valuable developer is understanding this issue to make better informed decisions about my users. I wish more companies spent more time educating their developers rather than slaving them to fix bugs and comply with urgent requests.

In my experience, bad developer experience results in bad user experience even if the developer has no say in the product (this often indicates the product or management team doesn’t know what a good customer experience is). Does this mean there are a ton of developers who genuinely want to produce good software but are limited by poor teams or are developers addicted to technology stacks and acronyms and fail to see how their decisions affect user experience?

Are raw materials like wood more favored by people than bits? People refer paperback books to digital books because they include more senses (touch, smell). You can’t touch or smell digital products (yet). However, when it comes to efficiency, why are we still a cash society for the most part. There are still pockets of society where digital payments aren’t encouraged. Is this because the software and/or hardware isn’t people-friendly or that people just aren’t software literate?

Ask yourself what software has made my life easier better more fruitful and what about that software is the cause and how as a developer can I learn from that and reproduce the same end result? Working software is useless without working people, a technological illiterate society cannot benefit from software with poor user experience. A poor user experience is where any friction is encountered between trying a achieve a promised outcome. The ultimate outcome of any software is to connect humans. Measure what this software is promising and whether people are achieving this outcome as expected. This is software quality that matters.

Real career goals as a developer are not to prove wherever Angular is better than React but whether your philosophy of making lives easier should pair with that of the company you work for. Educate yourself on how to improve both your developer and customer experience. Constantly enlighten yourself and perhaps you may end up working with a team that sees software as a means to improve efficiency and happiness, instead of encouraging bad behavior and poor user experience. This is certainly one of my long term career goals.

At the end of the day I hope we can all develop a common conviction as developers with the ability to change how our customers and stakeholders view software, not as a means to force technology but a super power to connect people for people’s sake, so that people become the greatest asset not technology stacks.


Development Thoughts of the Day

Software Quality: There are known software quality attributes such as performance and maintainability but good software quality is really achieved not by adding more features but removing just enough features. Since quality is ultimately measured by the user experience, what matter is how easy it is for the user to accomplish a task.

When all you have is a hammer, everything can be hammered down. But not every problem needs to be solved with a hammer. That’s why it’s important to understand how different languages solve problems differently. To learn a new ways of reasoning about software, learn new programming languages with different styles like functional, and dynamically typed languages such as Javascript.

JavaScript is an excellent language to learn new ways of thinking, building and deploying software. The concept of the Single Page Application has even made blazing fast enterprise applications running purely within the browser a possibility. However, it requires a lot more discipline than other languages because it’s easy to shoot yourself in the foot due to so many dangerous and unpredictable language idioms. Running javascript through a transpiler like Typescript is highly recommended to improve code quality. Typescript added strong typing at compile time and introduces ES6-like class syntax which allows for a mix of object oriented and functional programming


I first heard about the word Tactegic from this blog post. Without focus, lots of little tactical successes can breed strategic defeat. When it comes to programming, the word hacking seems related to this idea. When you’re hacking away, you’re usually taking as many shortcuts as you can, and fumbling your way towards some kind of ad-hoc fix. Hacking can be good with a degree of focus and strategy. In fact, some hacks may lead to actual products in the end. One possible benefit of hacking is doing away with over-engineering and over-design, however, one should eventually step back and be critical about ones own work.

Quick Reads on the Web

  • On Agile: I overheard someone say once that Agile is just a series of small waterfalls. Here is a PDF of software methods used over history starting from 1960. See any patterns?
  • IEEE Software: “Fundamental Facts about Software Engineering“, this short article is about people and complexity and how estimation is often premature.
    • “The most important factor in attacking complexity is not the tools and techniques that programmers use but rather the quality of the programmers themselves.”
    • “Quality is not the same as satisfying users, meeting requirements, or meeting cost and schedule targets. However, all these things have an interesting relationship: User satisfaction = quality product + meets requirements + delivered when needed + appropriate cost. Trying to improve one quality attribute often degrades another. For example, attempts to improve efficiency often degrade modifiability”
  • Javascript: Understand what promise chain composition really is and how to do it effectively without nesting them in loops. Also checkout promise anti-patterns.

For not quick reads, there are a ton of amazing, time tested Kindle books by Weinberg here: that are worth checking out.

Solving Complex Business Problems

I was once asked during an interview to sketch how I would write an algorithm to solve a puzzle game like Sodoku or Boggle. To be honest, it was difficult simply because I did not have a keyboard in front of me to work the solution out incrementally.

I’ve heard of developers working around such challenging interview questions by instead writing what the tests for the answer would look like instead of writing the answer itself.

For a web developer, understanding algorithms, and especially np-complete style problems may seem unrelated to wiring up an MVC app, however they are core to almost all industries. Industries that specifically deal with supply and demand require dynamic programming/optimization routines.

Going from web development to writing discreet optimization algorithms is definitely a big leap, especially when one considers the fact that those algorithms may not always be written in managed code, but instead SQL. So, one has to determine the problem, break it down and optimize it, then figure out how to accomplish it in the database or business programming language of choice. It’s no easy feat.

Fortunately, Microsoft provides a great business intelligence suite of products for doing OLAP number crunching.

There are numerous resources on the topic and I encourage all developers to familiarize themselves with optimization. A great place to start would be to write a program to solve the age old “Chutes and Ladders” game. Another well known case is the Knapsack problem.

On the Phoenix Project

I recently finished reading “The Phoenix Project“. As a senior software developer, reading this book has provided greater insight as to the inner workings of an IT department’s interaction with business.

Some of lines and developer jokes from the book:

  • “CIO stands for ‘Career Is Over.'”
  • “if your colleague tells you they’ve decided to quit, it was voluntary. But when someone else tells you they’ve decided to quit, it was mandatory.”
  • “If I fail, I’ll try to make sure it’s in a new and novel way.”
  • “for IT to keep the lights on. It should be like using the toilet. I use the toilet and, hell, I don’t ever worry about it not working.”
  • “Developers are even worse than networking people. Show me a developer who isn’t crashing production systems, and I’ll show you one who can’t fog a mirror. Or more likely, is on vacation.”
  • “We need to establish an accurate timeline of relevant events. And so far, we’re basing everything on hearsay.”
  • “A developer jamming in an urgent change so he could go on vacation”
  • “Situations like this only reinforce my deep suspicion of developers: they’re often carelessly breaking things and then disappearing, leaving Operations to clean up the mess.”
  • “The only thing more dangerous than a developer is a developer conspiring with Security. The two working together gives us means, motive, and opportunity.”
  • “You’ve probably heard of them: the Theory of Constraints, Lean production or the Toyota Production System, and Total Quality Management. Although each movement started in different places, they all agree on one thing: WIP [Work in Progress] is the silent killer.”
  • “Creating that predictability is what I’m most intent on instilling in my IT Operations group.”
  • “Despite all that work, I wish I could have done more to prepare. I force myself to relax, visualizing having a healthy and vigorous business discussion with him, walking out with everything I ask for.”
  • “We need to focus on the riskiest changes,” I continue. “The 80/20 rule likely applies here: Twenty percent of the changes pose eighty percent of the risk.”
  • “I’m concerned that we no longer have sufficient version control—we’ve gotten so sloppy about keeping track of version numbers of the entire release. Each time they fix something, they’re usually breaking something else. So, they’re sending single files over instead of the entire package.”
  • “there’s a huge memory leak, and that’s even without any users on it. My guys suspect we’re going to have to reboot a bunch of the servers every couple of hours just to keep it from blowing up. Damned developers…”
  • “Here’s the most amazing part: We made a huge investment in virtualization, which was supposed to save us from things like this. But, when Development couldn’t fix the performance problems, they blamed the virtualization. So we had to move everything back onto physical servers!”
  • “Phoenix website is leaking customer credit card numbers. They’re even posting screenshots. Apparently, when you empty your shopping cart, the session crashes and displays the credit card number of the last successful order.”
  • “I’ve been in software development for virtually my entire career. I’m used to everyone demanding miracles, expecting the impossible, people changing requirements at the last minute, but, after living through this latest nightmare project, I wonder if it might be time for a change…”
  • “I used to love this work, but it’s gotten so much more difficult over the last ten years. Technology keeps changing faster and faster, and it’s nearly impossible to keep up anymore.”
  • “Just how many times can you throw out everything you know to keep up with the latest new-fangled trend? I look in the mirror every once in awhile, asking myself, ‘Will this be the year that I give up? Will I spend the rest of my career doing COBOL maintenance or become just another has-been middle manager?”
  • “Yes! I see it now! It really is unplanned work! The fourth category of work is unplanned work!…unplanned work is recovery work, which almost always takes you away from your goals. That’s why it’s so important to know where your unplanned work is coming from.”
  • “Chester, your peer in Development, is spending all his cycles on features, instead of stability, security, scalability, manageability, operability, continuity, and all those other beautiful ’itties.”
  • “Solving any complex business problem requires teamwork, and teamwork requires trust. Lencioni teaches that showing vulnerability helps create a foundation for that.”
  • “Erik’s First Way. He’s talking about systems thinking, always confirming that the entire organization achieves its goal, not just one part of it.”
  • “Get humans out of the deployment business.”
  • “‘code commit.’ If I could wave this magic wand, I would change this step. Instead of getting source code or compiled code from Dev through source control, I want packaged code that’s ready to be deployed.”
  • “Messiahs are good, but scripture is better.”

Yes, this book rails on developers, but also managers and everyone in between. In conclusion, when faced with challenges like dealing with raging managers, tight project deadlines, or just stressful situations at work, the right way to react is always to communicate the right information across so that you come across as having a solution that brings results, instead of producing outburts of anger or other passive aggressive emotion. There are emotions, but they should be redirected. Frustration becomes desire, worry to concern and alarmed to curious.