text:
Earlier this month, Travis Kimmel, co-founder and CEO at GitPrime, joined Kishore Bhatia from SE-Radio to talk about measuring software engineering productivity.
They discussed:
- How the software industry is transitioning to data-driven management
- Why development metrics are important
- Findings from the 2017 Software Developer Productivity Survey
- How different team sizes and structures use metrics
Head over to SE-Radio to catch the full episode. And be sure to subscribe to stay up to date on all things software engineering — each episode is either a tutorial on a specific topic, or an interview with a well-known character from the software engineering world.
Here's the full transcript of the conversation:
Hello. This is Kishore Bhatia from Software Engineering Radio. Today's episode is about engineering impact and measuring productivity with Travis Kimmel. Travis is the CEO of GitPrime, a SaaS company offering engineering productivity measurement as a service. With a mission to bring visibility into software development process and bridge the communication gap between engineering and stakeholders. Travis is also involved with a lot of community work in the technology space. Welcome to Software Engineering Radio, Travis.
Thanks. It's great to be here.
Today we are going to talk about engineering productivity and metrics and specifically learn from your experience Travis working with engineering teams before, and now with GitPrime. Generally all the meaningful insights for the teams and business stakeholders measuring value and productivity. So let's start with some background establishing the team. When you blog you talk a lot about engineering impact. We're going to understand more about the common theme. Hopefully, you can share your experience and talks on metrics-driven engineering management with our listeners. But first:
What has really changed in IT, and specifically in the software engineering world, to have this renewed emphasis on measurement?
That's a great question. I think one of the things that we've seen over the last 10, 15 years is that almost every industry has moved towards quantification. If you've been in a board meeting, you'll see Sales coming in, and they've got this set of KPIs that they're tracking. Lead response time, and that kind of thing. Marketing has customer acquisition cost. Every department has a set of management metrics that they use to evaluate how they're doing, evaluate productivity at scale. That's super powerful. Engineering has been responsible for wiring up a lot of other industries to metric server management, and yet it's still the last frontier itself. It's not, you walk into a boardroom as a CTO and you're really in there telling a narrative account of some stuff that shipped and some stuff that didn't.
There's really no benchmarks to compare this quarter to last quarter. So that's the problem we're really focused on.
Gotcha. That sounds interesting, and it's really a problem that a lot of engineering managers definitely are dealing with. Give us some more insight into what's the way that you're looking at it from your experience.
As with many products, it was initially a product born out of personal need. I was an engineering manager at a startup and started with a small team where we were very much in that garage band mode, where everybody kind of knows what everyone's doing. It was super-fast, and we made decisions collaboratively. We scaled that team up to 10, 15, 20 engineers where we really started to feel the pain of not having hard data. This specific thing that you run into as you start to scale is everybody can't know everything anymore. When you get to that point it's hard to communicate with stakeholders, you get people who walk into engineering. Whether that's physically in the room or metaphorically because you're working remote and saying, "How is this feature going?" Answering that question can be super-painful if you have a really big team because it's just not obvious.
There's no way to look into a person's last two weeks of work elegantly and say, "Oh, it looks like they're making great progress." Or, "Geez, they've been stuck for three days, and they're just grinding their gears on a problem." That was the impetus for the product.
A lot of things have changed between the way of doing software development, the life cycle itself as it were. We keep hearing about springs and getting teams more agile and delivering value to their customers and validating that feedback.
What were some of the ways engineering teams organize and stay retrospective with feedback loops before that worked and how has that evolved now?
There was this funny state where you'd ask engineering for … Write up a big spec, ask engineering to go deliver on that and then you wouldn't see them for three to six months if you're lucky and possibly longer. Then often times the product came out looking radically different because no battle plan survives first contact with the enemy and that sort of thing. Agile, generally pretty awesome, was the idea of pressing those feedback loops. I think the fact that that's become an industry standard shows how valuable that is. The thing that Agile does really well is a lot of this forecasting and making sure that stakeholders are read into the decision-making and socializing decisions as they happen. So there's not this massive disconnect between engineering and stakeholders.
The thing it has not yet provided is a set of metrics to say, "Okay, it looks like our team is doing well." Most of the Agile metrics are very based on self-reporting. So the story point is this currency that evolves over time for the team, but it's weird to say, "Let's go increase the amount of storyboards were doing." Because everyone knows that the easiest way to do that is just over-estimate your tax. Every time stakeholders outside of engineering come in and say, "Okay, we're going to standardize on 40 story points per week," or something crazy. It just doesn't really go well because that's not what story points are intended for. And yet there is still this pervasive need to have some tractable way to have that conversation and say, "Okay, we want to take measured steps to improve our team. How do we do that?"
We think that that's the next natural evolution of engineering management and how engineering gets feedback. The challenge there has always been that most of the easily harvested metrics about engineering are not super-valuable. This thing that everyone's worried about which is that someone's going to roll in there and count lines of code and use that as a proxy for value, and it doesn't work. We all kind of know it doesn't work because sometimes the hardest change is like a two-line change.
So the challenge here is how do we develop a set of metrics that can give us some accurate signaling for an engineering team and help us make changes that matter at scale. How do we show — if you have a stakeholder who wakes up in the middle of the night with a brilliant idea, a change to a product that you're two months into building. That causes a lot of waste, it causes a lot of damage to engineering's ability to deliver. The software industry would be well-served by a way to quantify that waste. If you can approach that problem and say, "Look, we're happy to make these changes, but you have to understand we just invested $200,000 of product progress on this. If we take a right turn here, we're going to be $200,000 and two months behind. And here's a picture that shows you this is based on facts."
That's really our goal here, is to have feedback loops that are really good both for inside of engineering and then for communicating across these organizational lines and helping people understand what the work of doing software development is like.
Travis, you mentioned about engineering teams organized for agility and doing a lot of retrospects and feedback loops before and how different it is now. Isn't everyone already measuring against a common company goal? Let me rephrase that.
Isn't everyone measuring against their company's goal? Why measure engineering differently?
There's value in doing both. You definitely want to have everybody rallied around common goals. That's independent of engineering or anything else, that's just a good practice.
In addition to that, it's good to have a bunch of levers to look at Engineering and say, "Okay, here's the area where our team is super-strong and here's the areas where we can improve." I think without being able to measure engineering-centric metrics it's just really hard to figure out how to make things better. That ends up having the net effect of being a little disempowering to the engineering department as a whole. So when other teams are going into a boardroom with metrics that say, "Look, we have improved in the following three ways. 20% in this area, 15% here, and 10% here. And now we want more headcount."
What that means is that it's super easy for them to advocate what the ROI of staffing up their department is. When you get engineering coming in there with only narrative accounts, and no real tractable way to show the ROI of the engineering team, the unfortunate side effect of that is you're basically depending on engineering managers to be politically savvy which is not really when engineers are at our best, right? We're at our best when we come in there with a bunch of facts and data and say, "We shipped a bunch of stuff, we are slightly under-staffed here. If you give us three more headcount you can expect us to ship this much more stuff." That's a powerful place for an engineer to be because we're talking about data and hard facts.
I see. You mentioned ROI. Just for the audience can you clarify what that is?
Yeah. Return on investment. So if you're considering a request from engineering like, "Hey, we need to go and do a bunch of refactoring for a month here. If we do that refactoring we're going to move a lot faster." Often times what people hear there is they hear the engineering lead saying, "Hey, we want to do stuff that you don't value for a month." Because this technical debt is really only felt by engineering, the pain is only felt by engineering. And it's felt in our ability to deliver stuff quickly. But if you can put up a series of reports and show that the value of paying down technical debt and show technical debt being paid down over a month is that engineering moves a lot faster and is a lot more lightweight and can deliver stuff after we do that. And again, show that curve of productivity increasing after having, say a couple sprints to address a bunch of technical issues.
That's super-valuable and allows engineering to go and make these agreements with the stakeholders, and maybe it's with the product team. Whoever is really wanting more new stuff and say, "Well what you buy by letting us pay down technical debt for a month here is the ability to get more new stuff faster in the future." And then being able to back into that afterward and show that yeah we are actually shipping stuff 30% faster like we said. Very, very powerful.
I see some baseline and effort estimation to be able to get to a point where you can justify factually with what the return on investment would be for a particular effort, whether it's rewriting a particular piece of code or refactoring existing code.
Yeah, historical metrics are super-important just in general. In all of this stuff, the very first thing to do in there to do is go in there and say, "How do we develop a baseline for how we think about productivity?"
Often times the initial step there is just very kind of, brush your teeth, eat your vegetables-type metrics. Engineers theoretically want to be coding, the organization wants them to be coding. So how many days a week is an average engineer on this team able to code? You'd be surprised that it's not five, generally, right?
There's a lot of overhead that tends to go into engineering. It's more like two or three. So looking at something like that and having the rest of the org say, "Oh my gosh. When we call an all-hands meeting with the engineers that has a cost." And the cost is that they're unable to do the thing which they're amazing at.
I mean it seems ridiculously simple, but it's very difficult to look at that. So what happens instead is that people call these all-hands meetings, everybody kind of groans and knows that it's not really great for their own personal productivity. They'd rather be coding. But there's really no way to advocate for, "Hey, maybe only call the people who are necessary in here instead of having a $100,000 meeting." A little bit of data in situations like that goes a long way.
I think that's another experiential point of view that people think in generating productivity and measurement is an art. There is a lot of science behind it but there's also emotions, communication tracking involved. I see your point about how meetings take over a lot of that while you actually produce real value, real code.
Yeah. If you walk into an engineering team and say, "All right, how many people went to CS school?" Everybody raises their hand, we all raise our hand and say, "Yeah, we all went." What you learn there is how to create great code. There is a lot of artistry to that facet of it. And then if you ask that same group of people, "All right. How many people taught you how to be effective in a work setting? How many of you in here were taught, 'Here's how you advocate for stuff, here's how you work well with another group of engineers, here's how you deal with an obnoxious set of requirements like put a mood button in the app.'" Basically nobody has ever been taught any of that stuff. It's really not part of the curriculum. It's something you have to learn on the job and that's the kinds of things that we like to surface is these people-centric metrics.
Like, "one of the biggest problems in this org is just that engineers are in a lot of meetings and they don't get the opportunity to do a lot of code." Big, broad things like that.
Right, and you have to justify or at least create metrics that show how one thing adds up to value with another.
Threading that stuff all the way too, and therefore this creates value for the business, is really where a lot of the work is.
Right. I actually went through your 2017 Software Developer Productivity Survey.
What were your main findings in that survey, and how did they generate insight into the various things that engineering teams should measure?
Definitely. A lot of this was initially prompted by a product development. We went and we started with some very basic stuff like does software engineering even want metrics? There's overwhelming response in the affirmative there. Everybody wants metrics. They just want ones that are good and relevant. Then if there were good metrics they'd be very interested in knowing them.
One of the really key questions here was, "what slows you down?" If you're a developer working in the industry what are the top things that slow you down? A lot of the responses there were waiting for other people to do stuff. So human thread blocking. The bigger the organization the more you see this kind of stuff where a JIRA ticket goes into this holding state where you're waiting for approval from legal or a sign off of some sort.And maybe you switch focus and work on something else but that actually soaks up a lot of time. Task switching is super-expensive. You can only track so many open items at a time.
So that was the number one thing that people replied with. Then there are a couple others in here like meetings, inadequate tool sets. By and large we see that a lot of what's slowing engineers down is stuff that is not necessarily happening inside engineering but in those boundary lines and the handoff places between engineering and somewhere else. Having data to communicate that that's what happening is pretty powerful stuff.
Right. And the points that you mentioned about waiting on threads just like in software we've got a lot of congruency and sequential stuff that we build on. Is there some insight into how tools or engineering metrics can help bring those up?
Yeah. When you have an engineering team whose time is being soaked up by non-engineering stuff there's really … That's not felt organization-wide. It's felt by the individual engineers who have to deal with that and then also get all of their deliverables done. If you can quantify that stuff and say, "Look, our engineering team spent 30% of their time in meetings" or whatever, a bunch of other overhead and have that conversation in a more objective way that tends to be … The situation tends to resolve itself. It de-politicizes everything, it's no longer about somebody's opinion of how they want to work, it's about waste happening that nobody really wants. So again and again what we see here is that data is engineering's friend. No matter what that data is, it favors engineering because engineers tend to be facts-driven people.
We've all sat in the meeting where as an engineer we're getting out-talked by the suits. We know for a fact that something this guy is saying is wrong and there's just no way to communicate it. There's a great YouTube video to this effect where they're sitting in a room and this guy is saying, "We need you to make seven lines all perpendicular." There's some engineer saying, "That doesn't even make any sense." Over and over there's the string where facts are very friendly to engineers because that's what we like to play with. It's the tools of the trade. Engineering is this very concrete things to do. And so the more data we can being into the equation when we get asked these difficult questions like why is everything late all the time? Engineers get asked that all the time. And frequently, the answer to that question is outside of engineering.
It's not like everybody's sitting there playing foosball. That's sort of what everyone wants to think and it's just not true. The answer's a little more subtle than that. It's like, "Well because we keep shifting our target. We're not even clear down here what we're building. The specs here are so loose that we're just trying to go off of the last thing we heard. Surfacing those kinds of replies to why is everything late with hard data is very, very effective for helping engineering play the role they want to in the organization.
Right. I think the other point that comes in here is one of the more communication-driven, size-driven impact here on other teams' organize and deliver is the size of the thing itself. I've heard a lot of good things about organizing companies within different units of product in generating sales or having very horizontal, layered teams with product generating sales all part of the same track, making decisions faster, everyone being in the same group at the same time can mean more quicker decisions.
Even the DevOps feel that there is a lot of value in making sure that teams have a shared goal so there's not everyone throwing decisions at the wall or accountability is clear. But at the same time certain tasks get done faster when the teams are organized in the right manner.
How do you see that in the size of a company? Let's take an example of a startup versus an enterprise.
Sure. Well when it comes to software engineering metrics, typically small teams don't need them as much as larger teams do. You're not dealing at a point where that stuff's relevant at all. As a team grows the reason the data starts getting introduced into the equations is typically a team evolves a little bit beyond say five or six and there's team leads. We take one of the engineers, we sacrifice them. They no longer get to code and now they have to talk to people.
Very true, yes.
It happens over and over. That person needs to have some way to do that. They need to solve for two problems immediately. One is how do we communicate that we're bringing value? How do we show people that work is happening down here before a feature ships. Because sometimes that can take a while. Then the second is how do I as the team lead here focus my efforts on a day-to-day basis? Do I just go randomly pick some commits or PR just dumpster somewhat? Or can I be a little more elegant and focus on the stuff that really matters? That's sort of the first level of where companies emerge into into needing data is to have a touch of elegance with regards to managing a team. What are the important things to pay attention to today? I've got two hours here to focus on helping this team succeed. Where do I put that focus?
As teams grow even more into bigger and bigger, to an enterprise setting, really the role the data plays there from what we're seeing is large-scale change. So if you've got … Let's see, you've got a new process. You want to roll out Agile. So you do it across thousands of engineers and then people want to know how'd that go? We invested a bunch of resources in rolling out Agile. We don't have anything to report. We sort of report on our feelings like everybody seems to be happier, I don't know. Some people are sad, some people are happy. That's just not … It ends up sapping the ability to do any sort of large-scale transformation and engineering only gets small stuff. So what we see is that large teams use this when we want to go advocate for say, "Hey, we need to introduce an entirely new tool chain here.
"And we're going to do that work on a pilot project and we're going to take these metrics and see whether or not that's making any improvement, right?
Right, yep.
And then we're going to come back and we're going to say, "Okay, well we got about a 5% bump in our ability to ship features. That seems good. The products' cost is less than that so we're going to roll it out broad." So that kind of big-scale change for information whether it's new tools or new processes needs a feedback loop. That's where productivity metrics come in.
We've established the fact that visibility into engineering is a lot better when we actually do it as a data science, when we actually do it measured with a baseline and then iterate upon it. It's also good for large-scale transformations like you measured of going like you mentioned, of going Agile as a company. And then with size the importance increases.
What do you think is more important from an engineering manager's point of view when his or her team grows from a size, as you said bigger than five to slowly start getting into investigating into the more critical baselines and then building up those … I wouldn't say those metrics yet but at least the process is to get that cultural alignment.
There's a lot of different starting points and there's a lot of different ways to be successful. One thing that's generally true is that KPI-span is bad. So the last thing you want to do is go find a bunch of stuff you want to improve and introduce all that stuff.
If you can clarify what is a KPI?
Oh yeah, sorry. KPI, Key performance indicators. People say, "Hey, we're going to target these areas for improvement and we want to see everyone be better by the end of the quarter," whatever. So these KPIs, key performance indicators, get rolled out and say, "Okay, this is what we're targeting for improvement." That's good, that's a good way to use data. What makes that successful is focusing on one thing at a time.
The important thing to remember when using data for any kind of management or change stuff is that that's something that everyone has to pay attention to in addition to their job. Everyone has a full job, they got deliverables every day, they're responsible for all that stuff. And then any sort of global improvement is another layer of overhead on top of that. So you don't want to layer in like 15 things that we're going to improve by the end of the quarter because everyone will just improve that as a total beat-down.
So what you want to do instead, and what we see successful teams doing, is picking one thing that will be a high-value way to improve stuff. I keep coming back to this example because it's a good one. Let's get everyone out of meetings and back into the code. Let's try that for a month and see how that goes and see if that creates a change that we like. That could be a very simple kind of KPI. We're going to try to maximize the amount of days that everyone was able to actually go and do something in the code. Like independent of whatever that is, check some coding because that's what we're all here for and that's what we like doing. I guess the broad counsel there is no matter what size team you are if you're starting to do this data stuff start really small, introduce something like some single interesting thing, ideally that everybody …
That addresses a pain that the entire team feels from people outside of engineering to engineers themselves. And then target that one thing for improvement. Once that's successful, move onto the next thing but don't go in there and spam out a bunch of initiative stuff all at once where it's just going to create a lot of resentment.
Right. So I think it's starting small, measuring it and then high trading point those indicators to create a sense of small KPIs.
Yep. It's just like going to the gym. Anybody can go to the gym but the reason you hire a personal trainer is so that they can go in there and say, "We're going to work on your core first." And not go in there and just have a million things to do. It's really about breaking the stuff up into accessible chunks and making the problem, whatever the thing you're working on something that is immediately addressable and tractable.
So Travis, we've talked about KPIs and we also established how important it is to measure software engineering productivity, small teams, large teams, also during transformations into established baselines to be able to get a point of view on how we have improved time over time. How do you measure the engineering impact when we get into the data aspect of it?
I think there's a lot of ways to go about that. There are a couple of interesting examples we can look at here. There's this great Sufi story about how wisdom is not universal. If someone in the future came and they found a … What is that, the DSM4 that has all the prescriptions in it and they looked at that and they were like, "This is all medicine," and they didn't have any context. They could basically start giving everybody medicine without understanding the disease. That wouldn't work out really well.
A lot of what we advocate for is developing a set of metrics that really address the one or two things that your team is focused on. For example, we worked with one team that have this problem where they were engineers … It felt like all the engineers were stumbling over one another.
When we looked in at their data what we found is that there's this pattern with a culture of shipping monoliths. So an engineer would go, they work on something locally for a while, they'd have it out for a week or two and then they would check in this big … They were shocking in one massive commit which would basically create a merge conflict for every like other engineer on the product. That was super-ineffective because you get a bunch of operational overhead, people kind of stumbling over one another. We worked with those guys to say, "Look, you guys need to move more towards this taking smaller bites methodology of let's break all our work into pieces, check in five, six, seven, eight commits a day, push that stuff so that other people can rebase on it and have break points here that provide a reasonable way to back out if you run into a big conflict."
Integrate your work more often. Just like you get people … Programmers communicate at the level of code pretty frequently and so if there's this big gap between when you're communicating, "This is what I'm doing" literally at the level of code, not with words, that can be super-problematic. So when we go in there we'll look at are people just checking in these whopper commits all the time? Is that something that this team needs to improve or are they doing pretty good with granular delivery? Granular delivery tends to be a really big theme, pushing stuff up to where other developers can see it and comment on it the way that people do code review. Or large bodies of work getting sufficient code review or is that stuff getting rubber stamped? Those are all metrics that we tend to advocate that people look at and pick the one or two that can address something very immediate for the team.
Gotcha. So this is more iterative in approach to continuously check in small amount of changes and keep building upon it and integrating with team.
How should a manager introduce data to their engineering teams?
So there tends to be a first phase which is largely observational. The first phase is just to say, "Look, we've got this tool. It provides so much data about engineering, it's just data. Let's look at it." The first step is to get a baseline for where things are at. So the first step towards using data to make life better is not using the data and taking an observational stance and not trying to go in there and make a lot of assumptions. Once you've got this feel for where the team's at, what 'normal' looks like you can say, "Look, it seems like this would be a good area for improvement. What do you guys think?" We've seen a bunch of teams roll this out and the first thing… The best way to use data initially is just to help engineering get something it wants where engineering is a team.
That could be, "Hey, we want better requirement stocks." We hear that one a lot. We want to use this data to help people understand that a more fleshed out requirement stock leads to a faster implementation." So something like that, it's a great place to start.
Right. Did that vary between the engineers and the team like the role they played, junior engineers, senior engineers, team leads, managers?
How does that visibility matter to a junior engineer vs. a manager?
We focus a lot on team leads largely because they have people problems which is a lot of what we focus on. Meaning it's very hard to figure out how to provide value for your team lead to 20 people. Who needs your attention today? If you think about walking into a sprint or a daily standup everybody in the daily standup tends to say, "Here's what I'm working on." But there's no real visibility into whether that person's stuck and has been grinding on a problem for three days or whether they're making a lot of progress. Having a data layer on top of that to say, "Hey look, do you need a hand here to jump in and get you some resources? Can I ducky this problem with you?" That's pretty valuable. As an engineering lead it can be challenging to figure out how to be a good actor because you have this double bind.
Interrupting an engineer while they're working is super-costly. Like you're holding this glass palace in your head of abstractions and trying to figure out how to write that up. And then someone shoulder-taps you and says, "How's everything going?" Very disruptive. But not interrupting somebody who's been stuck for a couple days and could really use someone to talk over the problem with is also fairly disruptive. So when you're a team lead it's just … It's very hard to calibrate on how to be a good actor. Jira just tells you where people are oriented and it's a valuable tool to get a read on what everyone's doing but it doesn't really give you any insight into the engineering pipeline and the flow of work. That's really where we think that metrics are needed.
You mentioned JIRA here and that's a very important tool that a lot of teams are not just using JIRA but also very similar task tracking, bug tracking and story tracking tools being used in more and more Agile teams today. How does that translate into some of the baselines that the lead can get in when it comes to stand ups and tracking just the spring delivery itself?
I mean I think it's an essential tool at this point. I don't know if we've ever run into a team that doesn't use some form of issue tracker.
But you mentioned that there is no proactive visibility into how the sprint itself is going and if there are challenges?
I think a good metaphor might be Jira is like the navigation in your car. It tells you where you're going, gives you an estimate on when you're going to get there, gives you some directions sometimes.. It's navigation for where you're headed. It's not the speedometer or the gas or the fuel gauge or the temperature gauge or the temperature gauge to see if the engine's heating up.
All of those are also needed if you're going to be in the car driving it. That's how this stuff plays into the team. Jira is the nav, it shows where we're headed, it shows when we expect to get there. What it doesn't do is allow you to figure out if the car is healthy. If it's low on fuel. Are people getting worked too hard here? Are we under-staffed? That kind of stuff is just … It's not really a Jira problem.
Well that's pretty powerful for a software data-defined metric to work with software engineers, managers, team leads and give that insight. I'd love to dig deeper into how do you get to that meaningful data beyond the tools that are used day-to-day in our software developer life.
As an example, one of the things that we look at is code churn. So code churn is something that we mine out of Git and it basically … Let's use a non-code example here first. Imagine you write an email and you look at the email and you're like, "This is no good." So you throw it out and you write another email, a second draft. You look at that one and you're like, "This is also no good," so you throw that out. You write a third email, it's good so you ship it. We would say that there's three emails were written, one email was shipped and there's this delta of two churned emails which is interesting. And so we look at that at the level of code. We look at when engineers are rolling along, this is just a normal level of rewriting your own stuff. Like you try something, it doesn't quite work out.
But then if you see a software engineer sort of bobbing along and then there's a massive churn spike that's generally a leading indicator of a problem. Because if they're going along and they're working in the code base and all of a sudden they're spending a week re-factoring stuff that they just checked in. That's usually a sign that something is wrong. If you look at that and you say, "This person is not really prototyping a new feature so what are they working on? Are they having a hard time getting this thing in, is it a really loose definition on what the problem is?" So we look at that. That's kind of the … You could think of that as the engine heat gauge. Like how hot is this particular leg of development running? Another example would be we go back in the codebase and we look at globally if you take a team of say 50 people what percentage of code-based changes are aimed at refactoring legacy code?
And again, there's just this normal baseline, teams tend to have a normal amount of, "You've got to go in there and tweak some old stuff. Why are you shipping a new feature?" But if that starts to climb above about 50% you run into a really dangerous situation where if over half of your focus on the codebase is refactoring old stuff that's just going to snowball until all of it is refactoring old stuff. And so what happens is teams get into this weird cycle. They start throwing headcount at the problem because they want to shift stuff faster. But if you can't keep the level of just refactoring with legacy code below about half. That becomes problematic and really the right thing to do there is to set everything down, do a large architectural refactor so that that doesn't become this little cost that, death by a thousand cuts that everybody has to pay forward as they try to ship new stuff.
That metric is pretty powerful if you can actually start looking at various code churn and as you mentioned through the commits that are being made by engineering to a particular story.
Is it just code that you look at, or are there other behaviors that could be tracked through the release frequency or other meaningful data?
In that example, it's just code. Churn is specifically when I as a developer am rewriting stuff that I just checked in. There's this notion of authorship — whose code is it? But that's largely mined from version control. We do also look at a couple other sources of data currently and some interesting R&D stuff we look at a lot more. We also look at the data from the Git host so we'll look at things like how many people are being pulled in for code review? If we look at a team of 50 engineers or something and we can see that there are two or three engineers who are always reviewing every PR that's a huge bottleneck. That happens quite frequently. You have these senior engineers who everyone feels like they have to have that person's blessing. So spreading that out is pretty valuable.
Again, it has nothing to do with the nuts and bolts of software engineering. It's more the operational and people side. But it's a huge opportunity for improvement.
Then we also look at ticket data. We pull in data from Jira and we typically use that to think about things … This is not quite shipped to production yet but I'll leak it. We have one that we're working on currently called Ticket Jitter and so this is a way for us to quantify how much change happens to an issue, say a feature that you're building, while that issue is being actively developed. So we tend to think of this as bad, like the perfect implementation path is you get this requirement stock that answers all the business logic and you go on coding along your merry way. And then at the end the feature ships and everybody's happy with it.
And any deviation from that is a little bit of brain damage. The most brain damage is if you're working on a ticket while the stakeholder on that ticket is actively modifying the goal, the requirements and moving the goal posts. One of the things that we look at when we look at ticket data is the way to quantify that and say, "This ticket had a lot of jitter and that's why it's late. It's not late because the engineer was screwing around or we didn't prioritize it or whatever. It's late because the goal posts here were a moving target and we just kept coding towards that moving target the entire time this ticket was in process and that's super-wasteful. And the number of times it changed was 50 deviations in here, just a ton of commentary, it was a ton of clarification. So if we want to ship stuff faster what we need is for that stuff to be resolved before work starts."
There's pretty powerful correlation between commit frequencies and how the ticket data is actually being correlated with it. In fact that will basically become part of my next couple of questions as we move along which is in other words how do you build context for such an insightful metric for the stakeholders that are involved in making higher-level or lower-level decisions for the team?
I'd love to drill down more on a bunch of examples where you mentioned Git, you mentioned Jira, you mentioned ticket data that would probably come from something like Zendesk.
How does all of this get aggregated in a way that provides insight around how we can improve?
I mean the shorter answer here is pictures. We do a lot of work in D3 where data vis is one of our main focuses. I think one of the things that we as people who work in engineering kind of undervalue is the power of high-visibility stuff. Over and over we see value in people who can do regular updates that are visual. If you put together a release deck and let's say there's a ton of work that goes in there but you screen cap the noticeable changes in the app and you push that deck out, say, "Here's what we shipped." You do that frequently, that is so valuable.
So we take a similar approach when thinking about productivity. We believe that the best way to communicate that stuff is with a picture. If you've got a bunch of little bars and then you make a change and you've got a bunch of bigger bars that tends to be good.
Or if you can say, "We hear these stories from engineering teams where someone walks into engineering and says, 'I need a third of your capacity for this project. I've got some imperial feature …'" Imperial features are something that we use internally to talk about a feature that has a very powerful stakeholder that just comes in and says, "We're building this now." That happens all the time. If you have someone that walks into engineering and says, "I need a third of your capacity to build out this feature." Then you say, "Okay, great." You put some people on it and then two months later you're sitting in a meeting and that guy's going, "Well you didn't really give us a third and that's why we didn't get there." If you can pull a picture and say, "Actually we gave you 36.9% of our total capacity measured across these three different ways of measuring capacity, so we did deliver here. We're putting an appropriate amount of attention on it."
Again, data has this effect of de-politicizing everything. That's just delivering data insights through pictures and showing this is the work moving through the pipe. That's a lot of how we focus on making this accessible to less technical people.
That's a very powerful statement there, data de-politicizes everything. There's so much in context that applies to pretty much everything that we do as human beings and not just a software industry but overall business process management.
This was powerful. I think I'd probably love to put some links if you can provide me about the dashboards and the graphics that aggregate this type of data into more of a demo video maybe that a lot of engineering teams, managers and every individual that cares and is going through such an impact would love to have these.
So Travis. Thanks a lot for sharing that aggregate value and the graphics that you can pull from such an insightful data stream that you're collecting from different data sources on a day-to-day basis. These are all tools and metrics and processes that we run through. But this is really very valuable data that helps makes decisions.
It's been a while driving me. Our big goal here is always to thread the needle between all this data which is super-noisy and then business value. How do you correlate that with business values?
Right. There's a lot of times when refactor or relight is an afterthought or it's already happened or happening. By the time you discover why things are late or so complex you have already ended up starting on that journey. It helps if we can actually cover some of these examples on a proactive basis.
What else do you think an engineering manager can communicate around to be more proactive with historic context?
One of the things we focused on that's on here is how you take this giant wealth of data, which is not inherently all that valuable, and get rid of all the noise and find the signal in there. That stuff is pretty challenging. The thing that businesses always want to know is thread the needle between all of this Git data you have and show me where the business value comes in. There's always this disconnect between what engineering is doing and how that translates to business value. An example of that that we always refer to internally here is "The Green Button Problem." You've got this, let's say you throw in a Jira ticket and you're like, "I want all the buttons on this site to be green now." You look at it and you're like, "Yeah that's probably …" I don't know, whatever. A little CSS change, maybe it takes a half a day. So that work gets greenlit.
And then an engineer picks up that ticket and because they're a good engineer they pick up that ticket and they're like, "Well the right way to make all these buttons green is to go rewrite the entire templating engine while I'm in there. Because that's way overdue and we need to do it." The reason that they have that impulse is because good engineers want to get in there and generally improve the code base for everyone. But that stuff, there's often a massive delta between the ticket that an engineer picks up and how they approach it and what was greenlit. So a lot of what we provide is the ability to catch that stuff while it's happening, while it's in the pipe. If you look in there and you're like, "There's this ticket. There's this JIRA ticket that's like I turn the buttons green and I can see that that guy's in there doing a bunch of refactoring of legacy code and has been for two days.
That doesn't really match with my experience of turning buttons green. So being able to catch that stuff before you're three weeks deep into this massive template engine refactor and people are like, "How the hell did we get here?" That's super-valuable. Again all of this stuff is everybody following the things that make them great. What makes engineers great is the ability to tackle the real problem, not just the one that they were asked to tackle. And then what makes a team lead great is the ability to get in there and say, "Well look, I get it. Let's go see if we can get some resources to address this templating thing, because it's a nightmare. But not right now. Today make the buttons green." That prevents a lot, it's like problem interruption. You don't get to this point where people are dissatisfied with engineering and you generally have just a much healthier dialogue.
Because people are able to communicate about the actual value of a task and what that looks like in the engineering pipeline.
I see. The technical debt aspect also comes up most often in these conversations when people have historical context in the team. I'm especially interested in also knowing how does this help new engineers when they come on board and we're slowly going towards the digital and the millennial context here. To understand what is more productive at this point in time versus sometimes it's also about what is the right thing to do.
I mean one of the things that's kind of nice is the ability to look at something that happened a long time ago as a reference point. If you've been on a team for more than about a year or so you all remember that period where … I don't know. Maybe you had to deal with someone else's code and clean it up and it was a nightmare for a month. Being able to dive into data forensics and go back and say, "What did that look like? What does it look like when our team gets tangled up in a really deep refactor," from the perspective of all these metrics. If you can go back and find these canonical examples for your team of a month of brain damage in March because we all got caught up in getting rid of Angular and moving to React or whatever it is then you can get a feel for what that pattern looks like when it starts to spin up again.
You can head those things off and say, "Look, it seems like we're getting ensnared in another one of these issues. Let's figure out whether or not we actually want to tackle that now or just get this deliverable off and then do it in a month," or something.
Also you mentioned something about gamifying for the sake of providing rewards at an individual level. That's something I've seen before with CI tools and how different badges in the world get accumulated with unit test coverage and how frequently are you checking something? The only thing I was looking at in that sense was does this measurement continuously improve the team as a collective versus an individual with some more positive reinforcement. You clarified that it's more of a collective team effort and you want to make sure that you're making these decisions together with factual data.
Our general approach here has not been so much to focus on the individual engineer. We don't want people obsessing about this stuff. In fact we've strayed away a little bit from any kind of gamification for the individual. It's sometimes the beginning of a disturbing trend. It's a thing that kind of lends itself to abuse. You don't want to infantilize your workforce. Games are awesome, I love games. But there's this other component of work which is distinct from that and everyone's trying to rally around a work goal. It doesn't need to be dressed up as a gamified metric. So we've tended to resist that and focus more on metrics that's like how do you … If we presume that there's a manager or a team lead here who really wants to empower their team and find out what's blocking the team and find out what's holding them back and get rid of all that stuff what metrics would we build then?
That's entirely where we focus. From our view, a new engineer to your question here, a new engineer coming into a team, what they would experience in a team that has really robust metrics is they would have a lead that had a pretty darn good idea of one, where they could jump in and provide value. Like, "Here's where our team is a little weak and we need you to shore that up." And then two, how to onboard them quickly. They would know what good onboarding looks like because they would have this history of people who were onboarded well, what that looks like and what areas of the code base they were in, how we did that. A lot of how the individual engineer experiences value in a data-driven management setting is by managers doing less damage. Maybe that's the take home point here is, ideally what we're doing is improving a manager's ability to get out of the way and get other obstacles out of the way on behalf of the team.
So it's not really a direct consumption of value by an individual engineer because that stuff can get a little weird. If someone comes in and says, "Hey, what I really need you to do is check in ten more lines of code on average every day." Like, "Okay. I'll make my methods longer." That's not really the pattern we want to encourage.
Totally. I think earlier in the session we were talking more about how small teams and large teams look at metrics differently, look at productivity in a different manner. There's also a lot of data that gets generated with tools and processes as individuals create more and more value-driven sprints. How does the overall model work when the team itself is totally the more…
Are there certain specific examples that you can bring on for just remote teams?
Yeah. Ideally yeah. The way that the individual narrative gets brought in there is asking questions like, "Well when is Bob kicking butt? When is he at his best and how do we get him to do more of that stuff?" Because generally that tends to be a really good outcome for everyone. Yeah definitely. We tend to be a big fan of the idea that remote can be just as successful as on-site. The reason for that is that just because a developer is sitting in a chair doesn't mean you know anything at all about what they're doing. A developer sitting in a chair staring at a screen surfing Reddit looks exactly like a developer sitting there cranking code. This impulse to get everyone in a room is not necessarily inherently valuable. The real value comes orthogonal to that which is defining things really well.
Remote teams benefit a lot from metrics-driven environments because you can answer for deliverables. If it's very easy to go, "Look at what the guys over in Europe did before you got up," and it's just trivial that's great. Without a metrics tool that can be very hard to do. If you wake up and you've got a team of 20 and they're all in Europe and you're in San Francisco and you want to figure out, "What did they accomplish today?" That's actually just a hard thing. It's a very simple question, it should be very trivial to answer but it's not because the tool set that allows you to get a feel for that, the radar doesn't really exist. So that's the value more than anything else that remote teams experience from data-driven stuff. It just gets incorporated into the workflow and I think remote teams and on-site teams benefit about equally from having less interruptions and having data be the thing that drives everybody's feeling of whether or not progress is happening.
Often times remote teams run into this challenge which is like, "I just can't tell if they're working." I think that's what everyone worries about with remote teams. Are they doing anything over there? If you've got a set of data that says, "Yes." That's great, that just totally solves that problem.
That also leads us into a pretty interesting view on metrics overall for engineering teams. We talked about engineering impact in general. There's a lot of measurable business objectives or OKRs that the teams own from larger company goals. I want to understand more from these different roles how metrics play a role.
How does the VP of engineering see that metric versus HR or a business stakeholder that's basically done a revenue number on it?
Currently we serve engineering and so our view of the appropriate consumer for data about engineering is somebody within engineering. What we'd ideally like to see is that the VP of engineering, if HR is brought into the equation it's because the VP of engineering brought them in. Not because they're self-serving on a bunch of data. What we like to see is engineering-led discussions about engineering data. That tends to be a pretty healthy pattern. I mean it doesn't even matter if it's engineering-centric. You don't really want your HR team going in there and staring at your sales data, otherwise they'll start to, I don't know, think nasty thoughts about the week or something. I don't know. There are some great HR use cases but in our view that stuff tends to be very big-picture strategic stuff and not tactical metrics.
So the ideal way to present that is more in the boardroom context where someone from engineering has gotten together a bunch of very useful data, put that stuff together in a consumable slide deck and then it's shared with the rest of the org. As opposed to somebody from outside engineering self-serving data about engineering.
Right, that's a pretty powerful way to take some of these engineering metrics into a more strategic viewpoint when generating say factual and reasonable arguments.
Definitely. We have this impact metric which you're referring to which we have developed that takes a lot of different stuff from code-based into account and what we're trying to … We're measuring there is it's a proxy for movement in the code base. How much code are we pushing around? Not just lines of code but are we editing a lot of different stuff here? Are these big broad changes? Are we hitting fundamental parts of the code base here? So when we look at that and we look at the overall activity of engineering we can use that as a bellwether metric to see how successful engineering is in moving the code base forward. Just in bulk. So using that as a bellwether metric is very effective. The way that that's used typically is people will go in and advocate again for a particular tool chain and say, "Look, we need to bring in Circle CI and whatever else.
"We need to bring in this entire tool chain and if we do that we're going to get a massive bump in our ability to ship stuff." If you go in there and you measure something like engineering impact and show, "This is before, this is after," typically what we see is when people have the ability to measure engineering work in aggregate and take measured steps to improve it we typically see about a 20% boost in engineering productivity over the first six months. It doesn't really matter how you measure that boost. You could measure it in less employee attrition. In general if you target something very specific the effects of that are spread across whatever KPIs you may be looking to improve.
Have you seen engineering, especially with the impact metric in general, going in to cause a strategic change in direction be it technology evaluation or change in product or specifically anything that has to do with how the company looks at revenue generating value?
Well we typically stay away from things like code complexity metrics. Our focus is really on the people. What we want to do is provide a deeper view into the team as a group of people moving work through the engineering pipeline. So it's a little bit of automation around using this as a radar tool. Like where should I be focusing my attention? We don't tend to serve up a ton of automated alerts because that stuff becomes noisy really fast. Instead what we do is give people a lot of data at their fingertips to answer questions as they come up. Like, how's my team doing? Where can I weigh in today? We view ourselves as a tool for amplifying engineering leaders as opposed to we don't really want to automate away management. We want to empower it and help it do things that are good.
That sounds like an important company-level or strategic metric that can easily be influenced by these engineering metrics. So thanks for sharing that example. You mentioned something about the systems or the data sources that you collect the information from. I've seen a lot of automation done as part of the software development life cycle itself. A lot of the process and release management efforts that are being made in this point in time is to actually remove human decision-making from the more day-to-day repetitive tasks.
Where exactly is automation coming into the picture here as you make sense out of all this data?
Our goal with regard to the automation piece, our goal is less to automate away a particular part of engineering or function there and more to give engineering leaders power tools to do their job better, to make it easier to gather the data that they want and to generally be good.
Right, thanks. I think we've covered a pretty good amount of metrics, different data sources, how small, large, medium-sized engineering teams can actually use more and more of the impact influencers and tactical and strategic decisions both for the engineering teams as well as for their organizations. Do you have any best practices for both engineering and business teams where they have actually started measuring value or improving efficiency? I actually look at the word effectiveness more importantly than just efficiency. Do you have any such best practices just in general from your learnings?
Yeah. Again I think the biggest thing is to start small. There's that old joke, how do you eat an elephant? One bite at a time. Over and over what we see is people who focus very narrow on something to improve first, especially when you introduce a bunch of data. That's much, much better than getting kind of distracted and focusing on five things at once. Again it's important to keep that compassion piece and remember that if you're saying, "The team as a whole needs to improve across this one metric," that's a thing that people need to pay attention to on top of their job which is shipping deliverables and writing software and all that stuff. You really can't expect people … A manager cannot expect an entire team to track all the stuff that they're tracking. It's just not fair. It's the team lead's job to track all that stuff.
A lot of times the individual contributors on the team, they've got their own job. So really you want to keep all this change stuff as lightweight as possible on the team and the way that we see people doing that well is narrow focus. Do it iteratively. Have a cycle where you focus on one thing, get your pattern going there, focus on the next thing. Don't create more overhead for your team.
I see. I think we got some good best practices here Travis. I wanted to just run through the goals here and see if we actually want to actually add anything else that I haven't covered here or if from your experience you want to actually guide some of the other things to look at. We did discuss the myth that engineering productivity and value is an art. We actually looked at how some of these challenges that the teams run into in delivery pipelines and measuring feedback loops can actually be driven through very hardcore metrics that are systems process and tools-driven. Also you covered the engineering productivity and metrics in general for different sizes of teams and how KPIs can help evolve as the team grows into different areas within an organization and some of the best practices for the leaders involved in improving the effectiveness of all of these processes that are being put in place. Is there anything specific to the software delivery that you want to add here?
I mean not really. We covered a lot of ground there. I think we did a pretty good job.
Awesome. Thanks a lot for that. I think there's a lot of current and evolving trends that we saw here and I'm really looking at putting in some links for the audience here just so that they can see some of the demos also of how the metrics get dashboarded, the graphs that can actually show some aggregate value here and make insightful decisions helpful.
Definitely. In fact Ben probably has some really good resources for you. You should follow up with him.
Just for the audience Ben is also a co-founder in GitPrime where Travis works. What's your go-to reference for all things engineering where you go for learning more about what kind of data should you dig in and start figuring things out in more evolving trends?
I mean shameless plug here, I actually get a lot of that from our newsletter which is pretty good. If you want to check on it we do not shamelessly plug ourselves or anything. We roll up industry trend data and then typically our article's from other people or whatever's hot at the moment, ship that in a newsletter. I read that thing religiously. Other than that it's a lot of the same thing that everyone is doing. I'm just looking at Hacker News and that kind of stuff.
I've put the link to the newsletter here. I know that you blog on GitPrime. Is there any other way the audience can reach out to you?
Yeah. The best way to do that is if you want a little tour we're happy to do that stuff. You can grab a demo on our site, we'll provide a bunch of links here and then I'm always on Twitter. If you want to hear me directly I'm @traviskimmel on Twitter.
I'll put your handle there. Thanks a lot Travis for sharing this insightful journey with us on how you've learned software engineering metrics and the art of measuring it and improving upon this. I'm sure everyone has learned a lot in this particular show. So thank you.
Absolutely. It was great talking with you. Thanks for your time.
Thank you. For Software Engineering Radio this has been Kishore Bhatia. Thanks.
Thanks for listening to SE Radio, an educational program brought to you by IEEE Software Magazine. For more about the podcast including other episodes visit our website at SE-radio.net. To provide feedback, you can comment on each episode on the website or reach us on LinkedIn, Facebook, Twitter or through our Slack channel at SERadio.slack.com. You can also email us at firstname.lastname@example.com. This and all other episodes of SE Radio is licensed under creative commons license 2.5. Thanks for listening.


