Capturing these so I don’t lose these:
- Make users happy with your product as quick as you can
- Help your users as much as you can after that
- The simplest way to create value online is to save the user time
How embedded software projects run into trouble
Jack Ganssle has written articles for his top ten list of how embedded software projects run into trouble. Most of this could apply to any software project! Here are the links:
- Unrealistic schedules
- Quality gets lip service
- Poor resource planning
- Writing optimistic code
- Weak managers or team leads
- Crummy analog/digital interfacing
- Bad science
- The undisciplined use of C and C++
- Jumping into coding too quickly
- Not enough resources allocated to a project
When I read this, I decided to start working on the asset that is my weblog. I will strive to post something daily, even if it is only a link….
I would like to try this out!
I really like reading Belle Cooper’s post on leaving Micro.blog (via Chris Aldrich, which I saw in my RSS reader web app). I think it is good for people to share all sides of the experience of using a service. My preference is to host my own weblog and content, which I think is in sync with some of Belle’s points.
Doing a local install of Federated Wiki
Earlier this week, I installed the latest version of NodeJS and NPM (https://nodejs.org/en/) . I am going to try to install wiki on my Windows laptop.
Per this page (https://www.npmjs.com/package/wiki), I started Node.js command prompt and entered the following command:
npm install -g wiki
I then opened a browser tab and went to http://localhost:3000 and was able to see the Welcome Visitors page:
To be able to see the journal icons and be able to make edits, I clicked on the word “wiki” at the bottom of the page. After doing that, I saw a check mark appear next to the word, and I was able to make and save edits. It still looked like there is a yellow background to the pages. In the past, I thought that meant that changes would not be saved, but I will need to look into that more.
Next steps – look at getting wiki source code and running that so I can make local changes.
Getting back into Federated Wiki
I had a Google Hangout today with Ward Cunningham, creator of the wiki and his newer project Federated Wiki. I have my own wiki instance, spent the day discussing support for a project in Oregon using wiki and how I can help. It was good to catch up with Ward, I am looking forward to working with him.
The Post Kinds Plugin for WordPress attempts to make it much easier to create customized displays for and format each of these types of posts (and many more). It leverages the flexibility and power of WordPress to be your single social media hub while, along with other IndieWeb friendly plugins, still allowing you to interact with other social networks.
The debt metaphor in software development
In a new post, Ward Cunningham shares his thoughts on the “debt metaphor” in software development. One of the points he brings out is that programming can be thought of as making decisions now on the functionality of the program and deferring others to a later time (debt), with the understanding that as the program matures, refactoring can occur to make the program more efficient/better (paying back the debt).
In my experience in avionics software development, the creation of software is driven by approved requirements. As requirements change or are refined, the software is updated to be consistent with those requirements. One type of “debt” I see is when functionality is not completed on time, and gets deferred to a later software release (cost increase). Another type is when a problem is found (requirements, source code, tests, documents), but addressing the problem is deferred to a future time (the problem does not impact the functionality of the requirements, source code, or tests, or is deemed not a safety issue). This type of debt (typically called “open problem reports” (OPRs) is getting more scrutiny by aircraft certification agencies and OEMs (Bombardier, Boeing, etc.), since they see increasing numbers of OPRs as an indicator that the overall “health” of the software may not be as good as it should be, and that there should be as few OPRs as possible (in other words, fix your problems as you find them).
For myself, I prefer to fix problems when they come up. However, when you work as a member of a team, sometimes business decisions dictate otherwise….