Posts Tagged ‘ Software Engineering

My Rules of Software Engineering

updated: 08/28/2014:

When I was teaching at UIUC, one of my assistants shared with us a list of rules that he had put together about how to thrive in the software engineering field. After teaching over 1000 students software engineering at the University of Illinois, and now working on a large project in the industry for a while, I’ve decided to revisit those rules and change them to fit the landscape as I see it.

Charlie’s Rules of Software Engineering (adopted from Mike Lynn’s rules)

  1. Quality code is portable, secure, easy to debug, and flexible enough to be used in ways that were never intended….plan accordingly.
    1. If this isn’t the case, then you’re probably not writing very good code.
    2. Or your code is too specific and should probably be generalized.
    3. Or you are trying to ensure job security, any intelligent manager will fire you.
      1. Your job is almost never as valuable to the company as you think it is. Keep this in mind. Constantly find ways to improve your worth to your boss.
  2. Kludges that we’ll fix in the next release never get fixed in the next release.
  3. If you don’t do it right this time, you (or some poor bastard that replaces you) will have to do it right later.
    1. It always costs more to do it later.
    2. You often forget how to fix it later
  4. You won’t have any more time in the schedule for the next release.
    1. You won’t have any more funding either.
    2. And you will probably forget about it
  5. Nothing is free, coupling might save you time now, but it will come at the cost of more time spent on the inevitable rewrite that coupling assures.
  6. Plan as if every programmer who will interact with your code is an idiot. Then you have the worst case taken care of. If they’re not idiots then it’ll just be that much easier to use.
  7. Comment your code as if you were going to have to pick it up and use it again in 15 years.
  8. Your code is not finished until you’ve tested it.
    1. Never assume the other guy tested his code.
    2. Never assume the test team will throughly test your code.
    3. You are the front line of the QA effort.
  9. Consistency is often more important than doing it the best way. A less than perfect coding practice that is done consistently the same way is usually better than solving the same problem in “better” ways differently each time.
    1. Don’t sacrifice maintainability and understandability in the name of the “optimal” solution
    2. Going with that, clever code is bad. Clever code means it is unclear, non-obvious, or otherwise obfuscated. The benefits almost never out weight the costs here.
  10. Try to design things so that likely coding mistakes can’t happen (e.g. don’t make the length field in a TLV include the size of the TLV header, or some jerk will not account for invalid lengths).
    1. On the rare occasions when they do, document accordingly.
  11. Debugging a piece of code is about twice as hard as writing that same code. If your code is as complex as you can manage, you’re no longer qualified to debug it.
    1. And you probably should find someone else to continue its development
    2. And maintenance
    3. And testing
  12. Time estimation is really hard…it will take longer than you think it will. Under promise and over deliver. (see rule 50)
    1. No really, even if you take this into account it will still take longer than that.
      1. Seriously…
  13. The majority of time spent on a project by developers will not be writing code, it is spent on tasks that programmers are not as good at like debugging, testing, truly understanding requirements, documenting, etc
  14. The night before its due is probably not the best time to start integrating your code in a large project.
  15. You have several options:
    1. Be amazing at your job and be an asshole
    2. Be amazing at your job and be political/nice.
    3. Be decent at your job and be political/nice.
    4. Being bad at your job and being nice will get you fired. (usually by the assholes that call you out)
    5. Being bad at your job and being an asshold will get you fired. (usually by everyone else that sees your BS)
    6. If you are amazing, it serves you best not to flaunt it, but rather let your work speak for itself.
  16. Several guys sitting around one screen trying to fix a bug is rarely productive. Share your ideas, bounce things off each other, then disperse and come up with the next solution. Sitting around watching one person work is a waste of time.
  17. White boards are around your office for a reason. Use them!
    1. If you don’t have one, ask for one.
  18. Anyone that repeatedly declares things impossible should find their way to your kill file.
  19. In programming, style is substance too. Consistent style improves code readability and makes the code more manageable in the future.
    1. Its less important that a project has the style you like than it is that a project have a consistent style that everyone uses.
    2. Don’t nitpick on minor style inconsistencies (a tab in one file instead of 4 spaces, a single brace on the wrong line). It is counter-productive and will only make you look like an ass.
  20. Laziness and incompetence are contagious.
  21. An engineering manager’s job is to do all that is required to ensure that his engineers can do their job. This usually includes keeping his engineers sheltered from politics or any other “outside world” issues, so all they have to think about is their main responsibilities….developing, testing, documenting, etc
    1. listen to and be mindful of your manager when they do decide to involve you in those things
  22. Good engineers are harder to find than most people think, if you have one, do everything you can to keep them.
    1. The same goes for good managers.
    2. Good engineers will quickly realize if they are undervalued and will not hesitate to jump ship to somewhere where they are worth more.
    3. Top talent will not be acquired without top compensation and benefits. You can’t get the best if you don’t match what your competition is willing to offer them.
    4. You get what you pay for. If you think that less skilled or unexperienced engineers will do the same job as more experienced engineers then you are very mistaken. You might pull it off for a release or two, but sooner or later the real bill will come due.
    5. The senior engineers on your team are there for a reason. Don’t hesitate to involve them in your work, you won’t regret it. Don’t hesitate to ask them questions, you’ll look stupid down the road if you don’t. Don’t hesitate to challenge their ideas. The best solution is almost always a combination from many different perspectives.
  23. If you force developers to be more accountable for the bugs they cause, then the bad programmers will spend more time fixing bugs, and less time adding more bad code to the project…(a self limiting problem).
    1. Dedicating all of the QA effort to a separate test team is a recipe for disaster.
      1. Especially when there are geographic and cultural barriers to overcome
  24. A good exercise is to make your engineers swap code with each other…either you’ll get better code out of them, or they’ll kill each other…either way it should be fun to watch.
    1. On a larger project, this will be even more beneficial as it will expose people to areas of the code base that they may have never seen before
  25. Any time you use open source code in a project, be prepared to maintain your own branch of that code. You never know when the developers will get bored and leave you hanging.
  26. Be careful how you mix your licenses. Using GPL’ed code everywhere might speed up your startup’s time to market, but it could all be for nothing if your code ends up being forced into becoming GPL. (think LGPL)
    1. If youʼre not adding much to the GPL that you’re basing your proprietary product on, then sooner or later people won’t bother paying for your code at all. You have to have something of value to add.
  27. Beware of anyone in a suit.
    1. Especially if they make you come to work in one too.
  28. The man in charge often didn’t get there by being better than everyone else; keep that in mind.
    1. That doesn’t change the fact that heʼs in charge.
  29. If you’re made responsible for something (like security) but you are not empowered to make sure it happens, then your real job is to be the person blamed when something goes wrong.
  30. Engineering’s job is to find a way to say yes; even if the request sounds (or is) stupid.
    1. Especially if it comes from a client
    2. Don’t be afraid to ask questions
    3. If the request sounds stupid try to get to the root of what they’re really trying to do, often you’ll find that they are thinking too far ahead of themselves and a simple solution exists.
    4. Saying yes to the project does not mean saying yes to unreasonable or unrealistic time lines or resource allocations. You still have to set expectations appropriately.
    5. Saying yes also does not mean keeping your opinions quiet. If you think they are going down the wrong path, tell them so, but be prepared for the fact that engineers rarely call the shots.
    6. Don’t be afraid to propose alternate solutions
  31. Keep your code for work very separate from your code for personal projects.
    1. Be careful not to use work equipment for private projects either.
    2. Keep publicly published code out of proprietary code bases, otherwise you are a lawsuit waiting to happen.
  32. Don’t work any harder than you will be rewarded for.
    1. There are many types of rewards, how you define that is entirely up to you.
    2. Don’t stay in a job if you know you can get rewarded for your work better somewhere else
    3. Especially if you do not see a upward moving career path where you are
  33. Don’t ever let your company make you do something you would not be proud of; you may have to work with them now, but you’ll have to live with yourself and your reputation for the rest of your life.
  34. If your company makes a habit of asking you to do something you’re not proud of, find a new job.
  35. Management has no idea what the customer wants.
  36. Engineering has even less idea what the customer wants.
  37. There are people out there that specialize in turning customer desires into specific technical requirements. Engage them and work with them to turn the customer’s dreams into your product’s reality.
    1. Not using those people is a recipe for disaster
    2. Rarely is a product that only your engineering department thinks is “cool” really worth something in the marketplace
      1. “Cool” is not a business case.
  38. If you don’t talk to your customers to see what will make them happy, then sooner or later someone else will.
  39. Demonstrating that your competitors suck isn’t enough to get anyone to buy your product.
  40. Don’t ship anything you’re not proud of.
    1. Even if management tells you to. If they insist, raise your concerns to someone that will hear your case.
  41. Never outsource your core competency.
  42. In general, “revolutionary” products, aren’t. Even giants such as Apple have demonstrated that being “revolutionary” can only last so long until your competitors are just as much or even more on the cutting edge as you are.
  43. It doesn’t matter how secure your product is if no-one is willing to use it.
    1. The same goes for just about any feature or aspect of your product.
  44. Chances are your customers/users are not as dumb as you think they are.
  45. “Working from home” doesn’t count against vacation time.
  46. Only listen to the boss that can fire you, the others are just useful for stopping bucks before they hit you.
  47. More people notice it when you stay late, not nearly as much when you arrive early.
    1. If you arrive early and leave early, people will still think you are shorting hours.
  48. Your best guys probably won’t waste most of their time if you gave them something more challenging to work on.
  49. Never commit to anything in emails that you’re not actually committing to, if you must, commit to it over the phone or in person with no witnesses…otherwise learn phrases like “I’ll look into that” or “we’ll see what we can do”.
  50. Under promise and over deliver. If you are given a week to do something, tell your manager that you will do your best to get it done in that time-frame, then finish and deliver it a few days early.
    1. Management never gets tired of things getting delivered ahead of schedule.
    2. Even if that schedule is more relaxed than you know you could adhere to.
  51. If its been done before its boring.
    1. Unless you need that feature to be competitive.
  52. Odds are (Haskell/Scala/Go/Erlang) won’t be as revolutionary as you think it will be…C is still alive and well and not going anywhere
    1. So is COBOL for that matter.
    2. And RPG too
    3. And the mainframe…
    4. Picking a technology to work with just because it is the current “fad” will almost always end up biting you in the ass down the road
      1. That doesn’t get you out of having to keep up with current trends. They might not be a revolution, but they might not go away either.
  53. Use the language that you are most comfortable with, even if its not a perfect fit. Its often faster to make the language fit the developer, than to make the developer fit the language. Unless this violated rule 52.4
  54. Contrary to popular belief, ad-hoc third party libraries reduce portability of your code.
    1. This does not apply to well supported and funded libraries, or ones that you license for your use.
  55. Open source code is filled with bugs.
    1. Which get fixed based on perceived importance.
  56. Closed source code is also filled with bugs.
    1. Which get fixed based on amount of funds thrown at them.
    2. Or by the desire of the company to retain that customer
    3. Or by the desire to limit potential bad press
  57. If you have a support contract, don’t be afraid to use it.
  58. If you’re not getting better, you’re getting worse.
  59. Writing a technical book is way more work than you probably think it is.
    1. But being published has its benefits, especially with your reputation around the office as well as when you apply for other jobs
      1. Especially when your company will financially reward you for it
  60. Don’t be afraid to publish your innovations as patents
    1. Especially when your company will financially reward you for it
    2. You might not get personal rights to your idea, but your name will forever be associated with it
  61. Bugs exist in the space between what a program is supposed to do and what a program actually does. There is no such thing as self documenting code. Yes the code tells me what the program does, but it can never tell me what the program is supposed to do. Comments should explain what the program is supposed to do in as much details as the code explains what it really does.
  62. Avoid commenting the stupid stuff. We all know that int x = 0 means you are initializing x to 0. Your comments should read like a summary of the code path, not a Wikipedia article describing every little detail.
  63. Always document corner cases that you are accounting for.
  64. Take an etiquette course. People do in fact notice if you handle yourself with style and even more so, when you do not.
    1. I’ve taken this one from Nonnie Owens, which was fantastic. Find a course like this or someone who already has this knowledge who will teach it to you. Trust me, you’ll thank me later.
  65. Anyone can throw around “buzz” words. Just because you can say things like “Agile”, “MVC”, “Web 2.0” and the like, if you cannot back them up with actual substance, people will see right through you.
    1. If someone is doing this, play buzzword bingo
  66. Unless you are in the small minority (and you probably know if you are), if you code in the real world like you do in college, you will probably find yourself at a major disadvantage. Academia too often pushes the “just get it done no matter how you do it before the deadline so that your code passes the autograder” mantra. Generally, instructors in academia either don’t know how to properly write software or don’t really care. Don’t let the bad habits that poor coding instruction from school pushes on you stay with you forever. There are infinitely more jobs out there for competent coders with solid CS backgrounds than there are for CS theorists that don’t know how to code properly. Keep that in mind.
  67. An instant message is better than an email. A phone call is better than an instant message. Talking to someone is person is priceless.
    1. Unless you need your communication officially recorded for some reason or another.
  68. Design is iterative. The first idea is almost never the best nor the final one. There is a reason that Walkmans with cassette tapes have been replaced by newer devices. Do not let your infatuation with a current idea let you get behind your competition, your team, or the industry.
    1. This does not only apply to your code, but also to your career in general.
  69. Don’t let your life outside of 9-5 impact your life on the clock. Doing stupid things like drinking excessively on a work night will only lead to your own downfall.
  70. Don’t let your life on the clock impact your life outside of 9-5. Sacrificing yourself for your job is rarely appreciated to the extent that is worth your suffering.
  71. Any company that asks you to solve riddles or programming problems that have tricks to them is not worth your time. A company like that is looking to see if they can fool you, and is not really interested in how you actually decompose and solve problems. Riddles like those are analogous to proving NP reductions….it is important that you know about them, but your ability to easily solve them quickly without aides has no correlation whatsoever as to how successful you will be in your job. (I prefer the Joel method)
  72. Be confident in yourself. Your attitude is one of the major factors on how you are perceived. If you don’t believe in yourself, no one else will believe in you either.
    1. From my experience, this rule also directly applies to relationships with the opposite sex outside of the office.
  73. When you interview, if you are not also interviewing the company for yourself, you are doing it wrong.
    1. Do the toothbrush test. When you meet people that want you to work with them, if you couldn’t imagine yourself brushing your teeth next to them when you wake up everyday, you probably will be unhappy working with them.
  74. Don’t take a job solely on compensation. If you are, you are doing it wrong. Money is only one component into making the right career choice.
    1. You need to think about the things that money cannot buy, especially your quality of life outside of 9-5
    2. Money cannot buy happiness, unless you buy a waverunner, no one can be anything but happy while zipping across a lake on a waverunner
  75. Don’t be afraid to use version control, that’s what its there for.
    1. Use version control properly, use meaningful commit messages. Make your version control read like a history of your code base.
  76. From time to time every rule must be broken; one of the tests of a good engineer is knowing when those times are.
    1. The best engineers know when to break the rules, but they also know how to compensate for the resulting problems (documenting more, making it an idiom, etc).
  77. Leverage your network. What you know can be just as important as who you know.
  78. Learn something new everyday. If you aren’t growing your repertoire, you aren’t helping yourself.
    1. If your company doesn’t encourage this, find a new job.
  79. If your direct management is not capable of grasping the technical aspects of your daily work, then they are not qualified to manage you.
  80. Teaching something non-technical to someone with a technical background is easier many times over than the reverse. If you are hiring someone for a QA or technical writing position but they are a horrible coder, you are setting yourself, your team, and your company up for failure
    1. From my personal experience of teaching over 4000 students software engineering, I am positive that teaching a technical person something non-technical is much much easier than teaching a non-technical person something technical. When I taught a graduate level course at Illinois, I could teach anyone with CS fundamentals testing in a matter of weeks, but teaching someone with a testing background how to code scaled on the matter of years.
    2. Anyone who argues the opposite of this rule should be in your kill file, trust me, it is for the best.
  81. Conventions are generally a good thing, but the best engineers will know when to break them. If you are working with someone that imposes conventions even when better design prevails without them, that person should also be in your kill file.
  82. Do not ever end up in a job where your technical skills are neglected so that you become a clerk. There are less qualified people out there that can do those secretarial jobs for you. Demonstrate to your management through actions that your time is better spent on things a clerk cannot do and things should fix themselves.
  83. If your manager is a clerk, find a new job.
  84. It is great to evangelize about a process, but even if it has the best intentions, developers will rebuff it due to increased overhead on them.
    1. Developers are generally lazy and set in their ways
    2. You need to demonstrate the benefits of the increased overhead before they will adopt anything new
    3. If you do all of this, but some rogue developers still ignore it, publicly shame them
    4. Remember to be political though all of this
  85. These rules are not immutable
  86. What is the big O of merge sort?
    1. if you knew the answer off the top of your head, you pass the litmus test
    2. If you had to think about the answer to that for more than 2 seconds, you should not be working with me, working for me, or managing anyone like me because you are not qualified at the most basic level. Please reevaluate your career.
    3. What is the impact of the pivot on quicksort?
      1. same rules as 86.1, except if you cannot spit it out within 30 seconds, please disassociate yourself with software immediately, it’ll save all the educated people the trouble of having to deal with your ignorance.
    4. What is the big O of radix sort on an array of integers?
      1. being able to analyze this on a whiteboard will do 1 of 2 things
        1. make you look brilliant for knowing something not many people do
        2. shut you out of a job because idiots feel threatened when they are proved wrong by things they have not bothered to educate themselves on
    5. If I say the words “visitor”, “flyweight”, “bridge”, and “memento” and you cannot correlate them instantly, you belong in my kill file.
    6. Oh you know what “singleton” is, yeah I think we all know that popcorn is the basis of cracker jacks too…..
  87. Never be afraid to go to someone who can actually make a difference. Just because that person might be your 2nd line manager or even a VP of a company, the benefits almost always outweigh the deficits.
    1. I have found that when I do this, I actually gain respect and things start changing. The fear of raising concerns is often unwarranted.
      1. If you do get dinged for doing this, you should probably change jobs
  88. Remember to be political through all of this. If your daily job involves dealing with idiots, be kind and continue on. You will serve yourself by not burning bridges (tenure in this industry often outweighs value). Vent to people that will understand and call your bluff.
  89. If you regularly walk into meetings at work and are the smartest person in the room, do yourself a favor and find a role you will be challenged in.

 

I’ll probably be constantly changing and improving these as I continue my career, but this is how I see it now. If you have input, I’d love to hear it in the comments below.

these are purely my opinion and not that of my employer nor anyone else

Software Metrics

Note: This is a copy of a page I wrote for the software engineering course I taught at the University of Illinois Urbana-Champaign. I am reposting it here on my blog in the hope that it will be found useful by others in the future.

Software Metrics

What are software metrics?

  • Quantitative measurements distilled from data
  • Distilled by measuring software development processes and actual source code
  • Highlight areas that need work in specific nodes of code as well as generalizations about your code overall
  • “You can’t control what you can’t measure” -Tom DeMarco

Limitations of metrics

  • Software metrics are intended to help programmers control and monitor software production, but…
  • It’s difficult to determine “how much” software there is in a given program
  • Can give a skewed impression of software, especially when calculated early in the software development process
  • Can be difficult or complex to calculate, especially as the volume of code grows

Examples of metrics

  • Lines of code
  • Number of classes & interfaces
  • Code to comment ratio
  • Cyclomatic complexity
  • Code coverage
  • Bugs to lines of code ratio
  • Cohesion
  • Coupling
  • Failed tests per build
  • Version control commits per day
  • Lines of code per commit

Terminology

  • Node
    • A block of source code, usually either a single line, a function/method, class, or package. A node can have multiple children, but only one direct parent
  • Program
    • A graph of all of the nodes that comprise the source code
  • Flow graph
    • A directed graph of all of the single line nodes connected with vertices where the possible flow of execution might proceed

