Provide All The Information The User Needs And Nothing More

A key part of the design process is the precise definition of each and every software component in the system. This specification will become the "public" part of the component. It must include everything a user needs, such as its purpose, its name, its method of invocation, and details of how it communicates with its environment. Anything that the user does not need should be specifically excluded. In most cases, the algorithms and internal data structures used should be excluded. For if these were "visible," users might utilize this information. Subsequent enhancement or modification then becomes profoundly more difficult because any change to the component has a cascading effect on all components that use it (related to encapsulation).


Reference:
Parnas, D., "A Technique for Software Module Specification with Examples," CACM (May 1972).

Determine The Requirements Now

Requirements are hard to understand and harder to specify. The wrong solution to this problem is to do a slipshod job of requirements specification, and rush ahead to design and code in the vain hope that:

1. Any system is better than no system.
2. The requirements will work themselves out sooner or later.
3. Or the designers will figure out what can be built as they are building it.

The right solution is to do whatever it takes to learn as many of the requirements as possible now.

• Do prototyping.
• Talk with more customers.
• Work with a customer to get to know his or her job firsthand.
• Collect data.
• Do whatever it takes.

Now document the requirements that you understand and plan to build a system to meet those requirements. If you expect requirements to change significantly, that's okay; plan to build incrementally (Grow Systems Incrementally), but that is no excuse for doing a poor job of requirements specification on any one increment.

Reference:
Boehm, B., "Verifying and Validating Software Requirements and Design Specifications, IEEE Software, January 1984.

Fast Software Performance

Here are some aspects of software development that should be considered when trying to improve an application's performance.

Write Better Algorithms

Ultimately, the performance of an application is based on how well is is written. If the program loops around all elements in an array, the JVM will optimize the array bounds-checking so that the loop runs faster, and it may unroll the loop operations to provide an additional speedup. But if the purpose of the loop is to find a specific item, no optimization in the world is going to make the array-based code as fast as a different version that uses a HashMap.

A good algorithm is the most important thing when it comes to fast performance.

Improving your Algorithms & Data Structure Skills | medium

Write Less Code

A small well-written program will run faster than a large well-written program. This is true in general of all programs, and it applies specifically to Java programs. The more code that has to be compiled, the longer it will take until that code runs quickly. The more objects that have to be allocated and deallocated, the more work the garbage collector will have to do. If the objects are allocated and retained, the longer a garbage collection cycle will take. The more classes that have to be loaded from disk in the JVM, the longer it will take for a program to start. The more code that is executed, the less likely it will fit in the hardware caches on the computer. And the more code that has to be executed, the longer it will take.

More code / more features is a "Death by a thousand cuts". A developer will add a very small check for a feature then other developers will do the same and suddenly the performance has regressed. The cycle is repeated in the next release, and the performance starts to be noticeable. A couple of times during the process, performance testing might hit some resource threshold - a critical point in memory use, or a code cache overflow, etc. In those cases, the regular performance tests might make it possible to fix what appears to be a major regression. But over time, as the small regressions creep in, it will be harder and harder to fix.

I'm not advocating that you never add new features or code. The benefits of enhancing your applications is clear. But be aware of the small trade-offs you are making.

Writing Less Damn Code | heydonworks
Write Less Code | codeahoy
The Best Code Is No Code At All | codinghorror

Optimization Best Practices

Software engineers are expected to be familiar with the coding constructs that are known to be bad for performance. When writing code it is not "premature optimization" to apply your knowledge of best practices. So long as you are able to write clean, straightforward code that is simple to read and understand then you don't need to worry that you are prematurely optimizing your code.

30 Java Programming Tips and Best Practices for Beginners | javacodegeeks

Look Elsewhere

If you are developing standalone applications that use no external resources, then the performance of that application is mostly all that matters. Once an external resource such as a database is added, then the performance of both programs is important. And in a distributed environment, say an application server, a load balancer, a database, and more, then the performance of the single application server might be the least of the performance issues. In such an environment, a structured approach must be taken towards all aspects of the system. CPU usage, I/O latencies, and throughput of all parts of the system must be measured and analyzed; only then can it be determined which component is causing the performance bottleneck.

Optimize for the Common Case

It is tempting to treat all performance aspects as equally important. But focus should be given to the common use case scenarios.

• Optimize code by profiling it with realistic usage and focusing on the operations taking the most time.
• Apply Occam's razor to diagnosing performance problems. The simplest explanation for a performance issue is the most conceivable cause; a performance bug in new code is more likely than a bug in the JVM or the operating system.
• Write simple algorithms for the most common operations in the application. In general, optimize for the majority of your users. That will give you good overall performance stats but might not be what you need. For example, if 10% of your users, make 90% of your profit then you should optimize for that 10%.

Finally, JVM Tuning

Now that you have gone through the previous aspects that affect program performance, you are in a good place to tune the JVM. 

Align Reputation With Organization

It is generally recognized that Japanese software engineers view software bugs differently than American software engineers. Although many factors influence this, one relates to the perception in Japan that an error in a product is a disgrace to the company, and a disgrace to the engineer. This works more effectively in Japan than in the United States because Japanese workers tend to remain in one company for their entire careers. The mind-set, however, is important regardless of employment longevity.

In general, when anybody finds an error in a software engineer's product, that engineer should be thankful, not defensive. To err is human. To accept, divine! When an engineering error is found, the person causing it should broadcast it, not hide it. The broadcasting has two effects:

1. It helps other engineers avoid the same error.
2. It sets the stage for future non-defensive error repair.

Consider some guidelines for reporting errors.

1. Ask a coworker to check your work. Someone who will give you time to contact the author and won't judge you if you are wrong.
2. Give the author time to verify your report of an error.
3. Discuss with the author how to best report the error so that the error gets fixed with as little drama as possible and so the right people are informed.

Reference:
Mizuno, Y., "Software Quality Improvement," IEEE Computer, March 1983.

Change During Development Is Inevitable

Software will change during development! The changes might be refactoring code, adding new tests, changing requirements, or adding new requirements. The changes could be as simple as fixing bugs, or general improvements.

Prepare yourself for changes by making sure:

• that all software development is appropriately cross-referenced,
• Record Why Requirements Were Included
• Trace Design to Requirements
• Trace Tests to Requirements
• that change management procedures are in place, and
• Establish SCM Procedures Early*
• Give Every Intermediate Product a Name and Version*
• Rank and Schedule Change Requests*
• that budgets and schedules have enough leeway so that you are not tempted to ignore necessary changes just to meet budgets and schedules.
• Don't Set Unrealistic Deadlines*
• Avoid the Impossible*
• Avoid Standing Waves*

Reference:
Bersoff, E., V. Henderson, and S. Siegel, Software Configuration Management, Englewood Cliffs, N.J.: Prentice Hall, 1980, Section 2.2.

Poor Reliability Is Worse Than Poor Efficiency

Poor Reliability

Poor Efficiency

Poor reliability may not be readily apparent and it may be inconsistent. The difficulty in detecting poor reliability contributes to the difficulty in finding a fix for the problem. Efficiency, on the other hand, is usually consistent and easier to isolate. Making a redesign or refactor of the code for better efficiency easier than fixing poor reliability. Which "needle" do you think is harder to find?


Reference:
I. Sommerville. 1992. Software Engineering, Section 20.0. Addison-Wesley., Reading, MA, USA.

Great Designs Come From Great Designers

The difference between a poor design and a good design may be the result of a sound design method, superior training, better education, or other factors. However, a really great design is the brainchild of a really great designer. Great designs are clean, simple, elegant, fast, maintainable, and easy to implement. They are the result of inspiration and insight, not just hard work or following a step-by-step design method. Invest heavily in your best designers. They are your future.


The Design of Everyday Things

Design Principles

Design is the set of activities including:

1. defining an architecture for the software that satisfies the requirements
2. specifying an algorithm for each software component in the architecture

The architecture includes a specification of all the building blocks of the software, how they interface with each other, how they are composed of one another, and how copies of components are instantiated (made in memory and executed) and destroyed. The final product of design is a design specification.

Not Even In The Same Ballpark

Not so long ago, a new Product Manager told me that she also is a programmer... a software engineer. She implied that if she wanted she could be part of the development team. She had just started and I had no reason not to believe her and accepted it as an interesting side note and went on. As time has gone by it has become increasingly apparent that this individual was never a software engineer in the way that my peers are. The comparison is almost offensive in the stark difference and extreme lack of understanding of what a software engineer does.

To anyone reading this:
Please do not say that you are part of someone else's group unless you truly know about that person's group. I've brewed beer and cider a handful of times. I've even had the lucky experience of brewing some stuff that is better than some store bought stuff. But I would never call myself a brewer in the presence of someone like Sam Calagione or Jamil Zainasheff. I've never brewed commercially and have no concept of the constraints involved, and I don't have near the same range of experiences. Notice the difference in tone the following two statements have:

• I'm a brewer like you.
• I've brewed at home.

If they both seem innocuous then here are some example responses, respectively:

• Oh yeah, what bars are serving your beer?
• Since I have never brewed commercially, I do not grok the need for high efficiency sparging, dealing with distribution laws, etc.
• That's cool. What is your favorite style.
• I love Bock beer. And Belgium style. And Kolsch. And Scotch ale. And, oh man, Southern Tier's Creme Brulee stout is just epic. But I mostly make cider because I'm decent at it.

Of course, those responses could go any number of ways but the point is that you can share that you have some shared experience without implying your of the same level. Especially, when you have no idea. Heck, you might be better but you just met so you have no idea.

In short, just be genuine. If you were hired to do a job, focus on that. Don't worry about trying to "fit in" with people in other roles.

Four Points For a Better Team

1. Promote The Team
• Teamwork is powerful. Reward it. Also, make the effort to stop selfish and egocentric behavior.
2. Get Visual
• Everyone understands a good image. Instead of a paragraph that starts with tl;dr make a graphic that captures the point.
3. Tell The Company Story
• A company story enables deeper understanding than a vision statement. This understanding will help your employees focus on the company mission.
4. Be Present
• Get out and mingle with your employees and coworkers. Your team is watching you so strike up conversations and inspire unity and foster some goodwill.