text:
Here are some of the services Scarlett offers:
Kabbalistic Healing
Based on centuries old wisdom and teachings, Kabbalistic healing can quite literally transform your life. An understanding of these teachings, with Scarlett as your Sheppard, will consist of four steps - each with its own special significance. Then, with this new awareness realized in both your heart and mind, youll discover a very personal relationship to the spiritual nature of the universe.
That will be a splendid moment for you a joyful experience that will resonate beautifully throughout your being.
Intuitive Counseling
As we move through the avenues of life, we all face a multitude of choices and directions. Which is best for you? Often, a fork in the road offers a perplexing decision. Which way is best?
Scarlett, becoming as one with you and again acting as your source of understanding, will help direct you.
I want to say how we are grateful for your difficult input; our team members commend you for your boss participation and for your continuous support of this lifesaving law.
http://www.tileandgroutgurus.com/texas/tile-and-grout-cleaning-in-texas-city-tx/ grout cleaners in Texas City Tilenadgroutgurus.com grout cleaning companies in Bowling Green KY http://www.tileandgroutgurus.com/montana/tile-and-grout-cleaning-in-bozeman-mt/ tile cleaners in Bozeman grout cleaners in Hanover Park IL tile and grout cleaning Hanover Park http://www.tileandgroutgurus.com/florida/tile-and-grout-cleaning-in-melbourne-fl/ tile cleaning Melbourne http://www.tileandgroutgurus.com/north-carolina/tile-and-grout-cleaning-in-gastonia-nc/ grout steam cleaning Gastonia NC grout cleaners in Lincoln tile and grout cleaning in Lincoln http://www.tileandgroutgurus.com/minnesota/tile-and-grout-cleaning-in-saint-paul-mn/ tile and grout cleaning in St. Paul http://www.tileandgroutgurus.com/ohio/tile-and-grout-cleaning-in-springfield-oh/ tile cleaning companies Springfield tile and grout cleaning in Billings MT tile and grout cleaning in Billings grout cleaning in Franklin TN grout cleaning in Franklin grout steam cleaning grout cleaning Pine Bluff grout cleaning New Rochelle NY tile cleaning companies New Rochelle grout cleaning Flower Mound TX tile cleaning Flower Mound http://www.tileandgroutgurus.com/massachusetts/tile-and-grout-cleaning-in-somerville-ma/ tile cleaning companies Somerville http://www.tileandgroutgurus.com/arizona/tile-and-grout-cleaning-in-yuma-az/ grout cleaning in Yuma AZ tile cleaning in Kalamazoo tile cleaning in Kalamazoo MI tile cleaners tile and grout cleaning Johnson City
In her counseling she will help you determine the route that will bring you most quickly and easily to a new clarity of your lifes course.
With Scarlett, this ability is not only intuitive, it is a gift that is both rare and precious, and one that she openly will share with you.
Alternative Healing
Scarlett West has revealed to literally hundreds of her clients the fact that alternative healing is both a unique and unspoiled concept. But individual willingness is the key. You must be open and willing to participate in the four steps of healing Scarlett will share with you. When you do that, youll find yourself transported to a wonderful place that will forever remain open to you. And that place is the source of all true healing.
Holistic Healing
The premise of holistic healing is, in the most simple of terms, becoming captain of your own ship. Taking charge. That action, coupled with the guided steps to wellness Scarlett West will provide, will enable you to heal yourself. But she does encourage and welcome the participation and observation of a medical professional in this process. The fact that Scarlett is here today and able to extend this invitation, is a vivid example of holistic healing she applied to herself. Its a remarkable story shell be happy to share with you.
Business Consultation and Guidance
Beginning with the sometimes forgotten fundamentals of focus and intention, Scarlett will show you and your group how to work as more effectively as a team; how to incorporate acceptance and fostering of different personalities as you reach for new success.
The result will be a business plan for personal achievement and organizational accomplishment.
You may wish to schedule the presentation of a remarkable Scarlett West seminar. Available in various time and day lengths it will not not only fascinate and electrify, it will create new dimensions of self-realization.
Motivational Speaker
Shes been called the cheer leader of the universe and it is a fitting and apt description.
Scarlett can ignite a renewed passion in people for their work.
She sparks the energy needed to answer the challenges that confront all of us in the complexity of our professional and personal lives.
More than just inspirational, Scarlett brings to her motivational sessions an enthusiasm for life that allows us to become whatever we want to become.
Click here to find out more...
Scarlett West 877.956.8800 [email protected]
About Scarlett | Counseling | Rates | Contact | Message Board | Press | QA's | Guest Book | Testimonials

subset: commoncrawl


text:
GT Bank - Employee Review
The Good
Good environment.
Well known bank that constantly invests in technology
The Bad & Ugly
Promotion is subjective
Staff is unmotivated
Long hours and no work life balance
Advice to management
Make the promotion process fairer and more transparent
All the employer reviews on CorporateGist.com were submitted anonymously. You can add your anonymous review HERE


text:
With a strong city focus, this toolkit, developed by ICLEI and The Rockefeller Foundation, is targeted at city governments and their role in catalysing community building. It provides a streamlined process that is simple and yet rigorous, and which can be implemented by the cities themselves, with only minimal need for external support.
ecoBUDGET is an environmental management system, specially designed for local authorities based on local environmental resource budgeting by which local governments can identify and prioritise environmental issues, set targets and monitor the achievement of these targets annually through a environmental master budget to improve accountability and transparency. It does not give a monetary value to the environmental resources, but uses environmental indicators to keep the use of resources within the limits of the environmental budget. The first ecoBUDGET model was created as early as the mid 90's and was constantly improved with use that has already been successfully implemented in several European local authorities. It has also been adapted for use in Asian countries and has been implemented successfully in Guntur in India, Rajshahi in Bangladesh, Thimphu in Bhutan.
The Ecomobility Readiness Assessment tool has been developed for the project to assess the different components of a city's readiness for implementing NMT projects. To ensure that all aspects are captured in a comprehensive and structured manner, the tool covers a series of questions divided into 5 'E's: engineering, education, encouragement, enforcement and evaluation. Each 'E' in turn has questions pertaining to planning, policy, institutions, financials and implementation.
The IUWM process promoted under the AdoptIUWM project, is the application of an Indian version of the framework developed under the research project 'SWITCH: Managing Water for the City of the Future', of which ICLEI European Secretariat was a partner. The SWITCH Project worked with twelve cities around the world, including four from Europe and looked at implementation of an integrated strategic planning process for sustainable urban water management.
The Indian adaptation of the Integrated Urban Water Management (IUWM) toolkit would be launched in the last quarter of 2015. Watch out for this space!
GreenClimateCities program offers Local Governments a process and tested methodology tools, guidance and technical support on Low Emissions Development. It's built on more than 20 years of experience. It's a platform to improve local-national dialogue and cooperation to effectively plan, implement, monitor and evaluate local climate action. GCC is a clear and flexible methodology covering 3 phases: Analyze, Act and Accelerate - outlining how low emissions options can be identified and integrated into urban development policies, plans and processes.
The GPC provides the most comprehensive greenhouse gas (GHG) accounting and reporting framework for cities around the globe. Local governments can use this consistent standard to: set emission reduction targets, track performance, respond to regulations and requirements of local GHG programs, build and report GHG inventories which are compatible with international standards. It also allows horizontal and horizontal aggregation of GHG emission related data across sectors and sources, enabling cities to build more effective climate strategies and track GHG emission reduction from actions to access climate financing.
ICLEI's online GHG emissions inventory tool, HEAT+ helps local governments account for GHG emissions, Common Air Pollutants (CAP) and other Volatile Organic Compounds (VOC). The accounting and database capabilities of HEAT+ have helped several local governments make informed decisions in formulating targeted action plans by leveraging measures that offer the highest and most cost-effective impact in emissions and pollutant abatement.
The carbonn Climate Registry (cCR) is the world´s leading reporting platform to enhance transparency, accountability and credibility of climate action of local and subnational governments. It is designated as the central repository of the Compact of Mayors launched at the Climate Summit 2014. It enables Cities to publicly and regularly report their local climate action developments such as greenhouse gas (GHG) reduction commitments, emissions inventories and climate mitigation/adaptation actions.
The Solutions Gateway is an online resource platform for Local Governments where they will be able to find possible Low Emissions Development (LED) Solutions for their cities. It contains sectoral and cross-sectoral packages of activities, structured along Local Governments' responsibilities and spheres of influence, to support cities in the development of low-emission strategies, plans, and projects. The Solutions Gateway contents are based on proven technologies and practices, distilled into Solutions and Solution Packages which are drafted by experts of the respective field, and peer-reviewed. This resource is being developed and tested under the Urban-LEDS project, funded by the European Union, and jointly implemented by ICLEI and UN-Habitat.