Some Specifics

Lines of Code

  • A key size attribute of software
  • Can be a good measure of software volatility, especially when tracked over the entire development process
  • Can be used as the basis for other metrics, such as the bugs:code and tests:code ratios

Code to comment ratio

  • We’ve already seen how important commenting is to developing quality code
  • This metric puts a numerical value on the amount of inline documentation in a piece of software
  • Gives developers warning on when code needs to be documented

Cyclomatic Complexity

  • Directly measures the number of linearly independent paths through source code
  • CC = E – N + p
    • where E = the number of edges of the program’s flow graph
    • N = the number of nodes of the graph
    • p = the number of connected components of the graph
  • If code contains no decisions, then CC=1, if a piece of code contains a binary if statement, CC=2, etc…
  • Upper bound on the number of unique test cases required to have complete coverage of a given branch
  • Commonly used thresholds:
Complex and high risk
Cyclomatic Complexity Risk Evaluation
1-10 A simple program without much risk
11-20 More complex, moderate risk
21-50
> 50 Practically untestable, very high risk
  • Lower CC contributes to a program’s understandability and indicates that it is more easily modifiable
  • Generally, the greater CC becomes, the more complex and unmaintainable the code becomes
  • Greater cyclomatic complexity indicates a greater learning curve for new developers

