Software on Pavan Yarahttps://pavanyara.com/tags/software/Recent content in Software on Pavan YaraHugo -- gohugo.ioen-USpavan.yara@gmail.com (Pavan Yara)pavan.yara@gmail.com (Pavan Yara)Pavan YaraThu, 16 Jan 2020 22:31:34 +0530Don't Just Roll the Dice - A usefully short guide to #softwarepricinghttps://pavanyara.com/blog/dont-just-roll-the-dice/Thu, 16 Jan 2020 22:31:34 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/dont-just-roll-the-dice/<p>How do you price your software? Is it art, science or magic?</p> <p>How much attention should you pay to your competitors?</p> <p><a href="https://neildavidson.com/downloads/dont-just-roll-the-dice-2.0.0.pdf">This short handbook</a> will provide you with the theory, practical advice and case studies you need to stop yourself from reaching for the dice.</p> <h3 id="table-of-contents">Table of Contents</h3> <ul> <li>Chapter 01: Some – but not too much – Economics</li> <li>Chapter 02: Pricing Psychology: What is your product worth?</li> <li>Chapter 03: Pricing Pitfalls</li> <li>Chapter 04: Advanced Pricing</li> <li> <ul> <li>Chapter 05: What your price says about you (and how to change it)</li> </ul> </li> </ul>How do you price your software? Is it art, science or magic?

How much attention should you pay to your competitors?

This short handbook will provide you with the theory, practical advice and case studies you need to stop yourself from reaching for the dice.

Table of Contents

  • Chapter 01: Some – but not too much – Economics
  • Chapter 02: Pricing Psychology: What is your product worth?
  • Chapter 03: Pricing Pitfalls
  • Chapter 04: Advanced Pricing
    • Chapter 05: What your price says about you (and how to change it)
]]>Things I Learnt The Hard Way (in 30 Years of Software Development)https://pavanyara.com/blog/things-learnt-the-hard-way-programming/Fri, 28 Jun 2019 19:39:07 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/things-learnt-the-hard-way-programming/<p>This is a cynical, clinical collection of things Julia Biason learnt in 30 years working with software development.</p> <p>Again, some things are really cynical, others are long observations on different jobs.</p> <h2 id="before-you-start-writing-code">Before you start writing code&hellip;</h2> <ul> <li>Spec First, Then Code</li> <li>Write Steps as Comments</li> <li>Gherkin Is Your Friend to Understand Expectations</li> <li>Design Patters Are Used to Name Solution, Not Find Them</li> <li>Thinking Data Flow Beats Patterns</li> <li>The Magic Number Seven, Plus Or Minus Two</li> <li>Cognitive Cost Is The Readability Killer</li> <li>Learn The Basics of Functional Programming</li> </ul> <h2 id="testing-software">Testing Software</h2> <ul> <li>Unit Tests Are Good, Integration Tests Are Gooder</li> <li>Testing Every Function Creates Dead Code</li> <li>Tests Make Better APIs</li> <li>Make Tests That You Know How To Run On The Command Line</li> <li>Good Languages Come With Tests</li> </ul> <h2 id="documenting-your-code">Documenting your code</h2> <ul> <li>Documentation Is A Love Letter To Your Future Self</li> <li>The Function Documentation Is Its Contract</li> <li>If A Function Description Includes An &ldquo;And&rdquo;, It&rsquo;s Wrong</li> <li>Good Languages Come With Integrated Documentation</li> </ul> <h2 id="writing-code">Writing code</h2> <ul> <li>Be Ready To Throw Your Code Away</li> <li>Future Thinking Is Future Trashing</li> <li>Don&rsquo;t Use Booleans As Parameters</li> <li>Beware of Interface Changes</li> <li>It&rsquo;s Better To Let The Application Crash Than Do Nothing</li> <li>If You Know How To Handle It, Handle It</li> <li>Types Say What Your Data Is</li> <li>If Your Data Has a Schema, Use a Structure</li> <li>Don&rsquo;t Mess With Things Outside Your Project</li> </ul> <p>More:</p>This is a cynical, clinical collection of things Julia Biason learnt in 30 years working with software development.

Again, some things are really cynical, others are long observations on different jobs.

Before you start writing code…

  • Spec First, Then Code
  • Write Steps as Comments
  • Gherkin Is Your Friend to Understand Expectations
  • Design Patters Are Used to Name Solution, Not Find Them
  • Thinking Data Flow Beats Patterns
  • The Magic Number Seven, Plus Or Minus Two
  • Cognitive Cost Is The Readability Killer
  • Learn The Basics of Functional Programming

Testing Software

  • Unit Tests Are Good, Integration Tests Are Gooder
  • Testing Every Function Creates Dead Code
  • Tests Make Better APIs
  • Make Tests That You Know How To Run On The Command Line
  • Good Languages Come With Tests

Documenting your code

  • Documentation Is A Love Letter To Your Future Self
  • The Function Documentation Is Its Contract
  • If A Function Description Includes An “And”, It’s Wrong
  • Good Languages Come With Integrated Documentation

Writing code

  • Be Ready To Throw Your Code Away
  • Future Thinking Is Future Trashing
  • Don’t Use Booleans As Parameters
  • Beware of Interface Changes
  • It’s Better To Let The Application Crash Than Do Nothing
  • If You Know How To Handle It, Handle It
  • Types Say What Your Data Is
  • If Your Data Has a Schema, Use a Structure
  • Don’t Mess With Things Outside Your Project

More:

]]>Engineering Principleshttps://pavanyara.com/blog/engineering-principles/Wed, 26 Jun 2019 21:44:58 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/engineering-principles/<p>From 12factor.net:</p> <p>I.<a href="https://12factor.net/codebase">Codebase</a>. One codebase tracked in revision control, many deploys</p> <p>II.<a href="https://12factor.net/dependencies">Dependencies</a>. Explicitly declare and isolate dependencies</p> <p>III. <a href="https://12factor.net/config">Config</a>. Store config in the environment</p> <p>IV. <a href="https://12factor.net/backing-services">Backing services</a>. Treat backing services as attached resources</p> <p>V. <a href="https://12factor.net/build-release-run">Build, release, run</a>. Strictly separate build and run stages</p> <p>VI. <a href="https://12factor.net/processes">Processes</a>. Execute the app as one or more stateless processes</p> <p>VII. <a href="https://12factor.net/port-binding">Port binding</a>. Export services via port binding</p> <p>VIII. <a href="https://12factor.net/concurrency">Concurrency</a>. Scale out via the process model</p> <p>IX. <a href="https://12factor.net/disposability">Disposability</a>. Maximize robustness with fast startup and graceful shutdown</p>From 12factor.net:

I.Codebase. One codebase tracked in revision control, many deploys

II.Dependencies. Explicitly declare and isolate dependencies

III. Config. Store config in the environment

IV. Backing services. Treat backing services as attached resources

V. Build, release, run. Strictly separate build and run stages

VI. Processes. Execute the app as one or more stateless processes

VII. Port binding. Export services via port binding

VIII. Concurrency. Scale out via the process model

IX. Disposability. Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity. Keep development, staging, and production as similar as possible

XI. Logs. Treat logs as event streams

XII. Admin processes. Run admin/management tasks as one-off processes

]]>