text:
Date published: November 30, 2017
Examination Papers Policy Revised
The University's Quality and Enhancement office have recently revised the Assessment and Feedback policy.
As such, all future papers will not be available to be uploaded onto the website for research until after the resit examination period has taken place.
Schools have to give a permission to display exam papers on the web, as before.
Thank you
Timetabling and Examinations


text:
In the beginning of Genesis we find the code of the word:
Twin about the Twin Towers of September 11 but also found in the first chapter of Genesis, the forgiveness of sins through the offering of God and the call to repentance;
In the word of God, nothing is coincidence and everything has a divine purpose of reconciliation and repentance.
Genesis Chapter 1 בְּרֵאשִׁית
|א בְּרֵאשִׁית, בָּרָא אֱלֹהִים, אֵת הַשָּׁמַיִם, וְאֵת הָאָרֶץ.
|1 In the beginning God created the heaven and the earth.
The Aleph and Tav are after of the word where says: God
"The first and last, the beginning and end"
The same occurs in Isaiah 44:6
Thus saith the LORD, the King of Israel, and his Redeemer the Lord of hosts: I am the first, and I am the last, and beside Me there is no God.
The first and the last are the Messiah who is the Word of God
Isaiah Chapter 43 יְשַׁעְיָהוּ
The Letter Codes Spells: YESHUA
The perfect balance with the scriptures:
John 1:1
In the beginning was the Word, and the Word was with God, and the Word was God. 2 He was in the beginning with God. 3 All things were made through Him, and without Him nothing was made that was made. 4 In Him was life, and the life was the light of men. 5 And the light shines in the darkness, and the darkness did not comprehend it.
"Urim and Thummim" the perfect light of the revelations.
The Light of the Bible expanded their Spaces:
The Lion of the tribe of Judah is the one who opens the seals of the Book of God:
"Behold, the Lion of the tribe of Judah, the Root of David, has prevailed to open the scroll and to loose its seven seals"
It's amazing how the Messiah appears from the beginning to bring redemption and restoration for the sins:
1.Start with the first letter שָּׁ after the Aleph and Tav counting every twenty-six letters
2.Start with the first ת before the Aleph and Tav counting every twenty-six letters.
Genesis Chapter 1 בְּרֵאשִׁית
1.The codes spells; תרֶוְמֶהִ : Gift or Offering
2.The Codes spells: שָּׁוּפֶר : "Shofar"
The lion of the spiritual shofar
Yah Bless!