Code Coverage

  • A metric that describes to extent to which the source code of a program has been tested
  • Different degrees of code coverage:
    • Function coverage – Has each function in the program been executed?
    • Statement coverage – Has each line of the source code been executed?
    • Condition coverage – Has each evaluation point (such as a true/false decision) been executed?
    • Path coverage – Has every possible route through a given part of the code been executed?
    • Entry/exit coverage – Has every possible call and return of the function been executed
  • Some of the above are connected together
  • Code Coverage and Unit Tests
    • Indicator of how well your tests actually test your code
    • Lets you know if you have enough tests in place
    • Allows you to maintain the quality of your test suite over the lifetime of the project
  • How Code Coverage works (in Java)
    1. compile the source code
    2. instrument the compiled class files, excluding the compiled test cases. This adds the necessary information to allow for…
    3. Collect runtime data
    4. merge the runtime data into a auditable report
    5. When the tests are executed, the extra info added in when the files were instrumented will write out exact coverage data to disk

Cohesion

  • Cohesion is a measure of how strongly-related the various responsibilities of a software module are
  • A node is usually deemed to have “high cohesion” or “low cohesion”
  • High Cohesion can indicate many things about code, including the extent of reuse of code and readability
  • Disadvantages of low cohesion:
    • Increased difficulty in understanding nodes of source code
    • Increased difficulty in maintaining source code – changes will affect multiple nodes, changes in one node will require changes in many other nodes
    • Increased difficulty in reusing a node of source code, since most other nodes will not need the functionality that a node with low cohesion provides

