|
Some years back, I did a project for a company whose weekly schedule went something like this:
Monday: 8:30-12:00 - Weekly MMM (Monday Morning Meeting) to assign and prioritize tasks to be accomplished this week. Everyone's presence required!
Monday: 1:00PM-3:30 - Sales goals and prioritization for this week. All department heads, technical and support people required to attend.
Tuesday: 8:00AM - Emergency meeting to analyze customer's problem reported Monday. All departments heads, technical and support people must attend to determine who will fix problem.
Tuesday: 1:00PM - "Hot" sales call pre-call meeting to plan sales call meeting. All Dept. heads, technical and support people required.
Wednesday: 7:30AM - Emergency meeting to provide sale call support. All Dept heads.....
Wednesday: 1:00PM - "Quick" meeting to check on week's progress. All Dept.....
Wednesday: 4:00PM - "Who's available for overtime" meeting. All.....
Thursday: 7:15AM - "Why isn't anything getting done" meeting. All....
Thursday: 12:00PM - Team building luncheon. Meal and drinks provided by company. EVERYBODY requi.....
Friday: 7:00AM - "What can we do to improve productivity meeting?" All...
Friday: 1:00PM - Emergency meeting to determine who will be working this weekend to catch up. All......
Friday: 3:00PM - "So-and-so's going away party." Must attend!
I might be exaggerating a touch, but some days I spent as much as 7-8 hours in meetings which had little or no bearing on my assignment. Typical week averaged about 20-25 hours in meetings, usually during prime productive time.
Their idea was that "inclusion" was important and "everybody's ideas" were welcome (but they didn't really want to hear them.)
|
|
|
|
|
Wow... That is just like my previous company.
|
|
|
|
|
Could be worse. Meetings halt progress but don't bear anti-progress. Doing something exactly the way the customer (in my case, the product management department in the same company) wants only to find that I have to redo the whole backend because they didn't tell me of a "tiny" feature they totally need in advance, that's anti-progress. I'd rather sit in countless useless meetings than either create a patchwork solution I don't understand myself or redo the thing from scratch time upon time.
|
|
|
|
|
Your reply touched a nerve for me too. I am tired of hearing "Well, I believe that everyone should expect that if I said I wanted "Feature A", that it also meant I wanted "Feature B".
When I ask for specific written instructions I get "Well, I can't do that!"
I am a single programmer working in a small company, directly for the owner of said company. 
It would be so much easier if they knew, or at least thought about what they asked for up front.
|
|
|
|
|
I take it upon myself to ask those detailed questions up front - and keep asking them until I get an answer in writing. Then I at least have CYA'd myself. It also helps if the developer knows the industry really well, because then you can tell the customer that they didn't think of this feature or that consequence. I understand that not all developers have the luxury of being experts in some random other field, but it does help.
Bond
Keep all things a simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Hey, thanks, you actually help me feeling better about this nonsense, I'm not a lone!  Did you also have situations where you get a "spec" which is a prosaic description of what they want to be able to do, reply with a stiff spec of what you're going to build, they say "Yup, that's exactly what I want", you build it and back comes "but I can't do X" with X being explicitly forbidden by the spec they agreed to?
|
|
|
|
|
Yes. Repeatedly since 1978 when I first started working professionally.
I believe that most users do not have a clue of what they want until they see part of it.
Ours is not the reason why, ours is but to do and die...
|
|
|
|
|
Yeah... I just wish they were honest for once. Instead of an "Yup, that's how I want it" and a "No, redo it" afterwards, an "I am not sure if that's exactly it, points 1 and 2 I like, the rest no idea" would have spared me countless wasted hours. That, and I think it's a linguistical issue at times. I had repeated cases of someone agreeing to me suggesting handling certain stuff implicitly while describing how they want it to be done in a rather explicit way. Literally "Yes, that's exactly how I want it. Also, add X" with X meaning the exact opposite of what I just said. I wonder if it's really people understanding words differently or just not thinking in the ifrst place.
|
|
|
|
|
Many years ago I worked with Visual Studio pre .NET using Basic and C++. Please remember that Windows forms is a code generator. Sometimes it would generate buggy code and crash your work and the graphic design.
I finally got out from under legacy programs. I worked in other IDEs for several years. When I got back to VS I switched to .NET, C# and WPF in one large step. I was satisficed with this environment for several years.
I just started a new job with a program that was started a year ago. To my surprise it uses C# with Windows Forms. Guess what??? The code generator still crashes the program.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
|
I've been using this designer for many years, and when it crashes it is always because I did something silly (deleting a resource used by a control, for example).
I would not blame the designer at first; most of the time the issue began between the chair and the keyboard.
while (!(success = Try()));
|
|
|
|
|
i've had the designer crap itself without my help before but it's rare and usually easy to fix
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
3rd party or composite controls also tend to make the designer a tad mental.
|
|
|
|
|
That so often depends on how they're written. Of course it would help if microsoft would document the designer API better
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Everything will be fine as soon as .Net Core 3.0 will be released, it's a magic bullet that will make all your pains go away !
|
|
|
|
|
What? Instead of shooting myself in the foot I can now shoot myself in the head?
|
|
|
|
|
Quote: An angel's smile is what you sell
You promise me heaven, then put me through hell
Chains of love got a hold on me
When passion's a prison, you can't break free
Oh, you're a loaded gun, yeah
Oh, there's nowhere to run
No one can save me
The damage is done
|
|
|
|
|
I could crash the WPF designer just by looking at it.
|
|
|
|
|
|
Are you really that ugly?  
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
My C#/WPF app uses some *.h files shared with our Windows services which are written in C++. These files are compiled into a 64-bit assembly. Of course, Visual Studio and the WPF designer are 32-bit applications, so they can't load 64-bit code. The WPF preview function therefore doesn't work. I used the vaunted designer for its XML pretty-print and syntax highlighting.
Software Zen: delete this;
|
|
|
|
|
How's the crash stack look like? I've been using Windows.Forms for a decade or so and no issues so far, except that one case where my app crashed on Mono which I solved reading the crash stack.
Well, I had another interesting crash, an memory overflow. I was creating an object in an event handler and using the object in another event handler. .NET dealt with that just fine, Mono not so much. Since this thing had to run on a Raspberry Pi (so no .NET), I restructured the code.
|
|
|
|
|
The only times it has ever 'crashed', i.e cannot show the design window, is when I screwed up the code. I think you need to look closer at what you are doing. But if you have solid evidence that it's a bug in the IDE you could always report the problem to Microsoft.
|
|
|
|
|
Yeah, I am with the others in that I've been using WinForms for well over a decade and the only times that the designer has gone tango-uniform is when I've monkied with the designer code myself and dorked something up. We use the Infragistics controls extensively and we've had a few times where the UltraWinGrid has lost it's styling settings but those times are pretty rare. All in all I've not had any significant issues with VS (2008, 2010 and now 2015) and WinForms. (knocking on wood...)
|
|
|
|
|
I've actually had a better time working in winforms then WPF, when I update a graphic, it shows right away in winforms designer, but the WPF cashes the original image until i restart visual studio, but the compiled version shows correct  ? more than half time the properties side bar in the designer refuses to update or allow me to click on anything in WPF, so I revert back to typing in xaml which I highly dislike.
And yes I could use Blend that seems to work well, but i dislike jumping out of the environment that I'm working in for a small tweak, like changing an image.
I can't remember winforms designer having any more crashes than the WPF designer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
