The number one feature of any application is the best possible user experience. This applies to any app, such as for Windows, MAC, mobile, web, and even web API's. No matter what type of user will be using the code that you wrote, it’s your responsibility to make them happy and the way to do that is to make their work or life better. This is how you get and retain users which usually means more revenue and you get to keep your job!
The Best Programming Course I Attended
Way, way back when I was learning how to be a software engineer, I attended courses at a local community college here in San Diego, California. I’m pretty sure, I have only ever taken two programming classes. The first was one about the Pascal programming language, where I spent most of my time helping others in the class on their projects. The second was the best one and I still use what I learned in that class to this day. That class was called “System Design and Analysis”. This class, where we did not write any code, was just on designing applications. Everything we did was on paper and the class project was designing an application for a fictitious fitness gym. I took this class while I was working two jobs and had two small children at home!
The class taught me how to design an app from scratch that included gathering requirements from users and then designing (paper) prototypes of the screens for the app. We worked in teams of three to four people and our final grade was our team presenting to the users (students and teacher in this case) the application we designed to land the contract. I had our team dress in suits and dresses and we even brought food! After my team's presentation, we received the grade of A++, which I didn’t even know existed! I guess we would have won the contract.
I believe that knowing how to architect a solution (app) from scratch is the number one skill that any software engineer needs if they want to be a professional. Otherwise, you will just be a coder that bangs on the keyboard all day from a design someone else did who got paid a lot more than you!
Unfortunately, I see less and less of this type of work being done these days, before the engineers start coding the app, which will lead to worse user experiences. Some of what I think the issue is the improper way many teams implement Agile, high demand for implementing features and bug fixes faster, development cost, and more. I say many, many times that coding should be where you spend the least amount of time delivering an app.
For the rest of this article, I will give examples of how I used this class throughout my career.
Ticketing System for a Movie Cinema
The first time I remember using what I learned in that class was at a very small company (5 people) where I was hired to write a ticketing system for Edwards Cinemas here in the United States. Even though this was early in my career, I was hired as the lead developer. When I was writing the app, I took direction from the company owner on the design. I asked him over and over to send me to one of the local Edwards locations so I can watch the system they use now and ask questions. He kept refusing, telling me that he knows what they want.
Once I had a working prototype, I pestered him again to let me go to one of the cinemas. He finally gave in and let me go to one for about four hours. So, I took our system to the cinema and set up the computer screen next to the person taking the money and handing out the tickets. I would mimic what she was doing on the system I wrote to make sure they would like it and make their job easier.
During the lulls in the sales, I would talk to her about what she likes and dislike about the system she was currently using along with other questions about reporting and more. What I found through this experience, was that the company owner was very wrong about what the users wanted. This caused a lot of re-work once I got back to the office.
This experience taught me that if I want to write the best user experience for the users of the app, I need to talk to them and learn their current workflow so I can make it better. This became so important to me that at the next company I worked, I asked the CEO (at a company meeting) if I could go spend a day with the people that will use the app and he also refused. That was the day I started looking for a new job. Not long after I left, the company was closed forever. The bank came and chained the doors so the employees could not enter.
Mitchell International
As I stated at the beginning of this article, thinking about your users also applies to projects like web-based API’s too. Over 10 years ago, I started a Principal Software Engineer position (the highest level they had) at Mitchell International after the person that became my boss took one of my classes at the University of California San Diego and kept pestering me to work there. Mitchell develops software used by the automotive industry to manage collision and medical claims, parts and labor estimates, and glass replacement quotes. I specifically worked on their product called
RepairCenter.
The major feature that I worked on after version 1.0 was to architect and code a way for our partners to add custom apps into RepairCenter and a web API so that they could retrieve and update data in our backend system. Let me discuss the API, which was most of the work for this feature.
Our largest partner, who owned over 300 repair shops in the United States and Canada, wanted direct access to our SQL Server databases. We said NO for two reasons. The first was security. We didn’t want anyone but ourselves to have access to our databases. I even didn’t have access to our production servers! The second was we were so embarrassed on how bad our database was designed, and I knew it wouldn’t be easy for anyone to understand. Heck, it was difficult for me to understand! Why was it so bad? It was designed by the original developer who later sold the application to Mitchell. About every bad database design I have seen is from software developers! For example, if someone updated vehicle information, it had to be updated in multiple tables since much of the data was duplicated (I have no idea why). Every new developer into the team got burned by this when they would fix a bug and QA would come back and say it was fixed in one part of the app but not others. It was due to duplicated data. It took about three years of me begging Mitchell to let me hire a database business analyst.
I didn’t want our partners to deal with the same pain that we did, so my number one goal was to “cover-up” that bad design. So, I set out on the road to figure this out. First, I needed to understand the database better, so I spent a lot of time with that original developer since nothing was documented. I would create
UML models and kept going back and forth with him (he lived in New Mexico) until I got it right and I felt it was easy for just about any developer to understand. This process took the better part of three months. Taking time to design a solution takes time which always leads to a better outcome in my experience. If you don’t, you will be coding the same thing over and over or just putting on band-aids to cover up the bad design until you lose all your customers.
For the first version of the API, I spent a lot of time talking to our biggest partner and their developers about what they need since they would be the first users of the API.
Again, it’s my job to deliver something easy for them to understand, use, and would fulfill their data needs. The other most important thing I worked on, besides the design, was documentation! I created very detailed and easy to understand documentation and illustrations that Mitchell still has on their website today. Unfortunately, in the past 10 years, I haven’t seen documentation for projects like this get better. I feel it’s much worse if it even exists at all.
I also created a reusable Microsoft .NET assembly to make coding easier, in .NET at least. In this assembly were all the proxy classes (models), methods to call the API, and more. I did all the hard work and all they had to do was add it as a reference, set a few configuration values and they could immediately start calling the API! Can’t get simpler than that. I first created the assembly for myself to make it easier to write a custom app to test and benchmark the API endpoints. Later it was used in the actual RepairCenter product.
This project was also very successful. When I left the company, we were live or in testing with 40 partners and we were testing our first partners that Mitchell was going to start making 1% of each sale that came from their apps! The API was free to partners except for that profit sharing. I’d like to state that the biggest reason this project was successful was from what I learned at the class I took, and I spent a lot of time in the design phase before I wrote a single line of code.
Part Two
Well, there you have two real-world stories on how that one college class on application design has dramatically helped my programming career. But I haven’t told you the best story that even made me a patented inventor which I am saving for
part two of this article. Also, in part two, I will give you some recommendations on how you can get real-world experience in designing solutions that I hope you will use for the rest of your career as a software developer!
Do you have any comments so far? Please make them in the comments section below.
David MccarterPosted May 21, 2020, 1:50 PM
Part 2 is almost ready!