Re:Your job is not to tell us how to do our job
by crazychrome on Monday February 23, 2015 @07:07AM
(#9093843)
The view that developers are just coders to implement business requirements shall simply follow instructions/specifications is dangerous. The attitude of "my way or highway" is absurd if you really understand how organization/team works. It's your job, as a project manager, to not only provide material supports for your engineers to do their work, but also translate business logic into clear, acceptable, feasible and inspirational vision to your dev team. Engineers, on average, are smart and reasonable people. It's your personal failure being unable to convince engineers on "why" questions (e.g. why support IE8 on XP).
btw, 90% of business fail. it means 90%+ of the so called "business requirements" are just bs. it doesn't hurt to explain your business to your engineers. Can you sell your ideas to team? if you can't, it's a bigger problem than couple of naughty engineers.
Edit: delete the last line considered offensive.
Re:Your job is not to tell us how to do our job
by bradleyland on Monday February 23, 2015 @02:18PM
(#9096334)
The parent poster said nothing deserving of this rebuttal.
Re:Your job is not to tell us how to do our job
by chaz72 on Monday February 23, 2015 @08:32AM
(#9094148)
The developer should absolutely be involved in that discussion, as the person with the best information on the cost of supporting that long tail. If complexity makes the system less reliable for the 98%, supporting the 2% may be a fool's bargain. (If, I say - your mileage depends on your tech and your team.)
Re:Your job is not to tell us how to do our job
by a-ghost-fart on Monday February 23, 2015 @06:43AM
(#9093770)
I didn't say I assume the right to drop support, I said I will fight tooth and nail to drop it, that does mean following necessary process to do so. If the specification doesn't change because the stakeholders don't go for it, then that's life.
As much as the business doesn't want to be wasting money, I don't want to be wasting my time on something that has a detrimental effect on our ability to get the job done.
Re:Your job is not to tell us how to do our job
by onion2k on Monday February 23, 2015 @07:27AM
(#9093902)
As much as the business doesn't want to be wasting money, I don't want to be wasting my time on something that has a detrimental effect on our ability to get the job done.
If supporting older browsers is part of the specification then it has no impact on your ability to "get the job done" - supporting older browsers becomes a part of the job.
Re:Your job is not to tell us how to do our job
by a-ghost-fart on Monday February 23, 2015 @07:40AM
(#9093944)
Which is very true, and as I stated if it's part of the spec, it's part of the spec, but I find it's a duty of the job to raise it as a concern and an area of risk for delivering the product on time, especially when starting out on a new product.
That decision is absolutely not the place of the developer. Failing to support a particularly market segment has implications far broader than simply the bottom line dollar value of each user. Even if those users bring in zero revenue it can still be worthwhile developing the code base so that they're supported. This sort of thing is an example of something that you, as a developer, simply aren't equipped with the necessary information or knowledge to make decisions about on your own - it has to be a collective decision informed by developers, marketers, product managers, and C-level managers.
A trivial example - the decision whether or not to go with a single page Javascript application design versus rendering pages on the server can be influenced by user demographics but have a massive impact on everything in the business from hardware costs to how you integrate payment reporting in to the workflow of the business.
Any developer who puts their needs in supporting particular users over the requirements of the company as a whole, frankly, probably ought to be shown the door. They don't understand how the whole business process works and they will almost certainly screw up something really important later.