Coupling

  • Coupling is the extent to which a node relies on the other nodes in the source code
  • Nodes can be called either “loosely/weakly coupled” or “strongly/tightly coupled”
  • Loose coupling indicates high cohesion!
  • Loose coupling refers to a relationship between nodes such that one node interacts with the other nodes via a stable interface and does not need be concerned with the internal implementation of the other nodes
  • Types of coupling:
    • Content coupling (tightest) – is when one node modifies or relies on the internal workings of another node
    • Common coupling – is when nodes share the same global data
    • External coupling – Is when nodes rely on an external data format
    • Data coupling – Is when nodes share data through parameters
    • Message coupling (loosest) – Is when modules are not dependent on each other, they use a public interface to communicate

Methods for decreasing coupling and increasing cohesion

  • Transmit messages between nodes in a flexible format (such as XML)
  • Use public interfaces to communicate messages between nodes where a file format is not required
  • Separate code into nodes that perform logical chunks of work (example: MVC pattern)
  • Write code such that the implementation of a given node of code is independent from how it is used by other nodes

Free tools for auditing software

Modular Programming

Note: This is a copy of a page I wrote for the software engineering course I taught at the University of Illinois Urbana-Champaign. I am reposting it here on my blog in the hope that it will be found useful by others in the future.

Introduction

According to McConnell, a module is either (1) a collection of data along with routines, or functions, that use or manipulate that data or (2) a collection of routines, or services, that operate on any external data given to it. Modular Programming aims to maintain this type of structure in code by stipulating that all classes or routines be independent(de-coupling) as much as possible without inhibiting their ability to interact (cohesion). In other words, a truly modular program is one in which cohesion is maximized and coupling is minimized. Why should one code in this way? The answer lies in the fact that modular programming has proven, with actual experimental studies, to be more maintainable and easier to debug. Since this course involves writing a fair amount of code, we advocate the modular programming approach. We describe some good rules of thumb in the sections to follow.

Cohesion vs Coupling

Cohesion and Coupling are two important aspects of modular programming that need to be well defined before one starts writing modules. A module is cohesive if it offers services that are all related to each other , particularly in terms of high level functionality. For example, if a module contains the functions enqueue() , dequeue() makePhoneCall(), writeToDisk(), readTextFile() . Perhaps the type of data used is uniform for this program, but many of these functions have nothing to do with one another. The correct solution to making this a modular program is to group the functions that are related to each other into separate modules. With this, a supermodule can be created to connect these submodules. A module is decoupled and independent if it allows for other modules to interact with it very easily without having to use any additional “hacks”. De-coupling requires one to understand the parts of the module that are independent from each other. You can think of independence by asking “how much does this function or subclass affect this other function or subclass”? If the answer is ” a lot” , then one should maintain the code as it is, making a note about how these two components are highly related. If the answer is “very little”, which typically would be the case for programmers new to modularity, then it is best to decouple the two components into separate submodules.

