Workplace Issues

mac123

Hi all,

I'm a computer science student and I have a technical communications class where we have to come up with a common workplace issue faced my developers and possible solutions to that issue. It is for a 20-30 page report so it has to have some substance.

I've never worked in the field so I don't really know what the problems would be. I figured a lack of knowledge/experience among management might be an issue.

Any suggestions?

MaggotBrain

The constant interruption to a developers day would be a great subject. A productivity study with the daily onslaught of pointless meetings, standups, estimations, production issues, on call sleep deprivation etc.

amen

The constant interruption to a developers day would be a great subject. A productivity study with the daily onslaught of pointless meetings, standups, estimations, production issues, on call sleep deprivation etc.

+1

explaining to a business user why their change makes no sense and why it is not possible even if you had no computer,
working long hours to meet crazy deadlines,

zig

(warning: possible thinly veiled rant)

One workplace issue could be decision making, management and ownership coming from a person with little to no expertise in the area, but also lacks the ability to really listen to developers that do have that expertise.

This can very quickly trickle down and cause huge knock on effects that can ruin a company, e.g. promises to customers that can't be kept, bad estimations of work resulting in a huge amount of loss leading projects, unhappy customers, small requests/fixes from management that are assumed to be easy but can eat up alot of time, and very low staff moral.

The solution is a social/psychological one, not a technical one. There is such a big gap in personality in this industry compare to other industries that both sides (development and management) must 100% understand this gap exists. Being aware of the gap will then allow both sides to come to compromises and understandings.

The developer may have to learn to tolerate a level of pressure where they do feel its undue, but more importantly the manager must tolerate and appreciate a level of rejection, higher than expected estimations and the word "no".

EamonnDunne

MaggotBrain wrote: »

The constant interruption to a developers day would be a great subject. A productivity study with the daily onslaught of pointless meetings, standups, estimations, production issues, on call sleep deprivation etc.

Indeed, reminds me of the @PHP_CEO parody account,

"IF YOU HAVE HEADPHONES ON, HOW AM I GOING TO SHOUT QUESTIONS AT YOU ACROSS THE OFFICE?"

On a more practical note this is a good pick as there will be many studies already done that you can reference.

CreepingDeath

mac123 wrote: »

I have a technical communications class where we have to come up with a common workplace issue faced my developers and possible solutions to that issue.

I've been a developer for over 20 years now.
In ye olde days we following the "waterfall" method of development, which might have involved 3 weeks of design, 10 weeks of development and 3 weeks of testing.
It meant that when the product was ready to demo to the stakeholders it was too late, it had been written and if it wasn't what they wanted then time and resources would be wasted refactoring it.

These days we use the Scrum process.
Instead of spending 3 months developing in a dark room and showing the results at the end, we break the project timeline into 3 week chunks and plan what we'll do in those 3 weeks.
At the end of every 3 week "sprint" we demo our work to the stakeholders.
We get constant feedback which catches any problems with the solution early.

This was a huge step forward letting the stakeholders prioritise the bits they wanted next, which meant that the "nice to have" options were safely at the end of the development cycle and could be de-scoped if necessary.

On the subject of "technical communication" I think this had the biggest positive impact on my day-to-day work.

Also, the "scrum master" who plans and tracks the progress of the sprint tasks also has the role of trying to avoid people from interrupting his team.
So people have to ask permission to get support from his team, which they can reject if necessary or make a judgement call on it's priority.

fergalr

I suggest reading this:
http://www.amazon.com/Peopleware-Productive-Projects-Second-Edition/dp/0932633439

Its a popular and easy-to-read text on workplace issues around software development.
This will give a good overview of the subject.

The book is a little old, but, unfortunately, its not dated at all.

mac123

Thanks folks! Some good ideas there! Seems like I'll be facing some headaches when I eventually enter the workplace;)

punk_one82

Not sure how useful it will be, but one common workplace issue I've found in my short time as a developer is teams claiming to be Agile, and using that as an excuse to change requirements/acceptance criteria mid-sprint and in some cases wasting an awful lot of time/effort/money as a result, as well as infuriating developers who have spent a week or more developing a feature, only to be told mid-sprint to throw it out, start over and get it done in half the time.

yes there

That's not agile. The sprint is effectively a commitment. You can add but you can't change. Sounds like a product owner problem.

EamonnDunne

punk_one82 wrote: »

Not sure how useful it will be, but one common workplace issue I've found in my short time as a developer is teams claiming to be Agile, and using that as an excuse to change requirements/acceptance criteria mid-sprint and in some cases wasting an awful lot of time/effort/money as a result, as well as infuriating developers who have spent a week or more developing a feature, only to be told mid-sprint to throw it out, start over and get it done in half the time.

I've yet to experience directly or even hear of a company that truly does agile. Usually in my experience its waterfall with some practices cherry picked from agile and bolted on to the process.

Jim2007

punk_one82 wrote: »

Not sure how useful it will be, but one common workplace issue I've found in my short time as a developer is teams claiming to be Agile, and using that as an excuse to change requirements/acceptance criteria mid-sprint and in some cases wasting an awful lot of time/effort/money as a result, as well as infuriating developers who have spent a week or more developing a feature, only to be told mid-sprint to throw it out, start over and get it done in half the time.

This does not at all surprise me because Agile encourages the short term view on both sides and in the drive to get something out there it is not at all unusual for teams six or seven weeks in to hit a wall where they can no longer refactor around a fundamental misunderstanding of the problem domain.

To my mind Agile is great way to work if you are a consultant because it lets you get some billable software out there quickly, but it a lousy way to built in house software or have it built for you. The only difference between it and the waterfall is that it allows you to create as big a mess faster and just as expensive if not more so. And no doubt in a couple of years something new will come along and we'll forget about Agile in favor of the new silver bullet.

Over the years I've seen some great software written but it was not as the result of the programmer using or not using a particular methodology. It was because they were a great programmer and more importantly they understood the problem domain as well if not better that the business they worked for.

LordNorbury

A mate of mine, he had a biz turning over approx 3 million Euro a year, the whole business failed after he got the wrong IT company in to build an IT system for his warehouse (it was a logistics company) and he spent well over 150K between the hardware and the software, it would make a great case study in how to not go about having an IT system put into your business.

Lemming

Could look at the reluctance of non-technical departments/senior management to buy in to agile development in anything but a token/name-only manner. Everything ranging from resistance between depts. to consolidating the language used to describe a feature or piece of functionality so that everyone is speaking the same language (literally and metaphorically), to lack of understanding of estimates (guesstimates) and/or treating them as hard absolutes, or paying scant value to the time spent creating any form of unit testing, etc.

There's a whole heap of twists and turns that can be taken on the subject and differing angles to consider.