Quickly Learning The Business Rules
Podcast: Play in new window | Download (52.6MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
Unless you are the first software developer hired at a company, you’re going to have to quickly get your head around the rules of the software that you are building. While many industries are deceptively simple, you’ll usually find that there is a huge amount of complexity involved in any large scale software system. There’s a reason that such systems are complex – if they were simple, they probably wouldn’t be getting automated in the first place. Even worse, a lot of assumptions and rules in a particular industry are somewhat hidden and it may take a while to learn about them.
While you can learn the business rules in a particular industry over time by osmosis, that can often mean that it takes months or even years for you to be providing value at the same level as the more senior members of the team. Such an approach is risky – if you aren’t providing value in excess of your salary, you could easily be let go if the business takes a turn for the worse.
With experience you eventually learn that there are places to look, both in the codebase and in the business itself that can make your learning faster. We’ve organized this episode based around questions you can ask during your first few months at a new job to get exposure to your application’s business rules. These questions will also help you learn more if you’ve been at the same position for a while and still don’t feel like you understand everything that is going on.
Much of the time, you can learn the right things by asking the right questions and then digging deeper into the answers you get. While you can learn things the hard, slow way, if you can learn quickly, you often end up at a substantial advantage for doing so. Truly good programmers tend to be at least partial product managers, as they need to have a deep understanding of what they are automating and why in order to be effective. If you can learn the business rules of the software you are writing and do it quickly enough, you’ll make a great impression at your new job.
Episode Breakdown
What parts of the system are the most brittle and bug-prone?
There are several reasons this is a good way to learn about business logic. Bug-riddled parts of the system that have been bug-riddled for a while are usually that way because the organization is afraid to mess with it due to how critical it is. There is a minimum error rate in almost any codebase. The code where the most errors surface is most likely the code that is used most often. If errors are surfacing frequently in a particular part of the code, that also means effort was taken to log these errors.
Basically, the idea here is to look at the frequency of errors as a way to find important parts of the codebase. This also has the benefit of allowing you to become familiar with these critical parts of the codebase quickly, which makes it easier to justify working on them. This helps you learn more quickly. You should also take a look at which parts of the codebase are calling this portion of the code and which portions of the code are being called by this code, as these will often be pretty important as well.
Where does this system integrate with other systems?
Every piece of software out there is based around some mental model of how things are done. However, no two models of reality are exactly the same. The places where they differ are where interesting discussions happen. Integration points are a great place to compare mental models because you can actually see in the code where one model is converted to another.
In addition, the integration points in a system also show you the “edges” of the system. If something is not done by a system, it’s likely that the task will be offloaded to another system. It’s as valuable to know what is out of scope for your system as it is to know what is in scope. Sometimes intentional decisions were made to not include certain functionality in a system – finding the edges will often show you where that has occurred.
If we have competitors, how do we onboard their customers into our product?
Another good place to look is the process by which customers of other products are on-boarded into your product. To some degree, onboarding is a one-time integration process. Pay particular attention to areas where manual work is required in the onboarding process, as these tend to indicate things that are difficult to automate.
Pay attention to the data transformations. When looking through the onboarding process and trying to understand a system, pay special attention to how data is transformed. Onboarding data processes tend to be far less abstracted than those used in the normal development of a system and are often built by people with deep knowledge of the system.
What exports does our system have? What data does it need to export on a regular basis for use in other systems?
Along the same lines as the integration points on onboarding systems, it’s worthwhile to look at places where large amounts of data leave the system. Large data exports are often in the mix when a system has to integrate with older systems. This data is often some of the most important data in the system. If exports are happening on a regular basis, pay special attention to the timing of the exports.
Older external systems often frequently include governmental systems or systems of very large, old companies. Pay attention to what is being sent out and especially to what data is being filtered out. Sometimes the data in these exports will be the same data considered critical by the rest of the system, but sometimes it will vary. Pay special attention to any variance.
Where is the most sensitive data in the system and why is it sensitive?
Data is not an asset from a security perspective. It’s a liability. If your software is collecting and keeping sensitive data, there is a reason for it. Because of the nuisance of having to protect this data, it’s not usually done lightly. This can be anything from PCI data to HIPAA data, to sensitive personal financial information.
Pay careful attention to places where this data is accessed or changed. Access of sensitive data tends to be in processes that are system-critical, with most other processes remaining ignorant of the data (hopefully…). You’ll also usually find that there are interesting business rules around changes to this data. Pay close attention to anything that is triggered on a change, such as updates to other tables or systems. Also learn what regulatory requirements your system has, as those tend to be reflected in business logic decisions.
What areas of the system see the most traffic or load?
Asking this question will let you know what parts of the system are most valuable to the users. Sometimes this is different that what you might think looking at the product. This is especially true of more complex software packages that serve large numbers of people in vastly different circumstances.
Read load vs. Write load. Along the same lines, it’s valuable to determine whether the “read” side of your application receives more traffic than the “write” side. While it’s certainly more common for applications to be more read-heavy, a lot of your default assumptions may change if you find that writes happen more frequently or end up involving a lot more data. On the read side, caching rules are useful for knowing what is important, while understanding larger out-of-band processes is important on the write side.
What are the most performance critical tables in the database?
Along the same lines, you’ll probably have certain database tables that are very heavily involved in most system interactions. “hot” database tables tend to have some of the most important (or at least pivotal) data in the system. If optimizations have been made in the past to avoid overloading these tables, find out what they are. These often point to some of the more squirrelly spots in the application logic that you need to be aware of.
There are also some other signs that you’ll see that can indicate that a database table is extremely critical. Lots of indexes tend to indicate that the data is frequently searched in a variety of ways. A strong lack of indexes on a big table can often indicate that insert/update performance is critical for some part of the system. Large numbers of foreign keys to other tables can also underscore the importance of a particular table. Also tables with high number of rows or columns are usually worth looking at. There is a reason to store that much data, or a huge number of rows.
What language is being used when marketing this product to prospective clients?
When the software is being sold to a potential client, the way that the sales team describes it can often point towards the most important features of the software for the buyer. Note that this is different than the most important features as understood by the user. The buyer has a different set of objectives. Most software is purchased by people who only use a small sliver of the functionality in the software and often represents only a tiny slice of the load on the application. However, it is the most important group of users, because they won’t buy (or keep buying) if they aren’t kept happy.
The real question here is, what do the managers of your users want from the software. Look into the reporting and audit trail requirements for the application, as those tend to show what management is looking for. Also look into the type of questions that are asked of managers during user onboarding, as those tend to point toward what system roles are available for users and what those roles mean.
What is the main competitive market advantage of this product compared to its competitors and what is their main advantage?
Asking this question will tell you why your company’s clients use this software instead of a competitor’s software. This will tend to include a list of features that your software has that the competitor’s software does not. It will also show you where your application simply works better than a competitor. If those areas are important enough to change buying behavior, you should find out why.
Pay particular attention to any sales and marketing pages on your company’s website. Not only will this help you understand the vocabulary being in your system (sometimes the way your company uses a word isn’t the way English does it.) Also pay attention to the application features at each pricing level (if you can see it on the site). This will alert you to feature flags for paid features and their relative value.
What are the worst consequences of a system outage to a client?
Another approach you can take is to ask people at the company what happens to clients when the software is down. This could be anything from being a minor inconvenience to being a major problem that stops them from doing business. The consequences that occur along with an outage will tend to inform your application’s approach to errors (which is effectively another set of business rules).
When you are learning about this, it’s also a good idea to ask about SLAs (Service-level agreements) both for your app and any services on which it depends, as well as the procedures for outage windows. SLAs indicate how quickly your app needs to be back up after an outage. When looking at dependent services, it’s often informative to compare the SLAs with your own. If their SLA is over a longer period, this tends to indicate out of band processing that isn’t time sensitive. Looking at outage windows will tell you how frequently updates and major maintenance are expected to occur both for your app and anything it depends upon. Development practices change drastically if no downtime for maintenance is expected, as this tends to mean updates are applied hot.
Book Club
The Healthy Programmer: Get Fit, Feel Better, and Keep Coding
Joe Kutner
Chapter 4 dives into Agile Dieting. Kutner starts off with a story about being on the high school wrestling team and how he developed terrible eating habits to maintain a certain weight. He compares the pressures of being on the wrestling team with the pressures we face as programmers that lead us to make poor eating choices. The first section is called “An Iterative Approach to Dieting”. In it he starts off by pointing out that most fad diets only work by tricking you into eating fewer calories. As the only real way to lose weight is to expend more calories than you take in. He talks about trying different diets for two week sprints to find the one that works for you. He says to start off with the intention of failing at the diet then as you learn what works sticking with them longer. His next section is about balanced nutrition vs unbalanced idiosyncratic diets. He lists out the recommended daily percentages of different food groups. Then states that most fad diets do not meet these percentages which is why he suggests rotating through the different diets. In the section “Eating Your Brains Out”, he discusses desire and cravings. He says the next time you want a snack try solving a puzzle. If you are still craving the snack after the brain work you likely need food. He even provides a flow chart for conscious eating. In the next two sections he talks about counting calories and adjusting your intake. At first he has you calculate your base metabolic rate, then add to that based on activity. That gives you how many calories you are burning each day. Then he goes into caloric intake. Finally he talks about how your individual tastes are more important than diet specific menus. A few tips he gives for planning a healthy diet include: Eat foods that satisfy you. Schedule your eating. Make a list of off-limit foods. Rehearse your diet.
Tricks of the Trade
Line yourself up with the production of business value. Don’t ever work somewhere where you don’t understand the value that the business provides, how it makes money, and how its customers make/save money from your product. There are places where being dumb is survivable – this is not one of them.