Talent Development Centre

Tag Archives: software

All Talent Development Centre posts for Canadian technology contractors relating to software.

5 Free Software Programs That Are Actually Great!

There is some brutal software out there, and some even cost money! As far as free ones go, when you do find a good program, it’s often accompanied by viruses or malware, making you wonder if they’re worth your while. In the end, filtering through all of the junk to find the best free software can be a massive waste of time.

This video from TechGumbo might be your solution to all of this.  They’ve done the heavy lifting and came up with 5 free downloads that they consider to be great and extremely useful. Hopefully at least one of these will solve your software woes and increase your productivity.

Top 5 Cool Free Software You Need (Video)

The Internet is filled with hidden features. Just spend a few minutes searching out Google’s Easter Eggs and you will fill your day doing absolutely useless things, like turning the screen around with barrel rolls or searching for Chuck Norris and the meaning of life.
There are also practical items to find on the Internet, like free software that will raise your productivity and secure your computer when downloading. In this video from ThioJoe, you can learn about 5 different programs (plus one bonus) that just may change how you work today. Have a look. If you have any other favourites not included in the video but you’d like to share with our readers, please feel free to include them in the comments below.

Refactoring and Business

This is part two of a two part series (Part 1 can be found here). The original article Refactoring: 4 Key Principles was originally featured on the Agile Advice blog by Mishkin Berteig.

Talent Development Centre subscribers earn 30% off Agile Training Sessions in 2016. Register here and use Eagle’s membership number BLP038YK7E

Refactoring and BusinessIn the Scrum Master and Product Owner classes that we teach, this topic comes up frequently: how does the business account for refactoring?  How do we “govern” it?  How do we make good decisions about refactoring?

There are a few principles that are important in helping to answer these questions.  All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum,OpenAgile, or Kanban.

Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large batches.  The worst extreme is the complete system re-write refactoring.  The best refactoring activities take seconds or minutes to execute.  Small refactorings create a constant modest “overhead” in the work of the team.  This overhead then becomes a natural part of the pace of the team.

Not all refactoring moves can be kept so small.  For example, upgrading a component or module from a third party might show that your system has many dependencies on that module.  In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously.  This allows your system to be partially refactored.  In other words, to break a large refactoring into many small refactorings.  This, in turn, may force you to refactor your system to be more modular in its dependencies.

Another common problem with keeping refactorings small is the re-write problem.  Your own system may have a major component that needs to be re-written.  Again, finding creative technical means to allow for incremental refactoring of the component is crucial.  This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously.  One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.

Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it.  Instead, the technical team needs to use business requests as catalysts for refactoring.  If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature.  In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.

Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date.  This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code.  So, instead, we need to allow the technical team to refactor when they detect duplication.  Duplication of code, data or structure in the system.  A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result.  But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution.  Later, the business makes another request that also implies the same large refactoring.  Now is the time to seriously consider it.  It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies.  However, the technical team must also be willing to push back to the business under the right circumstances.

Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration.  In refactoring work, teamwork applies just as much as in any other activity.  Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring.  But that is just the first level of team cohesion around refactoring.

The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring.  Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring.  This last idea is best expressed by the concept of refactoring to patterns.

The highest level of team cohesion in refactoring comes fromcollective code ownership and trust.  Usually, this is built from practices such as pair programming or mob programming.  These practices create deep levels of shared understanding among team members.  This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support.  It also impacts research and learning processes so that teams can do experiments and try alternatives quickly.  All of which leads to the ability to do refactoring, large and small, quickly and without fear.

Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring.  This can be difficult at first.  Another analogy helps to see the value of this.  A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc.  In fact, all of those things contribute to the cost of surgery.  A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them.  Likewise, software professionals need to be open about the costs of refactoring.  This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest.  Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.

The challenge for business stakeholders is to accept the costs.  Respecting the team and trusting their decisions can sometimes be very hard.  Teams sometimes make mistakes too, which complicates trust-building.  The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring.  Ideally, it is continuous, small, and low-level.  But once in a while, a team will have to do a large refactoring.  How do you know if the cost is legitimate?  Unfortunately, as a non-technical stakeholder, you can’t know with certainty.  However, there are a few factors that can help you understand the cost and its legitimacy, namely, the principles that are described here.

If the refactoring is small, it is more likely to be legitimate.

If the refactoring is in response to a business catalyst, it is more likely to be legitimate.

If the refactoring is reflective of team cohesion, it is more likely to be legitimate.

And, of course, if the refactoring is made transparent, it is more likely to be legitimate.

About the Author
Mishkin Berteig is the President and Co-Founder of Berteig Consulting Inc. He has been Mishkin Berteigtraining, coaching and consulting for organizations adopting Agile methods since 2001 and is committed to helping individuals, teams and organizations apply Agile methods. Mishkin is a Certified Scrum Trainer, and qualified to deliver OpenAgile and Agile Project Management training.  He has developed and delivered Agile training both in public and in-house seminars for over 3000 people in Canada and abroad. Courses have been as short as three hour intro-style and as long as five day boot-camp-style, and audiences have ranged from junior team members to senior executives. He has also assisted organizations of all sizes to make the transformation from traditional methods to Agile/Scrum methods (Extreme Programming, Scrum, Lean, OpenAgile).  Assistance includes Agile Engineering Practices, Agile teamwork, Agile project and product management, Agile management and executive management.

Refactor or Die

This is part one of a two part series. The original article Refactoring: 4 Key Principles was originally featured on the Agile Advice blog by Mishkin Berteig.

Talent Development Centre subscribers earn 30% off Agile Training Sessions in 2016. Register here and use Eagle’s membership number BLP038YK7E

Refactor or DieEvery software system that we build is inside a dynamic environment.  The organization(s) using the software are all in a state of constant change.  The people using the software are also constantly changing.  Due to this constant change, every software system needs to be adapted to the environment in which it is used.  Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle.  Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security.  But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.

What happens when the business does not recognize those invisible qualities?  I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex.  Some people refer to this as legacy code or technical debt.

The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about.  It is pretty easy to see how this works – for someone who has a technical background.  But for those without a technical background it can be hard to understand.  Here is a little analogy to help out.

Imagine that you set up a system for giving allowance to your kids.  In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature.  After a few weeks of doing this, you realize that it would be helpful to have the date on the form.  You do this so that you can enter their allowance payments in your personal bookkeeping records.  Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment.  Then your kids want extra allowance for a special outing.  So you add some things on the form to allow them to make these special requests.  Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes.  So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes.  Your form is getting quite complex by this point.  Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances.  Every new situation adds complexity to the form.  The form expands over multiple pages.  Filling out the form weekly starts to take significant time for each child and for you to review them.  You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet.  You decide you need your own checklist to make sure that the forms are being filled out correctly.  A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version.  It takes three days, and there is lots of guess-work.  Your allowance tracking forms have become a bureaucratic nightmare.

The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step.  The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.

For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:

Technical Debt and Design Death

Technical Debt and Design Death: Part II

Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features.  If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.

I used the word “decision” in that last sentence.  What are the other options in that decision?  Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while.  Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details).  At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system.  Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.

In his articles, Kane Mar describes this like so:

It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.

In other words, refactor or die.

About the Author
Mishkin Berteig is the President and Co-Founder of Berteig Consulting Inc. He has been Mishkin Berteigtraining, coaching and consulting for organizations adopting Agile methods since 2001 and is committed to helping individuals, teams and organizations apply Agile methods. Mishkin is a Certified Scrum Trainer, and qualified to deliver OpenAgile and Agile Project Management training.  He has developed and delivered Agile training both in public and in-house seminars for over 3000 people in Canada and abroad. Courses have been as short as three hour intro-style and as long as five day boot-camp-style, and audiences have ranged from junior team members to senior executives. He has also assisted organizations of all sizes to make the transformation from traditional methods to Agile/Scrum methods (Extreme Programming, Scrum, Lean, OpenAgile).  Assistance includes Agile Engineering Practices, Agile teamwork, Agile project and product management, Agile management and executive management.

Google’s Most Popular Software Technologies

Diversification is a common technique used to reduce risk in many situations — investment portfolios, client lists, services offered — but how diverse is your skill set? Great Software Developers already know that having a variety of tools under their belt makes it easier to land the highest paying contracts. If you’re considering learning something new or brushing up on your skills, have a look at this article by Nick Kolakowski that was recently published by Dice. He reviews the top technologies as listed by Google in 2015.

While terming a particular technology “most popular” is always a problematic endeavor, Google’s gargantuan amount of search data offers some excellent insights into which technologies seized the world’s attention in 2015.