text:
More Highlights for Jay Jennings
The Making of Take Me Out to the Bulls Game 4K
"Take Me Out to the Bulls" game is a half-hour WRAL Documentary that immerses viewers in the experience of visiting the Durham Bulls Athletic Park and watching America's most famous minor league baseball team play a game.
Employing multiple cameras and even a drone over a four-game home stand, the documentary offers perspectives of the DBAP and a Bulls game that a typical fan in the stands would not see.
The documentary also goes behind the scenes to let viewers see the entire production that goes into creating the Bulls experience, from coordinating the on-field events between innings, putting replays and other images on the video boards and shooting off the fireworks. Viewers will get an exclusive look into the control room where those events are managed and even a peek into the Bulls locker room as players prepare for a game.
Throughout the program viewers will hear from members of the Bulls' staff, including the head groundskeeper, PA announcer, manual scoreboard operator as well as the team's manager, a star player and fans.
"Take Me Out to the Bulls Game" was originally produced in 4K, or Ultra High Definition, making it the first locally produced program in the country in that format.
Although the documentary was shot in 4K, this broadcast will be in normal high definition.
Narrated by WRAL News anchor David Crabtree.
Dreams of Gold NC Olympic Festival 1987
After several years of dreaming, North Carolina landed the Olympic Festival for 1987. The opening ceremonies took place on July 17, 1987 in Carter-Finley stadium in Raleigh. Athletic events were held in nearby cities. Greensboro hosted figure and speed skating. Durham was the site for track and field, soccer and wrestling. Chapel Hill hosted basketball, gymnastics, and swimming. Cary was home base for archery. Raleigh was tapped to host diving, boxing, and equestrian. Kerr Lake was the site for yachting.
WRAL Sports anchors Tom Suiter and Bob Holliday host this special broadcast, Dreams of Gold, leading up to the festival.
Capitol Broadcasting Company was a Grand Patron sponsor of the Festival.
Aired: July 11, 1987
Grape Expectations documentary about NC wine industry
"Grape Expectations" examines the economic success story that is the North Carolina wine industry. Meet the pioneers of the industry, learn how the industry is generating revenue, examine the sustainability of the industry's growth and explore the wide variety of wineries and vineyards that span our state from the mountains to the coast.
Hosted by WRAL reporter Monica Laliberte.
Produced by Clay Johnson.
Photographer/editor Jay Jennings
Aired 2012.
Last UNC Men's Basketball Game in Carmichael Auditorium
The last UNC Men's Basketball game in Carmichael. UNC vs NCSU. January 6, 1985.
Carmichael was known as one of the loudest arenas in the country while the Tar Heel men played there. The architecture of the building had a low roof and a student section that ringed the court.
UNC Men's Basketball coach Dean Smith led North Carolina to its arena-opening 82-68 victory over William & Mary in 1965. UNC player, Bob Lewis, made the first shot in Carmichael.
On January 6, 1986 North Carolina Coach Dean Smith led his Tar Heels to finish its 20-year stay in Carmichael Auditorium the way it started – with a victory. The No. 1 and undefeated Tar Heels defeated rival North Carolina State 90-79. A few weeks later, January 19, the Tar Heels started playing in the Dean Smith Center, AKA "The Dean Dome." That first game was against Duke.
The Tar Heels record Carmichael Auditorium, AKA "Blue Heaven" was 169-20.
Who made the final basket at Carmichael? *Spoiler Alert*
NCSU basketball coach Jim Valvano made a lay-up basket after the game. He claimed bragging rights to be the last one to make a basket in Carmichael.
Jay Jennings and Russian "Strangers in the Night"We conclude our TBT Russian theme with another news trip to the "land of the bear." It is 1992 and our intrepid international correspondents are WRAL News anchor Donna Gregory and photographer Jay Jennings. The name of the country has


