Developing software for corporates- the necessary obfuscation layer Developing software for corporates- the necessary obfuscation layer
Page 1 of 5 123 ... LastLast
Posts 1 to 10 of 49
  1. #1

    Banned

    aussielong has no reputation


    Join Date
    Dec 2007
    Posts
    1,365

    Default Developing software for corporates- the necessary obfuscation layer

    There appears to be a mismatch between how we really develop software and how non-technical management think we develop software.

    Breaking it up into tasks up front that get ticked off each day producing a nice graph isn't how we work.

    Tasks progress in parallel, many unexpected tasks come up during the day and get done quickly- these eat into my time.

    I don't have complete understanding now of how its all going to work - i just have a skeleton plan in my head, which i refine as i get more into the problem. These people dont like to hear "i dont know how that will work yet".

    Calling meetings to produce schedules and track progress actually impedes progress because it interrupts us.

    Every company i've worked in i've felt like i've had to mislead the management to keep them happy while i tinker away in a completely different world-eventually i produce what they wanted but i've done it in a different way than the project planning would lead you to believe.

    Most of the developers around me seem to work like this.

    But ... we can't get rid of the layer of management because the ones who pay for our services want to work like that. It probably makes sense for non-development projects. So we have to have this layer of bullsh1t that maps our way of working to their way of working, just to keep everyone happy.

  2. #2

    Fingers like lightning

    DieScum is too good to be a permie


    Join Date
    Aug 2005
    Posts
    649

    Default

    Yep. I suppose it's a tough problem to solve. There needs to be a way to track progress.

    If you put your car in at the garage you want an accurate estimate of how long things will take, what is wrong and what needs to be fixed so you can try and get a handle on whether they are trying to overcharge and are competent and you want it to work at the end. If at some point it looks like it will take longer to fix you need to know so you can plan other transport. Principal-agent problem.

    The best way to handle that is to hire a trusted mechanic with good reviews and let them get on with it.

    The more complex and high budget things become they less you can just trust someone and the more it needs to be tracked. If you put a fleet of a thousand limousines in to a garage for some upgrade and every day one is out of business costs you a grand you're going to want see planning and progress.

    So I think it's necessary sometimes, you can't always just trust, but it's often done so badly and it often gets surreal. I think in the technical side quality and competence are more visible. On the non-technical side a suit and a pleasant manner can disguise incompetence. So a PM or manager can happily waste days of your time on pointless meetings, or valueless charts and look busy and effective while actually doing harm.

    Putt's Law put it well "Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand."

  3. #3

    Banned

    aussielong has no reputation


    Join Date
    Dec 2007
    Posts
    1,365

    Default

    Quote Originally Posted by DieScum View Post
    Yep. I suppose it's a tough problem to solve. There needs to be a way to track progress.

    If you put your car in at the garage you want an accurate estimate of how long things will take, what is wrong and what needs to be fixed so you can try and get a handle on whether they are trying to overcharge and are competent and you want it to work at the end. If at some point it looks like it will take longer to fix you need to know so you can plan other transport. Principal-agent problem.

    The best way to handle that is to hire a trusted mechanic with good reviews and let them get on with it.
    Why do you draw a comparison to a car mechanic? Fixing cars is relatively easy.

    You should compare yourself to a surgeon?

  4. #4

    My post count is Majestic

    NickFitz has reached the peak. Play again?

    NickFitz's Avatar
    Join Date
    Jun 2007
    Location
    Your local branch
    Posts
    49,574

    Default

    This is one of the problems that Agile tried, in its original form, to address. Of course now its been dressed up as a "methodology" so that chancers can make money out of selling books and training courses, and has thereby turned into just another load of management bulltulip.

    But if it's done right, with a good team, it can be an excellent way of actually getting stuff done without having to make crap up just to fool some pointy haired idiot with a Gantt chart.

    Incidentally, Microsoft Project is a terrible tool for managing software development projects (though very good if you want to build a bridge or some such). This ought to be obvious from the fact that Microsoft originally developed it to manage their own projects and, since then, have never once delivered a product on schedule

  5. #5

    The beerded one

    EternalOptimist is NOT a disguised employee

    EternalOptimist's Avatar
    Join Date
    Jul 2005
    Location
    Castle Saburac
    Posts
    22,444

    Default

    You take a car mechanic, or a guy digging a field, then stand behind him with a whip and he will work twice as fast. crack the whip and he will work even faster, then whip him a little bit and he work his fastest.
    You get a second guy whose job it is to plan the digging, design a digging machine and count the first guys shovel fulls, (a thinking job), and stand behind him with a whip, and nothing will get done.

    Some jobs just dont respond to the old school management methods, dev work is one of them.The best dev teams I have seen have come up with their own versions of agile (rad, scrum or whatever you want to call it) and one of the keys is when the project manager realises he is not the boss, but the enabler, the oil between the wheels, the servant.



    (\__/)
    (>'.'<)
    ("")("") Born to Drink. Forced to Work

  6. #6

    doGlike

    SupremeSpod has no reputation

    SupremeSpod's Avatar
    Join Date
    Jul 2005
    Posts
    6,193

    Default

    Agile does work with adequate buy-in from the developers and customers.

    Developers with no social skills, and an over-inflated opinion of their own ability can really ***** up your project. Luckily they're going the way of the Dodo.

  7. #7

    My post count is Majestic

    MarillionFan is a fount of knowledge

    MarillionFan's Avatar
    Join Date
    Jul 2005
    Location
    .
    Posts
    35,964

    Default

    As the idiot with gannt chart I tend to produce a highly detailed development plan at the beginning of all projects. That is reviewed and agreed with the lead developers and then signed off by the business. This allows me to manage expectations of the client and keep track of the developers. It also allows the identification of issues, time delays and priorisation of scope should we have issues coupled with the ability to line up resources for subsequent phases.

    I tick off progress based on key areas both sequential and parallel. The detail is to ensure the developers know what were doing. To be fair though, everything I've had developed in the last few years I've offshored and this 'micro manage' approach ensures I get delivered what we agreed.
    What happens in General, stays in General.
    You know what they say about assumptions!

  8. #8

    doGlike

    SupremeSpod has no reputation

    SupremeSpod's Avatar
    Join Date
    Jul 2005
    Posts
    6,193

    Default

    Quote Originally Posted by MarillionFan View Post
    As the idiot with gannt chart I tend to produce a highly detailed development plan at the beginning of all projects. That is reviewed and agreed with the lead developers and then signed off by the business. This allows me to manage expectations of the client and keep track of the developers. It also allows the identification of issues, time delays and priorisation of scope should we have issues coupled with the ability to line up resources for subsequent phases.

    I tick off progress based on key areas both sequential and parallel. The detail is to ensure the developers know what were doing. To be fair though, everything I've had developed in the last few years I've offshored and this 'micro manage' approach ensures I get delivered what we agreed.
    And when MF's project goes titsup, I'll dig it out of the mire - for a price.

  9. #9

    My post count is Majestic

    MarillionFan is a fount of knowledge

    MarillionFan's Avatar
    Join Date
    Jul 2005
    Location
    .
    Posts
    35,964

    Default

    Quote Originally Posted by SupremeSpod View Post
    And when MF's project goes titsup, I'll dig it out of the mire - for a price.
    Has Suity got your pager number yet?
    What happens in General, stays in General.
    You know what they say about assumptions!

  10. #10

    doGlike

    SupremeSpod has no reputation

    SupremeSpod's Avatar
    Join Date
    Jul 2005
    Posts
    6,193

    Default

    Quote Originally Posted by MarillionFan View Post
    Has Suity got your pager number yet?
    It's called job creation, mate.

    "Suity the Project Manager - Can he fix it? No it's f*cked!"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •