This blog post describes some ideas I have about writing better code. When one says “optimize” the first question I have is: what is the goal? What are we optimizing for? I think optimizing means maximizing the economic value of the software you are working on. There is a subjective component to value that a developer has no control over. However, there are a lot of things that influence value that are directly controlled by developers.
With that, I will enumerate some key areas asking questions for each. Remember that programming is hard, and there is no panacea that works for everything. But these are some questions which help me think about what is working and what is not.
1. Use a specification/contract
- Can developer reading only the signatures and inline comments figure out how to use the functionality?
- Is expert knowledge of the implementation required to understand what the functionality is going to do?
- When a bug occurs, how difficult is it to find the part(s) of the code that are responsible?
- Are contracts recorded in comments? Enforced as runtime checks? Enforced as compile time checks?
2. Handle errors consistently
- Do you use return codes?
- Do you use exceptions?
- Is it possible to debug failures easily (e.g., set one breakpoint for unexpected events)?
- In the event of an error, does the program silently produce unexpected results?
- In the event of an error, does the program offer an informative error message and avoid damaging the program state?
- Can the program recover from some failures to still produce a meaningful result? (Please note: recovering from an error is completely different from ignoring it…)
3. Use interfaces
- To add a new functionality X, how much code needs to change?
- Do the function/method signatures make sense without reading the implementation code?
- Are there any functions/methods with more than six arguments?
4. Multithreading Friendliness
- How much static and global data is present?
- How monolithic are the algorithms?
- Can the big/time consuming parts of the algorithm be broken into non interacting pieces?
5. Know your programming tools
- Are you familiar with what STL can do, and how quickly? i. E.g., what does std::equal_range do?
- Are you familiar with Boost and other available utilities?
- Are you aware of domain specific libraries to help with what you are doing?
- Does your programming environment offer things like auto completion, cross referencing in the code, etc.?
- How much do you need text find to navigate in your code?
6. Know your source control, build, and testing systems
- How long does it take a new employee to check out and build a copy of the product?
- Are automatic tests run regularly on the code?
- How long does a build take?
- If someone makes grossly incorrect changes to the code, how long does it take to recover from that?
- Are changes associated with stories/bug fixes?
- Can you obtain source for each version of your released product easily?
- Are dependencies noted between changes? i. e.g., if someone wanted a version of your product from 10 years ago, except with bug fixes x,y, and z applied, how long would it take to comply with that request?)
7. Performance
- How do you measure size/complexity of inputs?
- How does compute time scale with size of inputs?
- How does memory consumption scale with size of inputs?
- For a given hardware configuration, how large a problem can you handle without running into memory problems?
Do you, dear reader, have any questions or schema for accessing software and development quality that you would like to share?
No Comments Yet
Let us know what you think