Monday, April 28, 2014
List canonical hexadecimal ascii contents of a file
To list canonical hexadecimal + ascii contents of a file use hexdump command:
Sunday, April 27, 2014
API usability is not different than application usability
API usability is not different than application usability. A good application must be designed for the best possible user experience. An Application Programming Interface must be as well.
So next time you are creating that interface to expose to a consumer regardless if that will be the lead of your country or a software developer work *with* your consumer(s) to make sure you get it right.
Separation Of Concerns (SoC) helps on that. Even if you have an all star team where everybody does from A to Z in the SDLC you might end up with greatest results if you divide the work and rotate the team through the different concerns. You will naturally avoid violation of SoC.
So next time you are creating that interface to expose to a consumer regardless if that will be the lead of your country or a software developer work *with* your consumer(s) to make sure you get it right.
Separation Of Concerns (SoC) helps on that. Even if you have an all star team where everybody does from A to Z in the SDLC you might end up with greatest results if you divide the work and rotate the team through the different concerns. You will naturally avoid violation of SoC.
Saturday, April 26, 2014
Diversity in the team? Psychology is important
Diversity in the team? Psychology is important for everyone.
Certainly sa the saying goes "when in Rome, do as the Romans do" is an important aspect for the individuals. Bit how about a group of diverse individuals working as part of a team?
While the saying still goes, can't ignore the bit of tolerance you will need to cope with differences. Going more diverse brings strengths for the company but without the right team psychology diversity can result in a double edge sword. Start from making sure the mission, vision and strategy is well understood and accept the fact that everybody is different so know what to expect from each member encouraging everybody to care about the common goal and put aside the differences.
Certainly sa the saying goes "when in Rome, do as the Romans do" is an important aspect for the individuals. Bit how about a group of diverse individuals working as part of a team?
While the saying still goes, can't ignore the bit of tolerance you will need to cope with differences. Going more diverse brings strengths for the company but without the right team psychology diversity can result in a double edge sword. Start from making sure the mission, vision and strategy is well understood and accept the fact that everybody is different so know what to expect from each member encouraging everybody to care about the common goal and put aside the differences.
Agile Interdependence: As a software engineer I want to read the founding fathers so that I know my rights and duties
What is agile interdependence? As a software engineer I want to read the founding fathers so that I know my rights. You are excited about a lot of languages and technologies but without the social guidance you will not easily fit as part of a team.
My recommendation: Read and make IT and non IT departments read three important documents:
My recommendation: Read and make IT and non IT departments read three important documents:
Have a product vision before blaming the IT mission statement
I think a perfect mission statement for a software development team is "High Quality for predictable delivery".
And without a doubt I believe that with that mindset in place if a team is still not bringing value to the company then the product vision is wrong.
And without a doubt I believe that with that mindset in place if a team is still not bringing value to the company then the product vision is wrong.
Non Functional Requirements should be sticky: Quality, Usability, Performance and Capacity
Non Functional Requirements should be sticky. I argue that Quality, Usability, Performance and Capacity are the three you must keep an eye on as a priority. These define the success of any product including software applications.
The application must be tested. The tests have to be automated because otherwise the quality cannot be guaranteed over time as the amount of features to be tested goes up. Dr. William Edwards Deming philosophy for quality control can be summarized in the below ratio which should be interpreted as: Quality increases when the ratio as a whole is higher, not when the focus is just in eliminating cost. If you focus just on cutting cost most likely you are pushing problems for a near future when rework will be needed in order to correctly fix your product. The application must be user friendly, it must do what the user expects with the minimum user effort. Any extra mouse action, voice command, keyboard hit does matter. Usability matters.
The application is supposed to wait for the user, not the other way around. Performance matters.
The application must handle the expected load. How many users are expected to hit the new feature? Will the traffic be spontaneous because of a mailing campaign? Do not assume your system will handle any load. Do your math and avoid surprises. Capacity matters.
The application must be tested. The tests have to be automated because otherwise the quality cannot be guaranteed over time as the amount of features to be tested goes up. Dr. William Edwards Deming philosophy for quality control can be summarized in the below ratio which should be interpreted as: Quality increases when the ratio as a whole is higher, not when the focus is just in eliminating cost. If you focus just on cutting cost most likely you are pushing problems for a near future when rework will be needed in order to correctly fix your product. The application must be user friendly, it must do what the user expects with the minimum user effort. Any extra mouse action, voice command, keyboard hit does matter. Usability matters.
The application is supposed to wait for the user, not the other way around. Performance matters.
The application must handle the expected load. How many users are expected to hit the new feature? Will the traffic be spontaneous because of a mailing campaign? Do not assume your system will handle any load. Do your math and avoid surprises. Capacity matters.
Wednesday, April 23, 2014
On Agile: Minimum Marketable Feature (MMF) is key for the team survival
Minimum Marketable Feature (MMF) is key for the team survival. This is specially true for small software development teams in non software centric companies.
Ask yourself if that issue you are addressing will have a direct impact on a non software developer geek life. If Business ends up stating that the feature results in a high Return On Investment ( ROI ) in a very short period of time then you have created or contributed to a Marketable feature.
Then it comes MMF. The feature that will take you the minimal possible time to develop and still the reaction from Business will be the above.
If the team is not producing enough MMF most likely Business is actively looking at alternatives.
This is not a Manager concern, this is your concern as a team member, no matter what your position is. I rather read a resume that states "I delivered 12 MMF in a year" than "I saved a million dollar in a one year long project". The first statement denotes clearer and longer term strategical thinking.
This is a great question to ask in an interview like I proposed in LinkedIn, specially for those that are closer to C level executives like the case of Project Managers:
What are the top 12 minimal marketable features your team produced during your best year as PM?
Correct answer: Mention at least 12 MMF explaining real tangible value.
Incorrect answer: Not able to mention at a minimum 12 (1 per month) or not able to provide clear explanation of projected or realized ROI for each of them.
Ask yourself if that issue you are addressing will have a direct impact on a non software developer geek life. If Business ends up stating that the feature results in a high Return On Investment ( ROI ) in a very short period of time then you have created or contributed to a Marketable feature.
Then it comes MMF. The feature that will take you the minimal possible time to develop and still the reaction from Business will be the above.
If the team is not producing enough MMF most likely Business is actively looking at alternatives.
This is not a Manager concern, this is your concern as a team member, no matter what your position is. I rather read a resume that states "I delivered 12 MMF in a year" than "I saved a million dollar in a one year long project". The first statement denotes clearer and longer term strategical thinking.
This is a great question to ask in an interview like I proposed in LinkedIn, specially for those that are closer to C level executives like the case of Project Managers:
What are the top 12 minimal marketable features your team produced during your best year as PM?
Correct answer: Mention at least 12 MMF explaining real tangible value.
Incorrect answer: Not able to mention at a minimum 12 (1 per month) or not able to provide clear explanation of projected or realized ROI for each of them.
Subscribe to:
Posts (Atom)
