Talent Development Centre

Tag Archives: jargon

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

Dumb Down Tech Speak to Even the Simplest Minds

The Infographic That Will Save Every IT Contractor Time and Patience

We shared a post from Freshbooks last week that decoded web development jargon, specifically Agile Scrums, Kanban and Waterfalls. The post argued that independent contractors in web development often deal with clients and personnel who aren’t in the field, so knowing how to explain certain terms is crucial.

The same holds true in all of IT jargon, not just web development. Independent contractors often deal with non-technical people and trying to explain terms to them can be torturous. You constantly have to repeat yourself, and even then the explanations don’t seem to get through. The result is a lot of wasted time and possibly a huge test on your patience.

Thankfully, we found this infographic from Geist. It provides basic tech terms in Tech Speak, Layman’s Terms and explanations so simple your mom could understand. Our advice for independent contractors is to forward this on to those non-technical people, rather than engage in time-consuming discussions.

Tech Speak Decoded

From Visually.

Web Development Jargon Decoded: Agile Scrums, Kanban and Waterfalls

Web Development Jargon Decoded: Agile Scrums, Kanban and WaterfallsThis post by Dennis Furlan first appeared on the Freshbooks Blog on June 1, 2016

As a web-development professional, you’re often dealing with clients and personnel who aren’t themselves in the field. They might have never worked within a web-development company before, or have little experience working with a web developer.

On top of that, web designers themselves — even those experienced in website development — may have worked in a web-design company where there was only one approach to custom software development and web design. If that’s the case, you might not be aware of approaches used in other web-development environments.

Whatever the case may be, as a web developer or website designer, you may not be as familiar with the basic terms of the profession as is ideal. Don’t worry, we’re here to help! With a Web Development Terms 101 refresher, we clarify the web-design terms you need to know.

Web Development Terms 101: Waterfall Versus Agile

First, there are a couple of web-design terms that essentially define the school of software development company or environment you work in. Back in the old days of software development services — let’s say back in the time when the Pong video game would have been considered leading edge — many software development companies would have used what’s called the waterfall model of software design. This is in contrast to a term that is perhaps more familiar to web developers today: the agile approach.

With the waterfall model, a more traditional, linear and predictable approach to software development is followed. Although the term waterfall may not be completely accurate, since it conjures up images of falling over the edge, it is a term that captures the essence of what these traditional development models do, which is to have a very structured work process in which one stage of software development is accomplished before the next.

As an example, you might have a web development model that consists of conception, design, code construction, testing, and deployment. The process only moves forward when a stage is completed. So, design can’t happen until conception, code construction until design, and so on. In fact, it’s a model of product development that dates back to the manufacturing model of decades ago.

The Challenge With Waterfall (aka Why Agile?)

However, in software and web development (just as with manufacturing), the traditional waterfall model has its flaws. It is rigid, can lead to backlogs, and, if one stage in the development process breaks down, can mean everything breaks down. To solve these challenges, more agile approaches deployed in the manufacturing sector, and in web-development companies, too.

With agile, the goal is as the name suggests: to achieve greater website-design productivity with a more agile approach to web design.

So, if we were to take the same example as above, instead of one linear process that starts with conception and ends with deployment, which is the case with the waterfall model, all the processes in an agile system — conception, design, code construction, testing, and deployment — can occur at the same time using flexible and interactive teams from start to finish. The advantages to this agile approach to web-design services include:

  1. Problems can be anticipated more quickly
  2. Decisions can be made to change direction in mid-course without major disruption to the larger endeavour
  3. No single process is beholden to another
  4. Everything gets done simultaneously, in a manner of speaking — meaning the project should be completed faster

With a web development company using this agile approach, there is less a reliance on tasks and schedules and a greater implementation of processes that incorporate various components of the chain. These processes can involve what is known as a sprint, which defines (in conjunction with customer feedback) the deliverables to be achieved within weeks, and not months. Sprints allows for better feedback from the customer and a more flexible delivery of the final product and service.

As much as it might be seen as trendier or more modern to be saying that you work in an agile web-design company, there really isn’t a right or wrong approach. It really is about assessing the client’s needs and how your own web-development company best meets them. With the waterfall approach, everyone is on the same page from start to finish. With agile, it’s a more flexible, improvisational process throughout. What works depends on the situation.

The Processes Within Agile: Scrum Versus Kanban

Now, what can confuse matters even further are web-design terms that make further differentiations in process and approach. Specifically, many web developers may be familiar with website-design terminology such as scrum and kanban. Well, these are essentially examples of the agile approach, and differ in some fundamental ways.

If there is one overriding differentiation between scrum and kanban it’s that, while scrum tends to be more structured and defined, kanban makes some of these same structures optional while keeping certain broader principles intact. This basic point of differentiation can manifest itself in the following ways:

 Scrum  Kanban
Focuses on specific processes from the outset Greater emphasis on broader goals instead vs specific tasks
Establishes cross-functional teams Cross-functional teams are optional
Workloads are often pre-determined Workloads are often defined as project is underway
Limits on work-in-progress and lead times are established Limits on work-in-progress and lead times are optional
Ideal for web-development companies seeking dramatic shift to the agile approach Suitable for web-development companies seeking a less radical upgrade to agile model

Meeting Your Client’s Web-Developer Needs

Again, is there really one website development approach that’s better than the other? Of course not. As always, it depends on your web development company’s ability to meet the needs of the client. In general, if your organization needs a dramatic shift towards agile, then scrum might better help establish specific structures. Alternatively, if the processes are already there, but in need of broad incremental improvements, then kanban might be the way to go.

Regardless of which web development terms you use, it’s always important to remember to match the organizational goals of your web development company with that of cherished clients seeking web-page design that meets their specific needs.

Too Much “Corporate Jargon” Can Harm Your Job Search

Frances McCart By Frances McCart,
Vice-President, Business Development at Eagle

Have you “drank the kool-aid”?

Have you gone after “low hanging fruit”?

Do you want to “uberize” an idea?

What do all of these statements have in common?  They are all overused in today’s corporate culture.

Someone sent me this video and I found myself laughing at all the corporate jargon one uses in their day-to-day life.  The video made me stop and think… am I guilty too of using too much jargon?  I think all of us fall into a rut in how to express ourselves.  It is often just easier to grab onto a current saying rather than coming up with a proper or original way to express what we are trying to say.   We easily fall into using overused statements to express our thoughts.  I am not saying it is 100% incorrect to use these statements, but the time and place must be considered.

In my line of work, I spend a good amount of my day speaking with contractors and clients.  I find candidates in particular guilty of overusing phrases such as “I am unique because I act as a bridge between the business and IT” or “I’m a thought leader who thinks outside the box” to convey what they did at their past/current place of work.  Some candidates go as far as to pepper their whole job interview with overused corporate jargon trying to express what they did.  They leave the interview without telling the interviewer what they really did and worse — leaving them with a bad impression of who they really are… a buzzword “abuser”.

What people often don’t realize is that by constantly using overused and overhyped terms (i.e. Uber), the impact of the statement and its true meaning is lost, and so is your credibility. For example, as an independent contractor working with a variety of staffing agencies, you too probably get bored of hearing recruiters dish out lines like “I’m working for a client who offers a great culture and work/life balance” or “This position offers great opportunity for advancement”.

When going into a job interview, meeting with clients or fellow independent contractors, stop and take the time to understand who your audience is and the best way to convey your message.  Use corporate jargon selectively… or not at all.