text:
the last kreator re-press before we hit the new release "gods of violence". this time it is "enemy of god" from 2005. just like "violent revolution" i didn't know the band's eleventh full length record when i ordered a copy. in the meanwhile when i waited for the record to arrive i didn't listen to it via the net as well, because there is nothing like experiencing new old music by dropping the needle on a vinyl record. so when my pre-order package arrived timely on friday - i ordered "enemy of god" together with the new album from nuclear blast - i was eager to set the music free.
the "enemy" doesn't disappoint at all. a very strong album by this german thrash institution. twelve full songs, no interlude or instrumental, just straight forward metal with the right feeling for classic solos and melodies. "impossible brutality" and "voices of the dead" are two fine examples of what amazing song writing this band is capable of. the record was recorded in andy sneap's backstage studios in derbyshire, england. actually mille petrozza wanted to record the album completely analogue but sneap changed his mind. petrozza's idea was implemented in 2009 on "hordes of chaos".
analogue recorded or not "enemy of god" sounds real good. a modern and forceful production like i have expected from an andy sneap piece of work. the artwork was crafted by joachim luetke, who was also responsible for dimmu borgir's "death cult armageddon" and others. i mean, it won't become my favourite style of art but i like it for what it is, definitely better than the visuals for "hordes of chaos".
the presentation is solid all the way through. a gatefold sleeve with cool artwork inside and double 180gr vinyl housed in printed dust sleeves. i opted for the regular clear red vinyl version for "enemy of god" and am quite satisfied with it. looks real nice. so, this was it with the latest re-issues of three great kreator records. i am really looking forward to listen to the new album. well, i think this is just what i will do after posting this entry. smell ya later. steamhammer recordings. 2005/2017.


text:
The Max Planck Institute for the History of Science (MPIWG), Berlin (Dept. III, Director: Prof Dagmar Schäfer) seeks an outstanding scholar for the position of a
Research Scholar
(TVÖD E13/E14, comparable to assistant professor/associate professor).
Starting date: 01 September 2014
The position is for three years, with the possibility of renewal.
Candidates from all areas researching issues relevant to the history of science and technology are welcome to apply. Current research projects should be relevant to the agenda of Dept. III and its upcoming projects (see http://www.mpiwg-berlin.mpg.
Candidates should have a doctorate in hand and a strong publication record. Evidence of intellectual versatility, in keeping with the departmental projects and its interdisciplinary and trans-regional research agenda, is required.
The MPIWG is an international, interdisciplinary institute. International experience is highly desirable. The administrative responsibilities of Research Scholars are decided in consultation with the Director and shared with other members of the scholarly staff. There are no formal teaching obligations, but the Institute and Department hold regular colloquia. The MPIWG provides excellent support for research, including travel funds and the possibility of organizing conferences on topics related to the Research Scholar's interests. Salaries are commensurate with academic experience and qualifications.
It is expected that candidates will be able to present their own work and discuss that of others fluently in English. Applications may be submitted in German, English, Chinese or French.
Candidates are requested to submit a cover letter, curriculum vitae including list of publications (designating the five most significant ones), writing sample (article, book chapter; maximum 10,000 words), description of current research project (maximum 1000 words) and names of three (3) referees to:
Note that only electronic submissions will be accepted.
Deadline for submission: 05 December 2013
Scholars of all nationalities are welcome to apply; applications from women are especially welcomed. The Max Planck Society is committed to employing more handicapped individuals and encourages them to apply.
For questions concerning the research project and Department III, please contact Prof. Dagmar Schäfer ([email protected]); for administrative questions concerning the position and the Institute, please contact Ms. Claudia Paaß, Head of Administration ([email protected]


text:
"There are many facets to sepsis, but the one we have focused on for the past 10 years is the plugging of capillaries," says Dr. Tyml. Plugged capillaries prevent oxygenation and the supply of life-supporting materials to your organ tissue and stop the removal of metabolic waste product. Plugged capillaries are seen in organs of septic patients. These organs may eventually fail, leading to multiple organ failure and death. Dr. Tyml's lab was the first to discover this plugging by using intravital microscopy, a technique Dr. Tyml pioneered in Canada.
According to Dr. Tyml's most recent publication, oxidative stress and the activated blood clotting pathway are the major factors responsible for the capillary plugging in sepsis. Through his research, Dr. Tyml has discovered that a single bolus of vitamin C injected early at the time of induction of sepsis, prevents capillary plugging. He has also found that a delayed bolus injection of vitamin C can reverse plugging by restoring blood flow in previously plugged capillaries.
"Our research in mice with sepsis has found that early as well as delayed injections of vitamin C improves chance of survival significantly," explains Dr. Tyml. "Furthermore, the beneficial effect of a single bolus injection of vitamin C is long lasting and prevents capillary plugging for up to 24 hours post-injection."


text:
What do we do?
We have full video production capabilities from concept through to distribution and are known for our professional approach and delivery of outstanding video content that includes training and education resources, business insight and promotional videos, documentaries and television advertising.
Who do we work with?
Cornerstore Media Productions create high quality video productions for clients within the education, community and business sectors. We work with our clients to create engaging videos that inform, inspire and motivate.
Where can we go?
Cornerstore Media Productions is based in Bendigo and regularly takes on projects across Victoria as well as interstate. We are more than happy to work with you anywhere in the world particularly when a nice beach is involved 🙂
A recent study by Microsoft showed that the human attention span has dropped to around eight seconds. That one second less than a goldfish! Video allows you to get valuable information across in a short amount of time without putting anyone to sleep!
Regardless of whether you work in the business, community or education sector, one thing will remain certain…clients, customers and employees want to be inspired! It's the magic ingredient that makes what we do matter. Video can cut through the static. Make people think, laugh, question and care…be inspired to take action.
Nearly all the information we believe is important enough to share with others is intended to encourage some sort of action…change a behaviour, buy a product, join a cause, go on a holiday. Video Content gives us more tools to motivate others to take action. Footage, Graphics, Music, Human faces. If its important enough to share, video will give it your best shot at making a difference.
Comments are closed.


text:
Have just noticed in the Navigators service file that Sgt P.M.Brown`s number was R/97040 not R/9740 as per form 765.
Hi All,
Sgt P.M.Brown R/9740 RCAF
Would anyone happen to have any info on this Canadian. He was involved in an accident at Tiree in Beaufort EK973 on 21 April 43 where his hands and face were severely burned. The aircraft was 5 OTU and I have all the details needed on this and other crew members, but can`t find anything on Brown. I can`t find him in Geoff`s list so think he survived the war, but was perhaps invalided out due to injuries?
Any help would be great appreciated. Even his Christian name would be a start.
Have just noticed in the Navigators service file that Sgt P.M.Brown`s number was R/97040 not R/9740 as per form 765.
Were any of the others Candaian and badly injured or killed? The names might appear in Canadian Casualty lists as injured?
That said I searched Flight global for P. M. Brown's but none showed up.
Dennis Burke
- Dublin
Foreign Aircrew and Aircraft Ireland 1939-1945
R97040 W/O Percy M. BROWN RCAF.
Deceased: December 6th, 1986.
Age: 67
Legion Branch: Harry Miner VC Branch, Clinton, Canada.
Brilliant! Thanks Col
One P.M. Brown of Toronto graduated from No. 1 Bombing and Gunnery School (Jarvis, Ontario) on July 31, 1942 but I can't tell if he's the man you're looking for ("JARVIS GRADUATES - ANOTHER CLASS OF AIRMEN GRADUATED TODAY" in The Globe and Mail, August 1, 1942).
Author of Crash in Bayeux - The Last Flight of Sergeant Ferguson (ISBN 979-10-91044-13-4) - www.facebook.com/crashinbayeux.
Thanks Fox,
This sounds very much like the same airman, but of course without a service number difficult to day for certain. Thanks for your help. Dave


text:
The number of people undergoing cosmetic surgery procedures each year is on the rise. Although previously confined to the realm of Hollywood and celebrities, more and more everyday folk are heading under the knife to alter their appearance, improve their self-confidence, and improve their health. Here are the top three reasons people have cosmetic surgery:
1. Improve appearance and self-esteem
For many people, cosmetic surgery is the only solution to fixing body issues that have persistently plagued them and ultimately had a depreciative effect on their self-confidence. Cosmetic surgery, such as a breast lift, is regularly sought after to tighten abdomens, straighten noses, and lift breasts with the ultimate goal being to improve self-image and lift self-esteem. Non-surgical cosmetic procedures are becoming increasingly common amongst individuals who wish to change their appearance but don't want to undergo the knife; such procedures typically include botox, lip fillers, and laser peels.
2. To reconstruct
There are many types of cosmetic surgery which although regarded as forms of plastic surgery, are actually designed to improve one's psychological and physical health. One such type of surgery is reconstructive cosmetic surgery. This surgery is typically performed on individuals whose bodies have been disfigured in some way. Surgery may be performed to re-build cleft lips, reverse birth defects, and alleviate scarring. The surgery may be cosmetic in the sense that it will alter the individual's appearance, but it will also have numerous psychological and physical benefits nonetheless.
Reconstructive breast surgery is commonly offered to women who have undergone breast removal surgery as a result of breast cancer; although this surgery is not physically necessary (women can survive perfectly well without having breasts), from a psychological perspective, this surgery is very much medically required as it helps to recover femininity and help to ease the trauma of treatment.
3. To tackle obesity
Many people who lose enormous amounts of weight often find that their skin – particularly around their faces, their abdomens, their upper arms and their thighs – is left sagging. This is because although the skin is able to stretch effortlessly to accommodate additional weight, it isn't able to ping back to how it was before when the weight is lost. If the weight loss is relatively minor, the only sign of the skin having been stretched may be a couple of stretchmarks, but the weight loss is extreme, the skin is left hanging loose and sagging. Unlike fat, the excess skin that's left over after weight-loss cannot be burned-off or shed during repeat visits to the skin, but must be surgically removed instead. Women who don't undergo surgery are often left carting around large amounts of excess skin, the result of which being continued straight on the heart despite the initial weight loss and a lack of confidence. One particular risk is that not having the skin removed could lead people to question whether the weight loss was actually beneficial and cause them to revert to their unhealthy eating habits.
Until Next Time… Charlotte x
Keep in touch: Twitter | Facebook | Instagram
Find my disclaimer


text:
But I am now, and that is the whole point, correct?
Serving this to family as an appetizer, and it's all I can do to keep hubby dearest away from eating my onions!
I thought I had balsamic vinegar, but I was wrong. I substituted with some balsamic dipping oil I had on hand. Well, it's always on hand in my house!
½ Cup butter
3 Large red onions, cut in half and thinly sliced
¼ Cup sugar
3 Tbsp raspberry or balsamic vinegar
1 Loaf baguette bread (cut into ½ inch slices)
1 Tub (8 oz) soft cream cheese with herbs or vegetables
2 Tbsp fresh parsley
1. In 12-inch heavy skillet, melt butter over med high heat until sizzling
2. Cook onions in butter 5-6 minutes, stirring frequently, until onions are softened
3. Stir in sugar and vinegar
4. Cook 9-10 minutes, stirring frequently, until onions are very soft and light golden brown
5. Cool onion mixture slightly (about 10 minutes)
6. Set oven control to broil
7. Place bread slices on cookie sheet.
8. Broil with tops 4 inches from heat 1-2 minutes or until lightly browned
9. Turn bread, broil 1-2 minutes longer or until lightly browned
10. Spread about 2 tsp cream cheese on each bread slice
11. Top each with 1 tbsp onion mixture
12. Sprinkle with small amount of parsley


text:
Post-Tropical Cyclone Lorena Public Advisory
000 WTPZ35 KNHC 221431 TCPEP5 BULLETIN Post-Tropical Cyclone Lorena Advisory Number 21 NWS National Hurricane Center Miami FL EP152019 900 AM MDT Sun Sep 22 2019 ...LORENA DEGENERATES INTO A BROAD AREA OF LOW PRESSURE... ...THIS IS THE LAST ADVISORY... SUMMARY OF 900 AM MDT...1500 UTC...INFORMATION ---------------------------------------------- LOCATION...28.8N 111.5W ABOUT 65 MI...105 KM NNW OF GUAYMAS MEXICO MAXIMUM SUSTAINED WINDS...30 MPH...45 KM/H PRESENT MOVEMENT...N OR 360 DEGREES AT 9 MPH...15 KM/H MINIMUM CENTRAL PRESSURE...1006 MB...29.71 INCHES WATCHES AND WARNINGS -------------------- There are no coastal watches or warnings in effect. DISCUSSION AND OUTLOOK ---------------------- Post-Tropical Cyclone Lorena crossed the coast of northwestern Mexico this morning. At 900 AM MDT (1500 UTC), the center of the disturbance was estimated near latitude 28.8 North, longitude 111.5 West. The post-tropical cyclone is moving toward the north near 9 mph (15 km/h), and this motion will continue to bring the disturbance farther inland until dissipation. Maximum sustained winds associated with this system are near 30 mph (45 km/h) with higher gusts. Dissipation is expected tonight or early Monday. HAZARDS AFFECTING LAND ---------------------- RAINFALL: The system is expected to produce total rain accumulations of 3 to 6 inches over central Sonora. This rainfall may result in life-threatening flash floods in Sonora. NEXT ADVISORY ------------- This is the last public advisory issued by the National Hurricane Center on this system. $$ Forecaster Avila


text:
Monday, June 23, 2008
George Carlin passes away
Comedic legend George Carlin has passed away at the age of 71 (Sunday June 22, 2008). Carlin, who had a history of heart problems, died at St. John's Health Center in Santa Monica about 6 p.m. PDT (9 p.m. EDT) after being admitted earlier in the afternoon for chest pains.
The legend known for his "dirty jokes" and crude sense of humor was set to receive the "Mark Twain prize for American Humor" award from the John F. Kennedy Center for Performing Arts. It was to be presented to Carlin on November 10th.
He will be missed.
Posted by SX0T at 12:48 PM |


text:
Beat the Heat on Summer Workouts
It's finally warm outside and while the extra daylight hours and sunshine are great for getting some fresh air, sometimes it's just too hot to safely exercise outside. Just because the heat is rising doesn't mean you should put your workout on the back...read more
Functional Fitness: What it is and Why it's Beneficial
You bend down to lift a heavy bag from the floor, or pick up your 6 year old after a bike riding fall and you hear: snap, crackle, pop and your back is out. Everyday movements can leave even marathon runners and weight lifters in pain. This is where...read more
Family Activities that Give Everyone a Great Workout
Family time is probably the most important time of the day. After the hustle and bustle of school and work, dinner and cleanup, it can be hard to find the time to be active and be together. When you want to get a great workout in but the kids need you too,...read more
The Best Exercises for People Who Don't Like to Workout
Let's face it, workouts can be boring. The machines are sort of confusing and the gym atmosphere isn't for everyone. Some people just really hate working out. So what do you do if you're one of those people but want to be fit? Believe it or not, there are...read more
Power Up! Explosive Exercises to Generate Significant Power.
Looking to spice up that backhand serve? Athletic power is a sport's must. It requires a large combination of muscle fibers to fire off simultaneously to jump higher, throw harder, and to move with abundant force. Below are some suggestions to do as either...read more
Sit Disease – Identifying Office Posture and using Exercise to Counteract it.
Humans have come a long way in the past millennium. But if there is one major area that we have begun to get lax in, it would have to be practicing good posture. Gone are the days of parents persistently informing their children to sit straight. We have...read more