LiveCode Forums.

Since Stan and I are jostling for bragging rights, I have posted before that in only one instance have I ever formally planned a new stack project. And even in that case, after making a nice flowchart, I simply started dragging controls and writing scripts.

There must be a negative bragging award somewhere.

What was my point? Oh yes. My largest project to date, a seven sub-stack application with 15,000 lines of actual working code, is a lovable nightmare. This is because it started out as a small well-defined gadget that grew horns and a tail.

What was my point? Oh yes.

How does one deal with that in the grown-up programming world, especially with more than one participant. I write alone.

Aren't all large projects similar, in that even a well defined initial functional requirement will soon become ancient history, if not laughably adorable? In my case, I try to modularize new requirements, hence those subStacks. But it is impossible to completely isolate them, and when they eventually must interact with each other, I find myself patching, patching...

Craig

Oh, Craig, I 100% agree with you; and that is why everytime I have been hired to do some programming
for someone else I have ended up getting in hot water.

AND the same goes for 'Lesson Plans' which teacher trainers and daft principals demand of their victims.

I have just wasted my daily 10 minutes time waste on LinkedIN where I keep being offered dubious jobs as
an interface designer for a software design team in places such as Dahomey . . . 'interface designer' my backside:

Surely one just gets 'hacking' and endlessly swizzling things around until something reasonably sensible comes
out of the ferment?

Try telling that to a load of executive types with preconcieved ideas of the 'way things are done.'

3 days ago my assistant teacher suggested I knock up a program for kiddos to practise and get to grips with English
articles (that's 'a', 'an' and 'the'); so I said, "OK, let's see what I can do." and I DID, and she played around with it a bit,
and suggested a few changes, which I implemented, ran off a standalone: bunged it on the Linux boxes in both of
my EFL schools, and . . . some of the kids suggested changes, which I implemented, ran off a new standalone: bunged it
on the Linux boxes in both of my EFL schools, and . . .
- -
While 'Out in the Real World' [a place I am glad I don't have to live in] we'd have a month-long focus group,
committee meetings, and so on, and so forth, fifth and sixth.

My wife is the head of the English department in our local University and, as she herself will be the first to
tell you, has managed to implement not a single change in the way things have been done for 33 years because
everything is swallowed in meetings, committees, and so on.

dunbarx wrote: Tue Mar 28, 2023 8:29 pm What was my point? Oh yes. My largest project to date, a seven sub-stack application with 15,000 lines of actual working code, is a lovable nightmare. This is because it started out as a small well-defined gadget that grew horns and a tail.

I can't say I have personal experience of expert-level grown up development in a large team - but having employed such a team some years ago for an ambitious project it became very obvious that most of the work on their end was the 'discovery' phase.

These guys took nearly 6 months speaking with all stakeholders, mapping requirements and workflows, creating scenarios relatable to each group of stakeholders, planning in broad terms the various elements, etc and created a number of mockups/wireframes that illustrated both interface in broad terms and workflows in the app. The other important aspect of the discovery phase was listing everting they wouldn't implement.

The 'discovery' phase was a significant chunk of the total cost and more than half of the development time. I'll admit at the time it seemed tedious and wasteful - why couldn't they just code what I wanted! But then again the software didn't end up sprouting horns and warts

If you're going to do this, I think it boils down to doing properly exhaustive planning and needs more than one person to do it. If you're building software alone and for yourself it's probably more difficult to see all the angles because we all have blind spots. And let's face it, most of the time we know (or we think we know!) what we need and just code it. But sometimes it comes back to bite you

Richard.

I choose you from among many possibles, just because.

You are a grown-up, unlike me. How do you perceive the nonsense in the previous handful of posts?

Craig

stam wrote: Tue Mar 28, 2023 9:12 pm If you're going to do this, I think it boils down to doing properly exhaustive planning and needs more than one person to do it. If you're building software alone and for yourself it's probably more difficult to see all the angles because we all have blind spots. And let's face it, most of the time we know (or we think we know!) what we need and just code it. But sometimes it comes back to bite you

Morning all,

When I was programming for others, my prototyping was done in my head: I would spend a day listening to people describe what they wanted (and smiling while internally I was thinking How the hell can I accomplish that?), then return to my hotel room and sleep on it. By morning I generally had a plan on how to proceed. Some times it all went well. Some times I would give them what they asked for and they would respond Now that I see this I realize it isn't what I really wanted. Sometimes I would say to myself I don't think this is a good approach, but it's what they asked for so I'll do it their way. In the latter situation, I would often end up having to change my approach mid project. But with very few exceptions I was the sole designer/programmer on the project, and mostly I was modifying an existing app to add or change functionality.

Large team projects require a standardized approach to keep all participants on the same page (eg: a shared data dictionary & record structure and an understanding how each person's contribution was to mesh the the work of others). I don.t have experience in that environment, but I remember listening to my father, who was Director of the California Department of Motor Vehicles, describe DMV's software development issues and wondering Why is this so complicated; I could program it in half the time.

At some time back then I found a website where people would describe software projects and solicit bids. I responded to a few with working prototypes, thinking that would give me an edge; but soon realized I was giving them design specs they could have someone else implement.

Today software development is a creative endeavor for me. Sure, I would be happy to see royalties from my app; but that's not why I program: I want to see the concepts in my head manifested in working software. And as my concepts evolve, my software changes. That is not a viable approach when one is programming for someone else.

Cheers!

Rob