Tuesday, July 06, 2021

Getting git@bitbucket.org: Permission denied (publickey) ?

Error looks like:
$ git pull git@bitbucket.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Assuming that you aready confirmed that you added your ~/.ssh/id_rsa.pub or similar to bitbucket personal preferences and that did not help, then you might want to to just try to connect via SSH to bitbucket with the below command which tries to connects to bitbucket.org via SSH with user git without allocating a TTY and in verbose mode:
ssh -Tv git@bitbucket.org
You should get something similar to the below:
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 logged in as git You can use git to connect to Bitbucket. Shell access is disabled
If that is the case then you you should retry your git commands again because they should work now.

Sunday, May 30, 2021

Friday, April 30, 2021

Unmet dependencies - you have held broken packages

This issue happens when dependencies get messed up at least in Ubuntu. Here is an example that I corrected today when I could not install vim:

sudo apt-get install vim
...
The following packages have unmet dependencies:
 libpython3.8 : Depends: libpython3.8-stdlib (= 3.8.5-1~20.04.2) but 3.8.6-1 is to be installed
E: Unable to correct problems, you have held broken packages.
To resolve it you need to clean, autoclean, autoremove, update, upgrade, remove, and retry install while removing any further broken dependencies:
sudo apt-get -y clean
sudo apt-get -y autoclean
sudo apt -y autoremove
sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get remove -y libpython3.8-stdlib # game me unmet dependency on libpython3.8-minimal
sudo apt-get remove -y libpython3.8-minimal
sudo apt-get install -y libpython3.8-stdlib
sudo apt-get install -y vim
 

Friday, April 16, 2021

From fullstack developer (FSD) to fullstack engineer (FSE)

If a fullstack product owner (FSPO) cannot be found, then try to find a fullstack developer (FSD) that wants to become a fullstack engineer (FSE).

FSEs write brainstroming documentation, wireframes and end to end specifications. They interact directly with the stakeholder. They save a whole layer of transaction costs when compared to FSDs, so productivity should be increased at a minimum by 100%. Yes that is right, it doubles (at a minimum) your productivity when it comes to the traditional Stakeholder+PO approach.

But what is needed for an FSD to become an FSE? First, attitude. This professional is eager to see financially tangible results. Second, skills. This professional strives for writing specifications and code as Jorge Luis Borges would write a story, as Albert Einstein would pursue his quest to discover the laws of nature, this professional will be simple and precise.

And what are the rewards? Did I say that such company will be saving a minimum of 50% on the cost to deliver software? Furthermore isn't it clear the reliance of such company on the unmatachable attitude and skills of such Engineer?

FSDs and FSEs out there: I leave the math to you.

Wednesday, January 20, 2021

Why quality first is the only effective approach to delivering software?

To answer this question we must ask first a related question: Why any new functionality should affect any previous functionality with which apparently there is no relationship? Because software is a whole instead of just individual parts. The simil here is the human body.

When you change something that you might think is not related to something else and suddenly you realize that something else failed, it requires an Engineer if we are talking about software or a Doctor if we are talking about health to actually give you response.

Yes, software must be seen as a whole and this is the reason why we have automated tests that look for regressions in the software world, the same way ideally a Doctor will follow up with tests across your body looking for signs of problems after prescribing a solution for any other problem.

Lean software teams should recognize that anything we do anywhere can have an effect somewhere else. Whether that is incomprehensible for some or not is irrelevant because it is simply a fact of life.

And this is why quality-first is the only effective approach to delivering software. Without it you are probably facing a 45% to 65% defect ratio which is holding your team from delivering more features as you keep fixing the problems you keep introducing as you go. I have found that e2e test driven development is an effective way to deliver quality-first software products.

Thursday, January 14, 2021

The Software Industry needs more Full Stack Product Owners (FSPO)

What is this term that I have coined as "FSPO" or "Full Stack Product Owner"?

An FSPO is an organization member that leaves their usual duties for a given amount of time to focus on delivering software that resolves challenges presented in their daily line of work.

An FSPO is a stakeholder first, then a product owner (PO) after, not the reverse. It is wearing these two hats, what makes an FSPO as effective as a Full Stack Developer (FSD). The existence of an FSPO for a minimal marketable feature (MMF) will reduce the number of people involved in providing a solution and with it the transaction costs related to its delivery. I personally have empirically demonstrated that depending on the availability and commitment of stakeholders we can get 5 to 10 times faster deliveries when an FSPO is put in charge of any MMF versus having a Stakeholder and a PO in charge of the same MMF.

An FSPO is not needed though when the given MMF can be deployed to production without acceptance from stakeholders. When this happens the PO is enough because the transaction costs are zero. This occurs when the PO is a subject matter expert in the Product or the feature being enhanced and has earned the two qualities that any FSPO must possess: responsibility and authority to deliver the specific MMF.

Using the FSPO role saves big dollars in the SDLC, however the challenge is to find people that can perform this job. Just as with finding FSD, this is a scarce resource. The introduction of the FSPO role represents a literal inversion of control (IoC) for product delivery because instead of the traditional "tell me what you want, here is what I understood, here it goes again after teh feddback loop 1, here it goes again after the feedback loop 2 ..." we go with "you tell me to do this and here it is to a T".

The FSPO performs a number of duties:
  1. Create a wireframe specification (wf-spec) for the very low fidelity conceived UI/UX. This can be influenced by a UI/UX expert but in many cases, specially those related to ongoing applications, such step is not necessary. This is definitely influenced by other stakeholders.
  2. Create an outline of functional and non functional requirements for the MMF. This brainstorming specification (br-spec) is influenced by a number of other stakeholders.
  3. Create end to end specifications (e2e-spec). This will be influenced by software developers as they collectively will need to find ways to implement the assertions being requested.
  4. Review automated e2e-spec implementations (automated e2e tests) delivered by developers often and on demand.
  5. Test the MMF deployed in dev servers often and on demand.
  6. Test the MMF in full when deployed to the test environment and all e2e tests have passed per the continuous integration (CI) service.
  7. Smoke test the MMF when deployed into the production environment.
  8. Classify issues as bugs when the developer did not follow the e2e-spec to a T or defects when the specification itself was faulty.
  9. Keep track of the development pace and find the root cause of slowness. Apply theory of constraints to get the pace back up.
  10. Get back to their organization duties using the features they themselves help to create and collecting the next round of enhancements, calculate their possible return, risk and statistics-backed cost to help with the authorization from the prioritization comittee.
A good starting point to hire an FSPO is to present this need to each future organization member who regardless will need to become a stakeholder. A second important point is to have a lean, company wide deployed, process engineering. Usually this means that the CMMI level of the company in question must be high. This should be the case if the company is already using end to end (e2e) test driven development. This is because e2e specfications (e2e-spec) solve problems in a simple and precise manner and they are also not difficult to understand for organization members that are experienced in their daily jobs but lacking exposure to develop software.

Ultimately all stakeholders that wish to become FSPO will get a big bump in their professional careers as technology continues to increase its importance when it comes to enabling the success of the organization. The introduction therefore of the FSPO role is a win-win for the Organization and the Stakeholder.

Followers