Philosophy Discussion Forums | A Humans-Only Club for Open-Minded Discussion & Debate

[Papus79]

Yes, no-one ever said (in my hearing) that design is easy. What you describe is one of the major challenges of software design. It sounds like you think you don't have time for design, a common reaction to this kind of issue, but my own experience is that you don't have the time not to design...

It's not a lack of time or lack of desire due to time, more like the client doesn't know what they need until they think of it on the fly.

[Pattern-chaser]

Yes, no-one ever said (in my hearing) that design is easy. What you describe is one of the major challenges of software design. It sounds like you think you don't have time for design, a common reaction to this kind of issue, but my own experience is that you don't have the time not to design...

It's not a lack of time or lack of desire due to time, more like the client doesn't know what they need until they think of it on the fly.

Yes, that's part of the fun. The client never knows what they want, and changes their mind often, even introducing features they'd previously rejected. Your design process needs to embrace and deal with this. It's a PITA but it's RL, and you have to accept it, which took me years (and years...). Adaptive processes like Agile and eXtreme programming offer practices and advice that may help, I think.

[Steve3007]

One difficult thing is when the design standard you're following mandates the use of a waterfall-like method but the customer still changes their mind about what they want, such that a more Agile-like method would be better in practice. It's ok if the customer is willing to pay for all the work involved in making the changes. But that's where clear mutually agreed documentation of the original requirements is useful, to reduce their ability to say "this is what we asked you to design all along, so you have to change it at your expense".

[Papus79]

But that's where clear mutually agreed documentation of the original requirements is useful, to reduce their ability to say "this is what we asked you to design all along, so you have to change it at your expense".

That's one of the things we're considering. Even when it's not mom-and-pop outfits there can be a lot of oversights, such as times when a President or VP of Finance and someone under them and a few other people test what they asked for, see no problem, ask us to release it, and as soon as they do all of their users start asking where features A, B, C, D, E, F, etc. are that they need every day. I had a project like that where we probably did a little over 1/3 of it real-time in production because we were asked to deliver, even after sandboxing with a head and second in command for the department that would be using it, what was - to the end users - an unusable product. That's one of the cases where their even giving us a big spreadsheet up front that seemed quite detailed still didn't carry the project, OTOH we did have better arguments for additional billing in places where they did open rabbit holes in the spreadsheet.

One of the primary contract challenges seems that you can topically frame things pretty easily for a surface level 'length and width' but it's very difficult to frame for 'depth' because it's what the client can't see and doesn't have a computer science background to understand (or if they understand enough they've got a bit more capacity to run you with plausible deniability).

[Pattern-chaser]

One difficult thing is when the design standard you're following mandates the use of a waterfall-like method...

Ah, now we get to the bean-counters - money-men; managers - who have a pathological need for certainty, and time-constrained development plans. Then they can observe and monitor 'milestones', in order to justify their existence. [There is no convincing justification of their existence, IMO.] RL incorporates changes to requirements as RL project development continues. This is a fact of life. This, coupled with the observation that design is a creative endeavour, makes it next-to-impossible to estimate accurate timescales.

Waterfall doesn't work; it never did. We pretended to practice waterfall, but did what we had to do to bring our projects to completion. And managers hovered around, like flies on , monitoring 'milestones' and showing everyone how very necessary they were, and how they were 'in control' of a process that is, essentially, uncontrollable.

Gods!, these things still make me angry, 6 years after I retired!