Google’s list of the most-searched software technologies last year included, in descending order:

  1. Java
  2. HTML
  3. Python
  4. JavaScript
  5. SQL
  6. CSS
  7. Adobe Flash
  8. R
  9. C
  10. GO

These rankings should be unsurprising to tech pros and Web developers; the top five technologies, for example, undergird the modern Web.

Further down the list, however, is where things get a little more interesting: Windows PowerShell (a task-automation and configuration management network), Scratch (a visual programming language), and Go (a programming language developed at Google) all made first-time appearances on the list in 2015. Adobe Flash was also new to the list, despite its age; perhaps the increased search volume was due to controversies over the platform’s security, or Adobe’s announcement that it would soon commence HTML5 support for Flash Professional CC.

For Web developers (and pretty much anyone whose job intersects in some way with the Web and mobile), knowledge of Java, HTML, and JavaScript is a given. But giving Go, Scratch, and PowerShell another look in 2016 might be a good idea; if those technologies catch on, they could climb further up the list—at which point, knowing them will be absolutely essential.

4 Key Steps to Decide on Accounting Software

As an independent contractor, it’s as important for you to manage your accounting as it is for any other business, and the right accounting software is a crucial factor in doing so.  It can be a large investment and there are a great number of options, so how do you select the software that fits your needs and matches your budget? If accounting is far from your Contractor stressed over accountingspecialty, deciding on the right one may come as an even bigger challenge.

FreshBooks recently published a blog post by guest author Adam Bluemmer, the Managing Editor for Find Accounting Software.  Withn it, Bluemmer describes four key steps to help you weigh your options.  We found the process so helpful, we decided to share it with our readers:

Step 1: define your requirements

It’s easy to be overly influenced by an immediate issue when seeking new software.  Pause for a moment to consider other issues that may have arisen since the last time you bought software.  Making a great software decision depends on factoring in these considerations.

To expand the scope of your needs, try brainstorming lists and sketching out simple process maps. These are time-tested project management techniques that can help you easily outline your requirements without the input of numerous people.

Step 2: identify your options

Once you’ve developed a solid set of requirements for your business, you’re ready to begin researching software. Here are 3 research techniques, each with their own pros and cons:

Recommendations from colleagues and family

  • Pro: a recommendation from a close source increases the chances that you are going to get an unbiased, accurate opinion
  • Con: the source may have limited product knowledge and thus, is unable to assess whether or not a software suits your needs
  • Best practice: try to find someone who works at a business with needs similar to yours.

Independent online research

  • Pro: searching reviews, product sites and user forums will provide you with many software options
  • Con: online research can be tedious. It’s easy to spend a lot of time reviewing software, only to find it doesn’t meet your fundamental requirements
  • Best practice:  once you’ve located the websites of a few products you’re interested in, use a search engine like Google to refine your key needs.

Third party software matching services

  • Pro: using a third party matching service, which offers recommendations of software to businesses, provides a quick and accurate match for your needs
  • Con: some services have costs or obligations
  • Best practice: when talking to someone from the service, verify that you can choose the number of product referrals and ask specifically how recommendations are determined.

Step 3: evaluate your choices

Evaluate your choices by asking each potential software provider how their program meets your needs.  This should immediately disqualify a number of options. Once you’ve narrowed your pool down to 2-3 choices, you should then:

  • Demo the software before investing or signing any contracts
  • Use social media and online forums to find product reviews, if you haven’t already

Step 4: make a cost-conscious decision

This means you should be conscious of all the costs, rather than just the purchase price. Potential software costs to consider include:

  • Licensing
  • Support
  • Version updates
  • Hosting

With many software solutions, especially SaaS or “software as a service” choices, these costs are bundled together. Cost savings need to be considered, as well.

Which accounting software are you using to manage your business?  Are you even using one?  Share your own thoughts and recommendations with our readers in the comments below.


 

FreshBooks_logo[1]FreshBooks is the #1 cloud accounting solution designed for small business owners. They help everyone from the most fragile of businesses (many of them one person, first time owners) to the most vibrant businesses, collecting billions of dollars. FreshBooks is designed for service-based businesses. They uphold a longstanding tradition of providing extraordinary customer service and building a product that helps save customers time, pursue their passion and serve their customers.