The Lounge - CodeProject

honey the codewitch17-Feb-21 11:53

17-Feb-21 11:53

How often is it that we run into a situation where we have a lot of backend or supporting code to write, and the client can see no progress?

I try to code around that, and break up those tasks so I can continue to show visible progress, probably drilled into me from the dotcom days always having to keep the venture capitalists happy with what we were creating.

But sometimes it's just not possible, especially when you're in a situation coding as a one person team developing way above your individual weight class, so to speak. Add that to developing two things that have to talk to each other wirelessly in the same language, on entirely different platforms.

Hence the title of this post, with apologies to Douglas Adams.

It can be a difficult situation, helping a client manage expectations. It really helps if you've shown a lot of progress early on and built some trust in the direction of the project with the client, but at the end of the day, it's ultimately about trust and client education, I've found. The more they know about the process of developing a product, the more likely they are to accept periods of it going "dark" in terms of visible advancement.

Still I prefer to keep these periods as short as possible and as rare as possible, because otherwise I myself get uncomfortable with the project. Spending too long in the weeds can make me lose sight of where I'm headed so as much as it's frustrating sometimes having to play show and tell every week it at least keeps me grounded.

Real programmers use butterflies

modified 17-Feb-21 17:58pm.

Re: The long, dark teatime of the project

Eddy Vluggen17-Feb-21 12:39

Eddy Vluggen

17-Feb-21 12:39

honey the codewitch wrote:
It can be a difficult situation, helping a client manage expectations.

No, it ain't. It need to be done.

You don't ask a doctor to manage expectations. He/she tells you how it is and you learn to cope.

honey the codewitch wrote:
It can be a difficult situation, helping a client manage expectations. It really helps if you've shown a lot of progress early on and built some trust in the direction of the project with the client, but at the end of the day, it's ultimately about trust and client education, I've found.

"We did the heart, now working on an unpredictable liver".

What progress I make is not part of a progress bar. Sometimes it very quick, some days me very slow. Like a Windows progressbar!

honey the codewitch wrote:
show and tell every week it at least keeps me grounded.

Ehr, once a week? We do daily. And some days, nothing changes really, you just throw away a lot of code.

Bastard Programmer from Hell Suspicious | :suss:

"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

Re: The long, dark teatime of the project

Marc Clifton18-Feb-21 0:51

Marc Clifton

18-Feb-21 0:51

I find it useful to use anything from a simple todo list in notepad to a ticketing system (pick your poison) where I break down all the back-end pieces that need to be implemented, individually tested, and then integration tested, for that one simple "see, clicking on the button works!" 30 second demo.

That way I can keep my own focus, add things as I realize "oh yeah, that needs to be done too" and "oh yeah, that scenario / edge case needs to be tested as well", and, assuming whatever you're using to mark each step along the way as "done", the client can see the progress you're making.

And of course, there's the brain chemistry[^] associated with motivation to work on a task and then marking it as done!

Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions

Re: The long, dark teatime of the project

honey the codewitch18-Feb-21 2:16

honey the codewitch

18-Feb-21 2:16

I lose notes, or can't interpret them later, so I use // TODO: statements in my code. Visual Studio produces a task list out of them. The other advantage is I (usually) know right where my TODO needs to happen.

Real programmers use butterflies

Re: The long, dark teatime of the project

Gary R. Wheeler18-Feb-21 11:33

Gary R. Wheeler

18-Feb-21 11:33

I run into that - a lot. I do the UI's for our products. The main product line uses C# and WPF. I've found it's easier to prototype directly in the product and demonstrate how it works than to draw a bunch of static pictures.

Fortunately the 'client' is the rest of the R&D team on the product, along with service, sales, and occasionally training. All of them understand that the pretty face is about 0.1% of the solution.

Software Zen: delete this;

Re: The long, dark teatime of the project

honey the codewitch18-Feb-21 22:25

honey the codewitch

18-Feb-21 22:25

I do similar except i mock using winforms for gui stuff because i hate the wpf designers, and i prefer designers for RAD UI development where possible. In fact winforms is great for me the way i code because it generates code and can roundtrip from the designer so i get both methods. WPF you can do it too, but the tags are annoying, and that's what the designer generates. Plus the designer itself is near impossible to use IMO.

So i dev in winforms for the mock, separating most of the actual logic, and them port it into WPF for the final product, which can then be tweaked but all the major elements and overall flow is there.

Real programmers use butterflies

Re: The long, dark teatime of the project

Gary R. Wheeler19-Feb-21 5:04

Gary R. Wheeler

19-Feb-21 5:04

I don't use the WPF designers myself. It's far simpler to hand-code the XAML Sigh | :sigh:

.

Don't even get me started on the abomination that is Expression Blend. I've never been able to use it, given its gray-on-gray user interface.

Software Zen: delete this;

Re: The long, dark teatime of the project

Slow Eddie19-Feb-21 2:13

Slow Eddie

19-Feb-21 2:13

It happens to me every day and is happening right now.

And don't talk about managing client expectations, they want it and they want it NOW!

Then they can complain/change their mind when they see it.

Life is hard. Programming is harder. Wear your mask.

Hardware at school

Rage17-Feb-21 10:12

Rage

17-Feb-21 10:12

My kids' school (Yes, I am the computer guy of the school as a ~~part-time job~~ hobbyist Sigh | :sigh:

) has a mobile cart with 16 strictly identical hp laptops, that is used by the teachers in their classrooms. The lappies are connected to two wireless access points (1 access point for 8 laptops) placed inside of the cart, which is itself connected to the school network via cable. The school has a server and its own domain.

Problem: At most, 6 to 8 laptops can connect at the same time without interruption or loss of the wireless connection, for surfing the internet or opening word documents from the server). When more laptops are used, navigation on the network (files or internet) gets really slow or even freezes.

I lack experience in mass wireless technology, so maybe you guys can help; What I tried so far :
- putting all 16 laptops to the network via a switch and cables instead of wireless, I get an average of 50Mbit/s on each, everything runs fine, so I suppose everything is ok from the server point of view.
- access points are 300Mbit/s capable, which means a theoretical 150Mbit/s (wireless is not synchronously bidirectional) for 8 laptops, or about 20MBit/s for each of them, in an ideal world. But I get between 20Kbit/s and 4Mbit/s at the very best. The wifi network card of the laptop is 2.4GHz.
- I separated the channels (used chan 1 and chan 6 respectively on the access points), no improvement
- I used 5GHz access points with 5GHz wifi usb dongles instead of the 2.4GHz ones, with almost no improvement.

Am I hitting a physical limitation of the Wifi bandwidth when trying to use 8 machines on a single access point ? Is there any different type of access points that are designed to handle more connection or with increased bandwidth ?
Any idea of what else could go wrong ?

Welcome to the Lounge