-
also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.
I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product. -
also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.
I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.
Exactly this, and if they really had a clue how to design things they would know to let you choose important parts like the microcontroller, because a designer usually is hugely ineffective with parts they are not familiar with.
So they are asking for the specific MCU only because they are totally clueless. Maybe somebody in the management just saw a nice Powerpoint presentation, or heard some name in some casual discussion, that's all.
Of course you can still do it but you need to communicate very clearly that your quote includes 200 hours of buffer for working with an unknown-to-you MCU and why you think this is an extremely inefficient idea. -
Sometimes i search compromise in such situations.also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.
I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.
If the client asks for, for example, ARM Cortex-M, or even STM32, this is not a problem. (unless it is something exotic or they ask for part that doesnt fit the job)
It might be reasonable, if he has plans of further software support for the product "in house", and he chooses according to the availability of programmers in his team. -
Yes; one should not be too hard-line about hardware choice.
For a company, the choice of hardware is a critical job. These days, almost nothing is multiple-sourced (except resistors, capacitors and trivial analog chips
) so you have to think long-term. In the old days, Z80 etc, you often ran right on the edge of what the hardware could do. I did consultancy for years and often used an FPGA (Xilinx 3k/4k) to make it possible. Today, an ARM 32F4 is probably 10x-100x fast enough for most jobs, and 1000x fast enough for the "Z80 jobs" especially if floats are involved. But at £5 each (500-off, 32F417, just placed the order) there is no point is going for less power unless it is something cheap (which will usually be massive volume then i.e. a lot of custom silicon).
Also the customer may well have an EMC-qualified product which they don't want to totally re-do following lab tests.
So the customer may well specify much of the BOM, like CPU, ETH chip, 3.3V LDO regulators, ADCs, DACs, and such like, for you to use.
But this goes both ways, because a consultant familiar with the chip will do a much better job (within a given budget) than one who isn't. The customer should simply not employ someone who needs to learn this. As an example, I am working on a project on which another programmer spent a number of man-months sorting out bugs in ST drivers. That kind of thing (having a solidly debugged hardware+software platform) will make that consultant worth 10x more.
I think a company needs enough expertise to make hardware (and basic software architecture) decisions and then needs to find a consultant/contractor who is already familiar with that stuff.
I have known plenty of cases where somebody had a product which they had demand for but could not make anymore because it was full of weird chips, which nobody would use in their own business One example was a box containing a transputer (yes the Inmos chip: https://en.wikipedia.org/wiki/Transputer) and for no reason; it was obviously doable with a 4MHz Z80 which pre-dated the transputer by maybe 10 years! The contract designer just loved this chip and this was an excuse to play with it. The company ended up buying up museum samples on Ebay. After many years they threw money at it and got it redesigned.
If you let the contractor choose hardware at this level, you tend to end up with - at best - a different chip for every product and in most cases with negligible overlap in the BOMs which will make your stock levels much bigger than needed. Even stocking a 1k 0805 and 1k 0603 is a PITA because if you extend that across the board you end up stocking 2x more passives. Or 1k 0603 and 1.1k 0603 where the 1.1k is probably pointless.
-
Agreed if the customer wants you to do HW + SW.also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.
I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.
But that is not this topic, it is SW only which probably means the customer had another person do the HW or if you are lucky it also still needs to be designed and you get a say in which uC etc.
-
Well, the right order is to prototype the software using a development board first and then commit to hardware.
Agreed if the customer wants you to do HW + SW.also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.
I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.
But that is not this topic, it is SW only which probably means the customer had another person do the HW or if you are lucky it also still needs to be designed and you get a say in which uC etc. -
Well, the right order is to prototype the software using a development board first and then commit to hardware.
Completely depends on the project. If the HW is "trivial" (i.e. something that can be built in hours on breadboard and jumpered to the devboard) and the application is software control heavy, that's a very good approach; you save time because you can start developing SW right away with the devboard proto while working on the final PCB in parallel.
OTOH if the "meat" of the project is, say, a motor inverter, a complex switch mode converter or similar, you can't quickly do it on a breadboard. It's all about proper engineering, PCB layout, and so on. So if done in the way you suggest, you would create a custom prototype PCB which does everything else except the MCU, and wire it up to the development board. While this is doable and I have done it because the customer wants such step in the process*, in my experience this just wastes time being an unnecessary extra step; if you commit directly to the prototype of the actual product, you are one step closer to finishing it.
*) or it's typically because the customer wants a small sub-project, because they are also subcontracting to someone else, and they don't want to provide too much in order to have another project in the future! In such case, thinking about the "big picture" is definitely forbidden. -
It also depends on the volume of the end product. Or put differently: if a product is going to be produced for less than 1k to 10k units it really doesn't matter whether you spend 1 euro or 5 euros on a microcontroller. The NRE costs will swamp the price difference. So better start with a microcontroller which is on the safe side of having enough performance. One of the critical errors I have encountered in my carreer is to (excessively) cost optimise low volume products which then leads to spending a crap load of time on getting the software optimised to a platform which isn't capable enough.
Taking this back to the topic: quoting for software development also includes a good insight on hardware abilities versus what is being required from the software. -
My motto is 'don't make what the customer wants but make what the customer needs'.
I try to do that but plenty of customers aren't interested in listening, the just want you to do what they ask. I'm fortunate in that I am mostly at a position in my career where I can be choosy about my customers, and I tend to avoid these. Still, fixed-bid is oftentimes way more hassle than it's worth. If the customer isn't understanding that this is a fluid process or feels that I am going to "run the clock" to milk them, then I really don't want to work with them. In the end it's a game of mutual trust.
-
My motto is 'don't make what the customer wants but make what the customer needs'.
I try to do that but plenty of customers aren't interested in listening, the just want you to do what they ask.
Well. That's what you're kind of entitled to as a customer. Now if what they want is not technically feasible, or some other solution would make more sense, it is your responsibility to make that clear to them. If at this point, they don't want to listen, you just don't take the job. The point is not even whether you are *right* or not. Even if it's indeed unusual, the customer may have a good reason after all. But if you take the job while you are convinced it's bound to fail, then you're going to take both of you down. Just don't do that.I'm fortunate in that I am mostly at a position in my career where I can be choosy about my customers, and I tend to avoid these. Still, fixed-bid is oftentimes way more hassle than it's worth. If the customer isn't understanding that this is a fluid process or feels that I am going to "run the clock" to milk them, then I really don't want to work with them. In the end it's a game of mutual trust.
Fixed-bid works well when the project is well defined. Right from the start. If it's not, then it's of course risky.
Sometimes, the customer is not necessarily witholding information, but they don't know/have the resources to properly specify what they want. In this case, if you think the project may still be worth it, you can offer the customer to help them with the specs. You can make that a first milestone with a go/nogo status.
-
The IBM estimate was based in large projects with multiple software team members and a range of skills (not including newby or incompetent. YMMV. Make sure you know your own productivity if bidding your services. Errors can price you out of the market or cause you to work inordinately hard to make your commitments. The largest merit of the IBM estimate is that it has widespread credibility, and if you can do better can result in excellent profits for you. But beware, starting programmers seldom can.
-
Yup very common and everyone can recognize thisMy motto is 'don't make what the customer wants but make what the customer needs'.
I try to do that but plenty of customers aren't interested in listening, the just want you to do what they ask.