How stupid am I if I think otherwise? That a few hours of planning can save you weeks of coding? ?
-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Do you use any software development process?
- Thread starter Rams007
- Start date
- Similar Threads Similar Threads
We (programmers) should tell our boss (if happen we have one) that coding is the way to go. If we spend more time on coding, we gain more experience and come close to delivery of finished product. Planning too much is a lazy excuse to get the project to get started. We will never have a perfect plan. Expect the unexpected.
I do not agree. The more time you spend on planning, the less you will spend on coding, finding bugs, maintaining, adding features, etc.
This is also why a programmer analyst earns at least twice as much as a programmer.
how long is consider (enough) more time?
Weeks of planning can save you months of: coding, debugging, ... (see my post #23)
You mean system analyst? Unfortunately I don't see this job position still exist (at least in my country). If it does, the pay is as same as a "programmer". Boss expect a developer (now it is no longer call a programmer) can do all the jobs, including planning, design, system requirement study, documentation, presentation or proposal of new system, coding, UI design, quality assurance aka testing, bug fix and project management. The project timeline is 2 weeks (include weekends). This is what happened to me and that is why I quit. I am still frustrated as the market is in this in this shape in my place.
It is like a very huge disaster happening or some sort of asteroid fall on earth (Armageddon movie?) if my previous boss saw a bug. He will tell his developer, "I have trusted you to finished the system in 2 weeks but now it is not finished. (You lied to me!)". He will add, "I even gave you extra time, if you think you can't finish it, at least tell me 1 week earlier!" This is a real story.
"Serious" companies still have the distinction between programmer analyst, programmer, systems engineer, hardware technician, etc.
That sounds like IBM mentality.
We (where I was employed) had to deal with "No I don't write code, I'm an Analyst!" type comments from staff at company we merged with.
Whereas we (being non IBM mainframe) did everything, we could code, do Analysis, design databases, we even shifted the paper for the printers when it was delivered, oh and we could operate the mainframe too to give the op's a break. It made the job more fun.
I don't know, you should ask Erel ?
The question is different; an analyst who does not stoop to coding is a snob who would probably also be fired. The point is that a simple programmer very often is not able to do well done analyzes, especially of large projects (but not only of these).
Last edited:
I see that these days you are very active on the forums, @agraham, so I suppose (and I very much hope) that you are much better (I hope definitely healed!).
Thanks for the kind thought. ? Not healed but stable and not progressing for the time being.
You beat me by at least three years - I remember getting this book in grade 2 (= 1974) but I don't remember how many times I read it, other than heaps
and then by year 7 (1979) I'd graduated to this book, which I do remember reading during geography classes where I had an agreement with the teacher that as long as I passed tests and assignments then she'd leave me in peace:
and then in year 8 we got an Apple II at school so I moved to 6502 where my first question was: how the heck can you do anything with only 3 registers?!?!
and then when the Commodore 64 came along with sprite collision detection in hardware... I think that was my point of peak amazement, at least re. computers.
(but you learning me a couple of years ago that most Android phones now had hardware non-cartesian graphic rotation came pretty close, though ? so thank you for that)
Your gauge package reminded me of 2005 and this project:
and then when I went trawling through email to pin down the precise year (I could only remember that it was before the GFC) I found this blast from the past in which the phrase squash-all-the-new-bugs pretty much describes my software development process :
This video has a better shot of the gauges, plus is more from the driver's perspective. It was quite eerie if your seat wasn't the one that was being projected for - even just being a metre off eg in the passenger seat, it felt like you were sliding sideways down the road like a crab.
Like some others here, I am from a time (1970's) when you could count on 16k of memory in a business machine, and up to 64k on a Vax, CPM or MPM system. Mind you that is kilobytes of memory, not mega or giga bytes. I learned to be as efficient as possible to conserve that 64k maximum of heap memory. I still try to conserve memory today regardless of all of the object oriented wastefulness of modern languages. My approach was all about speed. Speed of execution, reading/writing data, and speed in moving around the program itself (user interface). Before windows/gem/cpm86, there was just inline coding. A serialized execution of lines of code with the occasional branching to a sub routine or the dreaded "goto" statement.
In the early 80's I developed a controller for industrial laundry equipment using the Commodore C-64 and it's analog to digital convertors to read chemical levels in tanks, and control washing cycles/timing. It was state of the industry at the time and about half the price of the competition. More than that, it was completely upgradable via software instead of a hardware/mechanical interface.
This was a time when error detection and correction was very important. An element that seems to be getting lost in today's software. It seems that requiring memory is much more cost efficient than paying a programmer to write tight, fast code, and error detection and correction means letting the program crash and requiring the user to run it again. That's simplistic of course, but it is also true for an alarming amount of software.
I think starting in such a sparse environment helped us old farts to keep writing tight, fast code today. Maybe I have become a bit more lazy in my application minimum requirements, such as megabytes of required memory instead of Kbytes. We have to do what the operating system and our chosen programming language allow or require though. I still find myself searching for ways to write a routine so that it is as tight and fast as possible. The overhead for some languages/compilers is frightening now. I do sometimes miss the old inline procedural programming style language packages. Imagine the speed of execution on a modern machine. Imagine the amount of reusable code you would have to keep in your library though...
--- Jem
In the early 80's I developed a controller for industrial laundry equipment using the Commodore C-64 and it's analog to digital convertors to read chemical levels in tanks, and control washing cycles/timing. It was state of the industry at the time and about half the price of the competition. More than that, it was completely upgradable via software instead of a hardware/mechanical interface.
This was a time when error detection and correction was very important. An element that seems to be getting lost in today's software. It seems that requiring memory is much more cost efficient than paying a programmer to write tight, fast code, and error detection and correction means letting the program crash and requiring the user to run it again. That's simplistic of course, but it is also true for an alarming amount of software.
I think starting in such a sparse environment helped us old farts to keep writing tight, fast code today. Maybe I have become a bit more lazy in my application minimum requirements, such as megabytes of required memory instead of Kbytes. We have to do what the operating system and our chosen programming language allow or require though. I still find myself searching for ways to write a routine so that it is as tight and fast as possible. The overhead for some languages/compilers is frightening now. I do sometimes miss the old inline procedural programming style language packages. Imagine the speed of execution on a modern machine. Imagine the amount of reusable code you would have to keep in your library though...
--- Jem
Back in 1977 I employed a graduate straight from university to train as a programmer for our industrial control systems. He was a bit green around the ears but he was a natural wizz at shaving bytes from Z80 assembler code without losing functionality to fit it into the 2k or 4k EPROMs of the time!.