September 24, 2012 at 9:24 pm
Comments posted to this topic are about the item Trade-offs
September 24, 2012 at 9:27 pm
As they used to say in the project management unit I did at uni:
"Time, quality and cost. Pick any two!"
I used to call my self The Master on forums, then I entered the IT industry and realised how much I still have to learn.
September 25, 2012 at 2:54 am
With regard to the part about people being difficult to replace - I think software and software management will be one of the last things ever to be automated. As such at present it is one of the last bastions of truly hand built design. Anyone who is good in a built by hand environment can be very diffiult to replace. Especially if they are the original architect of the systems. I think this is why you get problems like the UK banks recent hickup server side (no one was left who had an adequate view of the complete systems).
I like to have a mix of old and new hands as well. The new learn from the old and can get a decent apprenticeship and the new can think differently and a lack of knowledge may mean they try things others would think impossible or just think completely differently. Plus if an oldie leaves an apprentice is in a good position to take over.
cloudydatablog.net
September 25, 2012 at 6:17 am
I have heared it as "Good, Fast, Cheap. Pick any two." See here. It's a truism. For the large part it's true. Like most truisms it's true most of the time except for when it isn't. :blink: That means that there are exceptions.
Then when it comes to people Steve makes a very good point. I got a neat quote the other day that makes the same point:
Everyone you will ever meet knows something that you don't
-- Bill Nye (the science guy).
ATBCharles Kincaid
September 25, 2012 at 6:47 am
I too have been working on the "pick 2" rule mentioned by others here, for most of my adult life. Can't remember where/when I first ran into that rule. Maybe in my management training in the early 90s.
And I definitely agree, people are never a "commodity". Even a "would you like fries with that" type position in a company can be better served by some people than by others. Some will, just by attitude, body language, etc., encourage people to come back, while some will drive people away, even on something as simple as that.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 25, 2012 at 6:50 am
"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."
Sigerson
"No pressure, no diamonds." - Thomas Carlyle
September 25, 2012 at 6:51 am
Always enough time to do it twice but never enough time to do it right seems to be the way it goes more often than not.
Cheers
September 25, 2012 at 7:10 am
I've always told my managers that building software is a trade off. We can do things cheaply, or we can do them quickly, but we can rarely do both. We can certainly fail in both ways, and many people do, but I usually see the need to trade time for money, or vice versa, when building software.
Building a piece of software cheaply and quickly isn't mutually exclusive. It can routinely be done by narrowing (trading off) the scope of the deliverable and keeping the stakeholders and requirments to a minimum.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 25, 2012 at 7:10 am
In my experience, it's often not helped by deadlines being set by people who have no understanding of the field - be that software engineering, infrastructure, building work etc. And then further problems being brought about by people just not listening to what the experts are telling them.
Bitter? me? No...
Thomas Rushton
blog: https://thelonedba.wordpress.com
September 25, 2012 at 8:39 am
I've heard that triangle put differently: time, cost and features. We're embarking on a major re-write of a legacy app. Before we started on this I had plans and specs as to what would go into the new app. I had some great features. Now I've learned that the deadline isn't moveable, and the cost is fixed, so now, only a month into the project I'm beginning to consider what features we can throw out, because clearly we're going to have to eliminate some features if we're to come in on time and on budget.
Kindest Regards, Rod Connect with me on LinkedIn.
September 25, 2012 at 9:22 am
...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.
September 25, 2012 at 9:56 am
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.
ATBCharles Kincaid
September 25, 2012 at 10:07 am
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!
September 25, 2012 at 10:27 am
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?
September 25, 2012 at 2:31 pm
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. ...:-D"
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply