Abstraction and encapsulation are opposite sides of the same coin, and essential to good object oriented software design. Why the, is there a tendency of some programmers to go in exactly the opposite direction? This trend and its implication is discussed below.
Users of a program found that sometimes, when they went to log in, they did not get a place to enter the username & password. Instead of the normal login prompt, they got a blank screen, and it was completely impossible to login. Sounds like a bad bug that needs to be fixed immediately, but the development team response was even more surprising: this was the user's fault!
Long ago I worked on a project where we needed to specify the hours that a business was going to be open, and to account for all the various difficulties around holidays and other special days. This is what we came up with and it still stands today.
There is endless discussion on how to format dates on the web, but most of this discussion is completely useless because it ignores the real world issue: different users want to see dates differently. No single date format will be suitable to everyone. This post is how to structure your product so that everyone sees the date values formatted as they would like to see them.
Always transfer dates as an integer epoch value: the number of milliseconds since Jan 1, 1970 UTC.
XML and JSON files store and transport data. What is the best way to store a Date-Time value? Always, always, always use the integer epoch format: the number of milliseconds since Jan 1, 1970 UTC. This post tells you why.
Time is expressed as a linear dimension starting in the past and going into the future. Any given moment is an instant alone that line. A date and/or time is a way of describing that point. But the description of that point depends on the time zone within which you are communicating.
The discussion came up of how to improve usability of the system. One position was to hire a usability expert to draw us a specification of a highly user friendly system, and then deliver that to the development team to implement it. There are several reasons why that will not work.
Design is the domain of product managers. It is performed most oten by people who do not do the implementation, however it is strongly informed by the implementation reality. Design is a synthesis from the customer needs and the technical possibilities.
One common rabbit hole that programmers often fall into is creating designs for abstract capabilities that then prove to be useless in real life. To avoid this, we must focus on concrete real-world examples when designing capabilities.
In a globally distributed system, there are some key patterns for handling dates so that they work reliably, performantly, and are unlikely to be misused by developers. Oddly, a number of new classes were added to Java which should be avoided.
This general design principle does not mean to never change anything, but to consciously create a paradigm where the same things have the same names and are accessed in the same way as much as possible.
The image of being forced to jump through hoops is one of being required to take arbitrary actions in arbitrary orders just to satisfy some goals that are either unseen or at least not in the interest of the user. Some software is like that. You have to perform functions that you don't want to do, that you know you are going to get rid of, in order to satisfy some internal constraint of the software.
At some point you may be asked to implement a timer — something that displays the amount of time that is elapsing. It can be a count-up timer showing the total times that something has been happening. Or it might be a count-down timer showing the amount of time remaining to complete a particular task. Most programmers will make some key mistakes the first time they attempt this. I am rather shocked and amazed at how many incorrect examples you can find if you scan the internet.
People talk about usability of software as if it was something separate from the software itself. Usability expert skills are distinct from those of programmers. And yet, usability is affected by many deep aspects of the software. It is essential that all programmers on a project be aware of the usability goals of the entire project.