Something that I have noticed, customers can drive the software's design quite easily. I don't work in the product department, but I am the developer who implements the ideas. This is my take from being asked to implement these new decision with the knowledge it's coming straight from the customer.
I have worked on several products with various teams sizes, and the customer usually has some direct input at some point. It's usually into the design, or the idea for the some functionality to be added, or replaced. I'm not sure why it is, but these are my ideas:
We think the customer is the domain expert.
If we don't implement it, we will upset them.
We do not want the customer to leave.
It is easier to source ideas from them.
Big opportunities could be had with just one more tweak.
This is a short list of ideas why, but it's obviously more complex than that. I don't think customers have the best ideas for software. They can be the domain expert for what the software helps provide assistance to, but they are not the software experts. Customer feedback is import. It does not require action.
When customer's suggestion, and feedback is prioritized, I have notice it gets near immediate action. This wasn't because the backlog of tasks are empty, but because it gets expedited. To remedy this, I would create a backlog for customer requests. Let that new backlog collect for awhile. Improve your software, and drive it in the direct it needs to go. We are the software domain experts.
I don't know if there is any software that is perfect so give yourself the opportunity to fix, or replace the parts that need it. These fixes will help software maintainability, and open the door to add new functionality to the software. This could be a good time to consider the customer feedback into your new design, if it make sense. Once you're done, the team will feel the improvements working on the software, and customers will notice too.
Lets make conscious decisions about our software by not being reactive to feedback, or relying on it for direction. Customers are relying on us for good software. Plus we don't want our software to be an endless feature treadmill. The final product will be a reflection of our thoughtfulness so we must build the best product with the limited resources we have.
Over my career, I have worked at several software companies and some software departments. Some companies sell their software directly, other companies make money other ways, but require custom solutions. One thing that is common, the managers of the software teams don't know the software or how to use it. I found this odd because the whole teams existence revolves around that software. Luckily for me, one of those jobs did not work that way. I had a boss who was part of the team and helped build the software we worked on. He showed me that managers can participate in the software development process.
This was a small company with 30 to 50 total employees. The software development team had to be between a dozen or two dozen people. Before I joined they decided to rewrite the product for some valid reasons. This meant I was joining a greenfield project. It was fresh start for design and code. My boss was also the architect. People wore many hats at this small company. The boss started the project with his expertise. Then he let the developer take on the big futures needed to replace older products. He did not just sit back and manage after that. He took on tasks, and fix bugs and worked with other teams. You could see the application running on his computer screen. He was just as involved as us.
One of my favorite examples of this was when our user facing UI was becoming inconsistent across all the screens. That is what happens when you got multiple developers building out new features at the same time. The boss did something clever. He took a screenshot of all the screens. Then printed them all, and then began posting them on the wall. He caught everyone's attention. When he was done, he was able to explain by showing everyone the inconsistency. With some effort from the team, the UI became more consistent after that.
Another example of being a manager by doing. There was an issues in production that took down a server. The boss knew the team was busy building the new release so he took it on. It was a customer uploading an CSV much larger than we expected. For this customers, large CSV files were common. He took the task on to fix it by refactoring the code to stream the file instead of load it into memory. It was really cool to see the final solution. I was impressed and learned something new.
Looking back at this, I'm glad I got to experience it. The best part about was, you got a manager who knows and is working with you. When you talk about the product, you don't get any confused looks when you mention a fact about the software beyond the basics. You get relatable advice and guidance they direct you to specific code examples. They also know which parts of the software are the hardest. They have a better idea of estimates and effort required. Most importantly they are able to understand and relate to your work.
I cannot say the same for other places. I have had manager just drop me off at my desk and not see them until it's review time. When there is an issue, usually I just get routed to another team member. I could have done that myself. Compared to my experience at a retail store when I was much younger, managers did not do this. Maybe it's the office and it's effect on work. Who knows.
Moral of my story, be a team player and get in there. Know how to use your product. Know your code. Feel the pain everyone else has. You might have fun and you'll gain some big respect.
Starting this series called: Just for Fun. It's inspired by the book Just for Fun: The Story of an Accidental Revolutionary by Linus Torvalds and David Diamond. I'm on my second read of the book. With this series I will describe what I am working on for fun.
The fun project is a resume builder. Here is how the idea started. A couple of years ago, I was ready to look for the next job. I couldn't find my resume at first. I was afraid I wiped it off my hard drive when changing my operating system from Windows to Linux. I ended up finding it, but it was a Microsoft Word file. It should have just been wiped off the disk. Since working with Microsoft Word was such a pain, and I am decent at HTML and CSS, I decided to build a resume that way. I ended up learning Tailwind CSS and made a nice looking resume in the browser.
After landing the next job, I had an idea to make an app to build resumes. This way I wouldn't be worried about losing my resume, it will look good, and easy to update. I set off to make this web app. You punch in your resume data and on the screen a virtual piece of paper in the browser updates as you type. It is pretty slick.
I started running into issues with a specific amount of data. It was resumes with multiple pages. Depending on the information in the resume, a second or third page becomes hard to render. I gave it many attempts to figure out but all the coded ended up being a big ball of spaghetti. I attempted with React, ELM, and Angular. I was pushing the code and I could feel it pushing back with no ideal solution that felt right.
Screenshot of the Angular app displaying a resume
The problem was with the HTML DOM. It is not an ideal way for trying to render the dimensions of paper as HTML. The height of a DIV cannot be calculated until it is rendered by the browser. This requires having call backs on the resize event for all the DOM elements representing the virtual paper in the HTML. After the call back, you have update the model data with the calculated height that was rendered. Yuck!
One day it just hit me. Why don't I just build it as a desktop application. They render graphics so they can render my virtual resume. I ended up using Scala as my programming language since I use that for my day job. I paired it with JavaFX as the desktop application framework. This concept also solved some other issues I had which were not related to the rendering of the resume. I started on this adventure.
The biggest leap forward was when I started learning about typography and learning how to calculate the resume design with a layout grid. I was able to calculate the height of all the elements for the resume before rendering. This removed the callback hell from resize events in previous projects. I also decided to start smaller and just render some boxes of alternating colors instead of text. This allowed my to prove that my idea was possible with less complexity. I was able to render several pages with the elements moving to the next page when there was no more space. It was exciting!
Video of the JavaFX app displaying multiple pages with alternating rectangular boxes
This project has taken me all over the place. It has inspired me to learn so many languages and frameworks. It's also opened up the world of typography to me. I have currently started to learn Clojure and LISP. I stumbled upon a video about it and was sold on it's powerful REPL. We will see if my next update has some Clojure in and what fun it may bring.
To give this post some back story. For my day job, I work for software companies. Over the years, team members have moved on and new team members have joined. When we talk about the software and perform our software planning tasks, there tends to be a lot of assumptions. This is something I have been noticing over the years.
You know what they say when you assume: "You might make an 'ass' out of 'u' and 'me'". When it comes to software planning and assumptions I will say "You are probably wrong". Of course this is contextual to the software and the team working on it. The older the software and the less experience the team, the more assumptions will be incorrect. I have found it is best to avoid assumptions in software planning. When you know something it's fact, but when you don't know, you tend to assume.
A lot of this is the nature of software and it's complexity. The more complex the software, the more it plays a role in the assumptions of how it works, instead of knowing. Complexity could be on the code level which only the programmers have to navigate. Software complexity can be a user level with an overwhelming amount of features bolted into the product. Assumptions grow from complexity and the uncertainty of how it works.
History or a lack of, can also be a source of assumptions. It is easy to blame the past for a reason today. The lack of history can lead to a lot of questions and confusion. What was easy in the past might not be today and vice-versa. Having documented software history is better than having none at all. It's best to not rely on historical metrics for tomorrows goals.
To prevent making assumptions in software planning, we can investigate, test and document. It's easy to make assumptions how the software will work. It may have worked that way in the past or other parts of the software work that way, but those are assumptions. To turn our assumptions to facts, we need to investigate and test. This means we need to read or use the software to prove that our assumed idea is true. Once we have verified our assumptions it will be a good idea to lightly document that understanding.
So when it comes to software planning do not base it off of assumptions. Either bring facts to the planning table or create some tasks to investigate any assumptions. This understanding will improve everyone's knowledge of the software on the team while also keeping plans based on facts. It's no fun for anyone when a project starts and assumptions are wrong and you have to start over.
My recent personal software projects have two main focuses: building for myself, and having fun. I have other obligations in life which do not allow me to spend all day on my projects. When I focus on these two objectives, it maximizes the joy I get out of coding in my spare time. The added benefit is I get a working product that I can use when I am done. There were some realizations along the way. I got constraints.
I have a day job that takes up a large part of my day.
I have a household which I am part of.
I am a team of one.
No plans for outside money or funding.
Not looking for external expenses such as hosting and other services.
To many interests and ideas.
Since I am building for myself, I am on a relaxed schedule. I still want a working deliverables and not be wasting my own money. Most modern practices software would steer me towards building out big software with many layers. That's hard to do by yourself. My time is limited and I don't have that kind of budget.
After some time and thinking about it. Looking back was a good way for a solution. Desktop applications fit the bill. They are self contained so the code is generally in one spot. They can easily be designed for a single user. They don't require access the internet. The list goes on. But most importantly, it fits into my constraints and allows me to focus on building software for myself and having fun doing it.
With desktop applications, I don't have to rent some dedicated server or setup a computer at home to act as a server. This takes a lot of maintenance and upkeep cost off the table. Less setting up servers and then forgetting; more time designing a solution. This checks the boxes for the constraints to respect the limited time and limited expenses.
As for having to many ideas and interests. Some can be combined with the on going project, while other just get added to a journal I carry around. I try to focuses on one project at a time. I pick the project to work on by the idea that solves my biggest pain points in life.
It's has taken some trail and error to discover my constraints. Once I understood them and applied some thought to it, new alternative paths appeared. I feel like I was able to find some additional joy and fun in my software projects in the process. Find your constraints, embrace them and most importantly, have fun.
