Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Trade-offs Expand / Collapse
Author
Message
Posted Tuesday, September 25, 2012 9:22 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Friday, May 2, 2014 4:11 PM
Points: 645, Visits: 377
...there is another constraint to people that I hadn't considered. Each individual in your company isn't just a resource that's exchangeable for others. Each individual has knowledge and skills that aren't easily transferred to, or replaced by, other employees.


It would be good that most of the managers would know that too.
Post #1364127
Posted Tuesday, September 25, 2012 9:56 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, February 6, 2014 12:59 PM
Points: 801, Visits: 1,962
Sigerson (9/25/2012)
"...
As I read in another post in this forum, from Abraham Lincoln, "If I had 8 hours to cut down a tree, I'd spend 6 hours sharpening the ax."


Get a better sharpener! Six hours?

* One hour preping my chain saw.
* One hour preping the job site.
* Fifteen minutes cutting the tree.
* Half hour cutting the feld tree into logs.
* Half hour clean up.
* One hour kicking back and sipping something cold.

The balance of the time goes back to the client.
Leave it to a lawyer to run up your bill.


ATB

Charles Kincaid

Post #1364152
Posted Tuesday, September 25, 2012 10:07 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:18 PM
Points: 2,266, Visits: 1,320
All may have been created equal, but not all IT folks develop at the same pace, rate, or to the same level. Some are mechanics who make, remake, and code pieces and parts, some are creative who see ways to make the systems bigger, better, and faster. And there are a few who are visionaries who see IT totally differently, and seek not to write code, but to redefine what we do and how we do it.

Managers who treat programmers as units on a spreadsheet would consider Bill Gates as just another coder, Steve Jobs as a person who should get back to work and quit wasting time dreaming, and Ida Rhodes as one who should just leave well enough alone.

We are in deed not all equal for some produce great things while others make real what those producers believe impossible.

M.


Not all gray hairs are Dinosaurs!
Post #1364161
Posted Tuesday, September 25, 2012 10:27 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:27 PM
Points: 7,120, Visits: 15,016
Sigerson (9/25/2012)
"Better, faster, cheaper--pick two" is certainly a reality in our world and in any engineering discipline.

But we can do better, I think, in putting more emphasis on the DESIGN phase of any project. I've probably spent (at least!) a couple of years of my working life redoing work that someone else had not thought through well enough. Designing a project from A to Z is time-consuming but it cuts down sharply the time required for development.

As I read in another post in this forum, from Abraham Lincoln, "If I had 8 hours to cut down a tree, I'd spend 6 hours sharpening the ax."


Agreed - and that design should include documentation of the constraints imposed and the assumptions. Why? So that you can easily pick up an existing piece of code and quickly figure out if the original design was flawed, if something else changed in the environment which invalidated this function, or if the implementation was simply restricted because of a budget squeeze.

Having a solid description of what needs to be delivered, and why a limited scope may have been picked cuts down on bad assumptions and/or unecessary rewrites. It also cuts down on the variability you get from multiple folks developing a solution. It's not the dev's fault if you gave them a 50K foot view of a requirement but they didn't implement other unwritten specs you didn't include. Overthinking/overengineering a process can also be a flaw, causing a rewrite as well.



----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #1364174
Posted Tuesday, September 25, 2012 2:31 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
A mentor of mine long ago once said "if you pay peanuts to get a job done, then you will usually get a lot of monkeys." I have always remembered that too.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1364287
Posted Wednesday, September 26, 2012 9:48 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 17, 2013 8:58 PM
Points: 28, Visits: 114
I agree. You can pick two, one from colum A, B or C but you can't get all three; period.
Post #1365021
Posted Friday, September 28, 2012 6:47 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 7:42 PM
Points: 8,567, Visits: 9,071
Frank W Fulton Jr (9/26/2012)
I agree. You can pick two, one from colum A, B or C but you can't get all three; period.

No, you can trade off between time, cost, and functionality - that's not pick two (or one) and to hell with the other(s), it's take a rational balance between them. One reason projects screw up is that someone somewhere assumes they can discard one of those three fundamentals and have the other two: but you can't - as soon as you discard any one of them, you guarantee acheiving none.

Or of course you can adopt a project methodology which has a planning phase, a design phase, an implementation phase, and a delivery phase, which are to happen in that order with no feedback from any stage to its predecesors; that comes pretty close to guaranteeing failure - in fact just having no feedback from design to planning is usually enough on its own to guarantee failure. Yet some of the most widely mandated project management ideologies in the world have that absence of essential feedback.



Tom
Post #1366143
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse