The Ultimate Purpose of Software is to help somebody achieve a greater goal
1. The degree of Software
Goodness of a piece of software is the degree to which the software realizes
its ultimate purpose.
For example, software that helps 1M people learn algebra can be said to have
greater Software Goodness 2 than
another software that helps only 100 people learn algebra.
Note that people who benefit from software can be anyone impacted by the
software, other software engineers, for example. If a library is a joy to use
(due to its -ilities [readability, simplicity, robustness, etc]), then it can be
said that it achieves greater Software Goodness than a library that is a pain to
use (due to its lack of -ilities).
What drives a person to pursue Software Goodness?
I believe that what drives a peson to write software with a high degree of
Goodness is that person's Care 3
4 for others and the greater goal
the software is helping achieve.
What is a Human?
We define a human by that which a human essentially is. Humans (like everything
else in existence) are interactions of the universe happening here and now.
For example, a wave is an interaction of the ocean AND it IS the ocean, the
ocean is an interaction of planet earth and also the earth, the earth is an
interaction of the solar system and also the solar system, and so on, until we
reach the Universe.
In the same fashion, a nail is an interaction of your body and it is also your
body, your nail is you, because you are defined by all of you (nails included).
We can say that humans (just like everything else in this planet) are an
interaction of the planet AND we are also the planet, the solar system, the
milky way galaxy, the constellation and the universe.
In conclusion, we say that a Human is, essentially, an interaction of the
Universe and is also the Universe expressing itself in the form of a Human
here and now.
This is a quote-of-aquote I found in quora. It is the absolute most practical advice
I have read in my life about how to go about finding your passion.
I have found that I have always gone out of my way in life, to do that which excites
me the most, even if that has meant making my life 'harder' from an outsider's perspective,
so this advice really resonates with me.
Some of the worst things that have happened to me in my life, have been because of me following my
passion, but also, the absolute best achievements in my life have been due to me following my passion.
So I would never change any of my decisions, because now that I look at it that way, all of those
decisions are what have led me closer and closer to my true passion, and I say closer, because I still
have a feeling that I have not found my ultimate passion, and may never will...
In the meantime, I'll just keep looking.
My thesis project is about automatic evaluation of object-oriented design by means of automated code analysis; in other words evaluate the design of a program automatically.
I found the need for a tool that would allow to me to extract the code model from a program and then query over that model in order to extract information and metrics about the program's design.
The characteristics I was looking for in a code analysis tool where:
The code model extractor must process source code or intermediary code Java or .Net
Rationale: If we are able to analyze bytecode or MSIL we can use the same tool for any language of the given platform.
Acceptance Criteria: A proof of concept must be implemented that is able to extract the code model in the form of objects of the given platform.
It must possible to invoke the tool from within the code as objects, without having to go through a GUI or CLI.
Rationale: This is to easily integrate the tools as part of another project without hassle or strange behavior (i.e. opening a GUI, etc)
Acceptance Criteria: A proof of concept must be created that invokes the tool in a programmatic manner without using the CLI.
It must be able to provide:
- Number of lines of code in a method, class or namespace (package).
- Method calls between classes
- Location of method calls between classes
- Method and member signatures of a class
- Enumeration of classes, abstract classes and interfaces
Rationale: This features are needed in order to perform the code analysis, because that will provide the data we will measure and evaluate. With those features it is possible to obtain all the Chidamber & Kemerer metric suite which are fundamental for code analysis.
Acceptance Criteria: A proof of concept that can obtain each and one of the listed items programmatically.
The extracted code model must be readable in-memory, directly or indirectly.
- It is allowed for the tool to generate a file first and then read that file to generate an in-memory model
Rationale: The code model must be representable in-memory in order to use for automatic evaluation.
Acceptance Criteria: A proof of concept must be created where the code model is fully representable in memory.
This post is primarily to remind me of the concepts behind Extreme Programming. This post will help me remember that Extreme Programming is not just pair programming, TDD, reduced documentation, evolutionary design and reduced planning.
XP practices are actually the smallest piece in the puzzle, the guiding values and principles are what made Kent Beck come up with those practices.
(Human) Values => (Domain Specific) Principles => (Software Specific) Practices
Values of Extreme Programming
Values are intended to balance and support each other. Improving communication helps achieve simplicity by eliminating unneeded or deferrable requirements from today's concerns.
Values do not provide concrete advice about what to do in software development. Because of the distance between values and practices, for that Principles bridge the gap between them.
- Communication is important for creating a sense of team and effective cooperation.
- The objective of communication is to transfer knowledge and information between the team(s).
- Simplicity is the most intensely intellectual of the XP values.
- The objectives are to make a system simple enough to gracefully solve only today's problem and eliminate the waste of unnecessary complexity.
- It is also important to remember that simplicity is contextual, the design must be understandable by the team working on it, otherwise it is pointless.
- Change is inevitable in software development, therefore an XP team embraces change by giving high value to feedback.
- XP teams strive to generate as much feedback as they can handle as quickly as possible.
- They try to shorten the feedback cycle to minutes or hours instead of weeks or months. The sooner you know, the sooner you can adapt.
- Courage is effective action in the face of fear.
- Doing something without regard for the consequences is not effective teamwork.
- Courage alone is dangerous, in concert with other values it is powerful.
- Examples: The courage to speak truths, to discard failing solutions and to seek new ones.
- The other four values point to one that lies below the surface: respect.
- The contributions of each person on the team need to be respected. I am important and so are you.
- Every person whose life is touched by software development has equal values as a human being.
- Your organization, your team, and you yourself may choose other values. What is most important is aligning team behavior to team values.