These are examples from C/C++. Other numeric and data types are possible (e.g., 80-bit floats, logicals, enumerated types, tuples representing colors for pixels in images and videos, ASCII and Unicode for text characters and symbols), dates and times.
Basic types can be combined into strings, arrays, structures, records, objects, and so on, sometimes requiring you to know where the gaps are (see story 1).
Instruction Operations (meta-operations)
BIOS level: Machine level instructions that know how to access some hardware and bootstrap the OS.
Operating System (OS) level: Manages processes, provides background services, facilitates access to all hardware
Application level: Does what the users want. Business Analysts are mostly concerned with applications that serve users.
Cluster level: Systems of multiple computers that perform different functions or replicate functions for scalability, operating as a unified whole.
Translate human-readable code into machine code.
Automate writing code.
Reduce coding errors.
Integrate reference material.
Integrate debugging and test operations.
Manage large projects.
Enhance and organize collaboration.
Comparisons of how the same basic constructs are handled in different programming languages are here and here as just two examples.
In the end the libraries and application frameworks are the bulk of what needs to be learned.
The compiler, VM, or OS can set maximum sizes for these. Physical configuration of the processors and memory set the ultimate limits.
Details may vary between implementations
Traditional programs can mark a region of the heap and make it visible via the OS to other programs, which can then map to the absolute address. All programs need to use the same declarations for this to work (usually a shared header or include file).
Most work gets done in third-generation languages.
Languages may fit into or incorporate many different paradigms.
Is it more important to optimize software on speed or memory?
With power comes responsibility! Newer tools take more work out of the hands of programmers.
List of considerations
People and Methods
The ultimate optimization is to minimize the total cost of ownership over the entire life cycle.
There are multiple barriers to clear communication.
These can be mitigated by error-checking mechanisms — and by being clear in the first place.
The end blocks can be improved by review, mutual expertise, patience, and empathy.
The middle blocks can be improved by clearing up the communication medium.
Don't assume communications will just work. Make them robust.
Arrange for queues so failed operations can be retried until they succeed.
Log everything if appropriate. Use performance monitors.
Be aware of different data types and formats in different languages and on different machines.
Internet and other communications are often set up to deal with differences in data types, as described previously, and endianness, using XML encoding where everything is written out in text.
Other communications, involving video, audio, images, and specialized document formats, are based on published standards.
Talking to customers is improved by mutual expertise, patience, and empathy.
Talking to users is improved by mutual expertise, patience, and empathy.
Talking to technical teams is improved by mutual expertise, patience, and empathy.
Talking to management is improved by mutual expertise, patience, and empathy.
Talking to external entities is improved by mutual expertise, patience, and empathy.
Documentation, review, feedback, and correction are human forms of queuing and retrying.
Non-functional requirements are qualities the solution should have, and may also address working methodologies.
Wikipedia lists close to sixty possible NFRs.
All other participants and stakeholders should willingly — and proactively — drive identification and specification of NFRs, and will doubtless have their individual passions, but never be bashful about asking questions which lead to more conversation and specification.
As a BA, consider it your responsibility to drive a thorough exploration of this topic during an engagement.
If the Conceptual Model and Requirements are defined with sufficient clarity and thoroughness, the UI should practically write itself.
A good UI can be pretty or utilitarian, but it's more important that it:
I've used systems that had absolutely horrible interfaces where you were never confident about what was going on.
Tax software and job search sites often maintain clear situational awareness.
Individual fields can enforce certain formats, can display allowable ranges of values, and show flags or change color when formatting or values are not acceptable.
BAs should have a solid grounding in UI elements and actions, and tools to create mock-ups, wireframes, and so on.
Question: Should there be more than one way to do things?
You are trying to solve the problem on three layers as the same time.
I tend to conceptualize from the middle (application) layer and work out.
If the middle is solved abstractly, the other layers practically specify themselves.
Working in the different layers takes different, specialized skills. You need to be able to talk to a lot of different kinds of people.
Link to detailed discussion.
Given our discussion of...
...we see that the trend in software languages, tools, development practices, and management, has been in the direction of increasing abstraction in support of greater productivity and complexity.
Facts and Fallacies of Software Engineering describes 50 years of incremental advance.
This presentation and other information can be found at my website: