How many hours for a project - Page 1
Forum section: electronics / projects

author: bitboards
author_rank: Newbie
timestamp: August 28, 2025, 10:22:09 am
content: I'm working on a project and I've had the usual 'this is taking too long'.The project comprises of the following (in brief):* A central hub unit with Accelerometer, GPS and GSM. It has an optional 2" display and an optional battery.* A battery monitoring device with 2 remote thermistors, 6 analog inputs, 4 current shunts, 4 relay drivers* A engine monitoring device with 2 remote thermistors, 6 analog inputs and 2 relay drivers* A simple Victron solar charger monitor, collecting solar data via uart* Optional (off the shelf) 4.5" or 7" display.The first three items above have a board with an ESP32 microcontroller for Bluetooth/Wifi and an ATTiny1617 for board control and doing the grunt of the I/O. All items are linked via WiFi presently with a framework written with Bluetooth in mind for the final product.Except for the optional 4.5/7" displays, all items have a custom PCB. The first spin of each board has been made by hand with board bringup and manual rework to a functional state.The firmware for everything is almost ready to be called a prototype. I've had to cut a lot of corners to bring it to this stage and the optional 4.5/7" displays are a little way off being ready for the prototype.What ballpark figure in months would be reasonable for this amount of work?

author: paulca
author_rank: Super Contributor
timestamp: August 28, 2025, 11:24:05 am
content: Increase your resolution and type of metrics will change your outlook.Stop looking at the full project or end game all the time. "How much left?". Set a "cadence", say 2-3 weeks. Decide what your goals are for that period, plan, execute, evaluate. Repeat.Ideally set yourself up for success each time."This period I want to get the AT command protocol working on the I/O MCU."Then if you succeed to achieve that goal, it's a success! Celebrate it. Pat yourself on the back and start planing the next spurt's goal.It sounds like you don't have a deadline anyway, personal project? Don't deliberately put yourself into the same slowly heated pan professionals find themselves in daily.... set small incremental goals, plan, execute, evaluate, repeat. You will get more done and enjoy it more.(Technically this is CBT therapy technique. Like social media sites tweak and fiddle with your knobs and buttons, you can do it too. Dopamine from success is a brilliant positive re-enforcement tool.)

author: eutectique
author_rank: Frequent Contributor
timestamp: August 28, 2025, 11:50:49 am
content: Quote from: paulca on August 28, 2025, 11:24:05 amSounds like ascrum. I second the approach.In a simplest implementation it boils down to a bunch of post-it notes listing bite-size manageable tasks, placed on a whiteboard with three columns -- "To do", "In progress", "Done". This is useful even for a one-man operation.Quote from: paulca on August 28, 2025, 11:24:05 amYes!

author: moffy
author_rank: Super Contributor
timestamp: August 28, 2025, 12:38:23 pm
content: I found that I regularly underestimated the time by a factor of 3 and the cost by a factor of 3, don't know what your factor might be but mine was quite consistant.

author: tggzzz
author_rank: Super Contributor
timestamp: August 28, 2025, 12:49:42 pm
content: Quote from: moffy on August 28, 2025, 12:38:23 pmThere are sound reasons for the factor of 3 w.r.t. time.Essentially people make estimates presuming they are working productively, i.e. "A time". In reality there is a lot of other time, "B time" required for admin, meetings, creating documents and all the necessary ancillary activities in a project.Typically people working on a project spend 30-40% of their time doing "A time" activities. That agrees with my experience.Can't remember the source, maybe "Rapid Development: Taming Wild Software Schedules" by McConnell.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 28, 2025, 01:31:40 pm
content: First thing is not to try and estimate the project as a whole. Start by listing the different tasks in a hiearchical way, getting into more details at each level. The benefit of this approach is that it will start documenting the management of the project and will also give you something formal and hard to deny, to submit to your managers. That's called a WBS.Doing that, you'll (in most cases!) find out that you'll end up with an estimation that's much longer/requiring much more resource than what you initial "intuition" was... and even if you're experienced.Using a simple project management software for this is handy - you don't need anything super fancy, just something that will allow adding tasks with hierarchy and update the total amount of time/delays/resources automatically.For each "leaf" task, sure, you can further add a 2x or 3x markup, especially for the more critical ones. Alternatively, you can "assign" only a fraction of the team's work time (as tggzzz mentioned) to get more realistic deadlines (as opposed to raw work load).But don't fall into the trap of trying to use your "experience" and "intuition" to come up with figures without having done the above first. You'll almost invariably come up with something that's far from reality, with nothing to back it up (but be certain your management will keep track of what you said). With a reasonably detailed WBS, you'll have the rationale that comes with your estimation.If you haven't done that before, try that. I guarantee you that you'll be surprised by the result.

author: tggzzz
author_rank: Super Contributor
timestamp: August 28, 2025, 02:54:01 pm
content: Quote from: SiliconWizard on August 28, 2025, 01:31:40 pmFor many small-medium projects such a breakdown has an extra benefit: it encourages people to think in terms ofdependencies. Thus, you cannot integrate the hardware with the software until the hardware is available and working to a suitable extent.Don't bother with full PERT charts; just the dependencies is sufficient to allow people to see what must be sequential, what can be parallel, and compare that with the assigned personnel.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 28, 2025, 07:49:48 pm
content: Quote from: tggzzz on August 28, 2025, 02:54:01 pmYes! Just simple dependencies. And yes, you can include fabrication delays for prototypes and such, and that again will make you see the project in a different light.If you don't want to/can't invest in a commercial project management software, but want something adapted and easier to use for this purpose than a spreadsheet, there is Planner (a Gnome app, but which runs on any Linux DE and on Windows too):https://wiki.gnome.org/Apps(2f)Planner(2f)Downloads.htmlIt's simple and easy to use.There's also ProjeQtor:https://www.projeqtor.org/en/, for something a lot more featureful, that can be shared across a whole company (but requires installation on a server). Steeper learning curve.Or otherwise any project management software.

author: RJSV
author_rank: Super Contributor
timestamp: August 29, 2025, 06:14:52 am
content: I know the feeling, but here I see that paulca has a very good reply.I've been swamped in a wood construction framing project that had estimated completion...in May, (2025). It's now another 3 additional months !I also use mental 'key up' techniques. That, I obtained with martial arts classes, (Tai Quon Do mainly). A key-up is when you self-excite yourself, like a verbal 'Lets Go', or 'Lets do this' before a team leaves the locker room, for competition.Raising out of bed, you can juice the motivation, by placing objects to view, like a portion of your unfinished project. Example: maybe you've just received a new set of boards, and then gone to bed for that day.Placing a board or two nearby means that you can, casually, glance at the good news, and get started (with morning coffee, etc).You don't have to be phoney about it; but I might treat those new board assemblies like some gold bars arrived. Obviously exaggerated but that's the purpose of a 'key up'. Paulca reply helps explain how to put more short-term goals, and, like I said, an exaggerated little celebration, or milestone helps get you juiced, alcohol-free.The negativity of counting up the unfinished tasks can be overwhelming. Often, I enjoy running by the clock; doing 40 minutes of carpentry, in the hot (equater) sun, followed with 20 minute break. Forcing NO measurements of progress or setbacks...just pure work, with head down.Then, it helps to do little reviews, of yesterday's progress.Negative attitudes come easy, so it's a battle all the way! Good topic, thanks for reading my take, on self-motivation.

author: krish2487
author_rank: Frequent Contributor
timestamp: August 29, 2025, 06:32:54 am
content: Quote from: eutectique on August 28, 2025, 11:50:49 amJust being pedantic, but technically this is a bastardized version ofKanban.Software industry just "borrowed" what was relevant and efficient about lean manufacturing and tried to apply it to a field that has nothing in common with manufacturing. The industry has been limping and mutiliating and desecrating the idea more so every year..Agile basically boils down to three tenets1. The customer doesnt know what they want2. We dont know where we are in the roadmap i.e how much we are done3. We dont know when we will finish.

author: Simon
author_rank: Unknown
timestamp: August 29, 2025, 06:49:33 am
content: Management always think that things take too much time. Is your employer an electronics company or does it specialize in something else?

author: paulca
author_rank: Super Contributor
timestamp: August 29, 2025, 07:59:43 am
content: Quote from: krish2487 on August 29, 2025, 06:32:54 amTo be pedantic it's none of those. However. Scrum != Kanban, they are different things. Scrum+Kanban+a host of other techniques are available in Agile.Agile is just a framework of tools. The real tenants don't look like that. The first tenant of Agile is.. "Working software". You would be surprised at how low on the priority the "working" part is on other methodologies.Would you prefer DSDM?Technically "Lean" - being on a level with Agile or a peer, as also a collection of techniques - was specific to the manufacturing as it holds the stipulation about work buffering, or rather not to. 1 item per swimlane per process or person. The term "lean" is referring to it fixing the problem of manufacturing with huge unbalance stock buffers creating problems and costing money.When they apply "lean" to software it's akin to a coded pushing a ticket to "Ready to test". He can't push a second ticket to "Ready to test", so he has to switch hats and go and move a ticket out of another column. ie. become a tester.The everyone does everyones' job bit can be annoying. I personal don't mind testing, but I absolutely despise doing test documentation.

author: krish2487
author_rank: Frequent Contributor
timestamp: August 29, 2025, 08:15:57 am
content: Quote from: paulca on August 29, 2025, 07:59:43 amThe "this" I was referring to was the description and not the link provided. 3 swimlanes with Backlog, WIP and done is a version of kanban. :-)and I agree that Agile is a framework and yada yada.. The term "Working Software" is ambiguous. working according to whom?the client? the developer ? the tester? qa?what is defined as working and not working? the degree to which something works? what is an acceptable fault and what are not?The three points I wrote ( sarcastically I should add ) basically sum up the clusterfuck that passes for Agile these days. people love to bitch about waterfall and how it has a huge overhead, long lead times, how the final product is out of date by the time it is delivered and so on... Yet not many complain about how Agile (in its present form is implemented, is an absolute disaster to what the core tenets of Agile framework are), about how one is never done, and constantly reprioritize work, split work constantly to give an impression of progress and shove stuff into future sprints..

author: paulca
author_rank: Super Contributor
timestamp: August 29, 2025, 08:39:42 am
content: Quote from: krish2487 on August 29, 2025, 08:15:57 amThis is a problem yes. Academics and think tanks come up with something like Agile and then industry, in particular "commercial" ventures _can't_ implement it without changing their entire business structure. So they modify Agile. They accept parts of it and deny others.This causes Agile to fail. Agile uses a bunch of tools in concert in very deliberate ways. Where some have known pit falls, others are put in place to offset that. So when companies start taking the bits they like and leaving off the bits they don't it ends up being worse than not trying to be Agile.The main bone of contention between Agile and:Private sector enterprise - the customer has to sign a contract for the company to get paid. Therefore the customer is going to want to know, "What, When, How Much?". Agile refuses to answer.Public sector - the customer has to legally define, document and tender the work, procure the funds, allocate the funds, expect the work to be heavily documented at all stages and signed off.... aka it's 90% governance and 10% management. Agile is FAR to chaotic and dynamic to co-exist with that documentation flow.That said. Kanban, scrum, dsdm, RID, TDD, flat team structure, team size, cadence.... are still all tools that can be employed.What is worse than Agile is what comes after the team and management give up on Agile - as they implemented it - the result is wasteland of chaos and bedlam as there are NO TOOLS and NO METHODOLOGIES in use at ALL!In both private and public sector I have seen the recent "surrendering" to resourcing problems with development managers. They basically deleted the role. Instead they use generic project managers with zero software methodology toolkits or even experience.My 20-30 years in te industry tells me it is the later which is causing the decline in software quality, not Agile.A conversation I had one day with such a manager:"How long will it take?""I don't know I've never done it before.""Well, it's like tiling a bathroom just, can't you just do one bit before lunch, time it, work out how many you need and multiply?"I literally walked out of that meeting.In more recent times I got told the development phase is 30 days. We have 2 devs, so that's 3 weeks. I asked how they got 30 days and they said "The business requirements document has 30 requirements". I then got upset that they divided the "man days effort" by "men" to get "days elapsed". "The mythical man month."Yet it was "me" who had to appologies from my exasperated response to this complete ignorant, incompetence.Closing the rant. On the battle ground of "swim lanes", ticket statuses. The most important column, the one most tickets end up in, IMHO, is "BLOCKED". It was so useful that "Jira" the most used, defacto, dev management tool, was forced to remove it from default templates because "business" metrics said that too many tickets got stuck in BLOCKED.It doesn't matter if you call it "BLOCKED", "DEPENDENCIES", "NEEDS INFORMATION", "WAITING ON OTHERS", they don't like the status, looks ugly on their boards and .... in large enterprise, they want a head on it, a name on it and someone to blame for it at ALL times.The solution, in the abscence of any adult software development management? Just remove the blocked status and leave the ticket in progress and keep asking the person it's assigned to for status for which he has no control or agency.

author: tggzzz
author_rank: Super Contributor
timestamp: August 29, 2025, 09:43:07 am
content: Simple point.. all processes have their strengths and weaknesses.Following a process is absolutely no guarantee of success. What is necessary is skill and intuition coming from experience.Particularly in software development, pimps HR and management have a tendency to focus on acronyms rather than experience. Plus callow youths can be bullied and cheated.Guess what the consequences are.