Information Hiding

As the term suggests, information hiding aims to prohibit others from viewing private areas of one’s program. Users of one’s code need only to know the interface of the code and not the implementation. Thus, one would only expose the code’s interface while hiding the private implementation details. According to McConnel, Such private areas are typically:

  1. Areas likely to change frequently
  2. Complicated data within a module
  3. Intricate Logic with routines of the module
  4. Operations at the programming-language level

As an example, suppose you are writing a program for your company and it involves data about the number of employees at the company. One may not want to tell outsiders or competitors about the size of its company; it might hurt that company financially to do so. Instead of making the company size publicly viewable you would have an interface that only gives public information (Gender, age, ethnic demographics as a percentage but not the actual numbers). What is being hidden is how those percentages are being calculated since the company size would be needed to calculate such demographics.

Ensuring Modularity

To make sure that you are following modular design, here are some principles to adhere to:

  1. A module should address one central functionality or goal.
  2. If a module is built from other smaller components, a module should be easily broken down into these components.
  3. Implementation details of the module should be hidden from external modules. It should be seen as a black box.
  4. The interface of the module should allow for easy access to its services without needing to set or hardcode any other information.
  5. The set of services that the module provides should be related, in terms of high-level functionality, to each other.

Extending Modules

It is important to realize that once you have a fully functional module, you can use this module as part of a larger module containing submodules as its components. This idea defines the recursive nature of modular programming, in that you can always follow this principle to build larger and larger programs. The “super-module” should follow all the principles discussed above, maintaining maximum cohesion and minimal coupling with other such modules.