|
I can see why you wouldn't care if the customer is paying anyway. It's probably a personality thing. Like your colleague, I don't like being yanked around in one direction, then another. I would tell the customer that churn has a cost and suggest that we work together to better determine the requirements in advance. If they didn't want to do that, OK, they're the customer. But not one that I'd gladly take on again.
|
|
|
|
|
Greg Utas wrote: I don't like being yanked around in one direction, then another.
I don't see it that way.
Obviously, my client doesn't really know where they want to go, or they do, but something changed.
I try to support them the best I can and if that means going from one direction, then another, that's fine by me.
And sometimes I simply tell them "I want to do that, but I'm also doing that other thing for John, so you should probably get together and work out your priorities and then get back to me."
Recently, I had to tell a client "look, two weeks ago you said this thing, which is what I did. Now you say another thing and I have to change it again. We really should prevent this in the future..."
But you know, stuff like that happens in business, things change, priorities change, people change.
Also, I charge by the hour, so it's all paid time, which greatly helps 
|
|
|
|
|
I beg to differ.
Money is not the only reason I write code. Another reason is the satisfaction of knowing that people find it useful and are using it. Basically, I'm happy when my client are happy with what they paid for. This is also a good way to ensure repeat business.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
My client is so happy they said they'd prefer to ditch some really large suppliers in favor of me.
Unfortunately, that's not really an option right now.
I had two projects where a customer really didn't use what I wrote for them and that just sucks (although they did become a repeat customer and are now using another system I wrote and they're now even asking for yet another!).
They can be using your software to full satisfaction and still change priorities though.
|
|
|
|
|
I have had branches waiting for weeks or even months for review and release (this was before scrum), and they do not merge easily by that point - and as you said, going back into that code after such a long time is a churn.
|
|
|
|
|
That's despicable. For many years, the products I worked on used a proprietary code repository that dated to about 1980. A group owned each file, and one of its members had to open it for you if you needed to change it. You could work on it privately, but you'd ask for it to be officially opened once your changes were reviewed and you were ready to commit. Once the file was open, you'd commit your changes quickly so that anyone else working on the file could synch with your changes and ask for the file to be opened for their changes. Any significant delay in this process would get escalated to move things along. It worked quite well, though I can see it being a problem in open-source projects where escalation isn't possible.
|
|
|
|
|
Ours is similar in structure, if not in timing. We each have our own repository with our own branches that we can push to the main repository when ready. They are then reviewed, any repairs made, and then merged with the development master and pushed live by the lead. I 'can' push things live, but only in 'emergency'. Our bottleneck is that we have only one reviewer and he's also an equal part of the dev team. So pushed branches got forgotten.
I am hopeful that the sprint/scrum process will eliminate that in future.
|
|
|
|
|
The main difference in our processes seems to be that, once you push, there's no need to merge. You've been working off the latest version, so your new version fits right in. Anyone who was working privately on the same file then has to synch with your changes before they can push. This relieves code owners of the task of having to merge incompatible versions.
|
|
|
|
|
Structure, with flexibility of course. Without it's all a mess of work hours but with no idea of the direction.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Too much structure can cause a lot of useless output.
My current example:
I'm testing the MVVM Toolkit from MS (which is based on the very popular MVVMLight from Galasoft).
When you install the NuGet package of the MVVM Toolkit it comes along with 6 or 7 other packages.
And when you create a new build it adds more than 100 files to your debug folder !!
MVVMLight from Galasoft did add less than 10 files.
|
|
|
|
|
Well, and then there is me: Why on earth would you use a toolkit for MVVM. But I am starting to accept that either:
1) I did not understand MVVM and by accident created something that is way simpler to program
2) A lot of other people are misunderstanding MVVM.
I do not care which one it is, as long as those toolkits are kept away from my software. 
|
|
|
|
|
I use it for my hobby project.
Now found out the >100 files are only copied when .net framework 4.6 is used.
With .net framework 4.7 it copies only < 20 files to the debug folder.
|
|
|
|
|
There are a lot of "filler" DLLS to bring 4.6 up to .NET Standard compliance - which might be what is used by your framework. The best solution if this is a problem is to stop using 4.6 - the world is not going to stop using .NET standard, so even if you skip this framework (well, to be honest, as it is an MVVM framework I would skip it no matter what) then the next library you find for something else will have the same problem.
|
|
|
|
|
Try something like a Trello task board. If your project is hosted on GitHub, there's a Trello add-in that will allow comments during commits to become tasks.
Here's a sample board
New Requests
Requests being worked
Requests being tested
Requests completed
This will give both of you the ability to see what's in queue and give your friend the structure he needs.
|
|
|
|
|
Yeah, it's probably going to be something like that.
Done that before and works pretty well.
|
|
|
|
|
Think of the addition of structure as simply the next step in your evolution as a developer and businessman. It's inevitable.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I know you're right 
Just have to get it out of my head and into some system or another.
Kanban has been mentioned a few times in this thread, probably going to be something like that.
|
|
|
|
|
When working alone, do whatever you feel comfortable with. I suspect that even then, you impose some structure on your work.
When working with someone else, some structure is essential. This is necessary so you can coordinate your work - for example if your team member is designing the UI, you don't want to have him/her sitting around waiting for you to implement & test it while you write the data access layer. This does not mean that you need to implement all the requirements of the American DoD.  
As always, YMMV.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: you impose some structure on your work.
Yes, I do.
Daniel Pfeffer wrote: for example if your team member is designing the UI, you don't want to have him/her sitting around waiting for you to implement & test it while you write the data access layer
Sounds like a matter of communication, call it a stand-up if you will!
Talking to coworkers shouldn't be dubbed a process, but common sense
|
|
|
|
|
Good to see this discussion, and particularly that there are plenty of (other) folk out there who "just get on with it". I think the key is absolutely the number of people involved, even if they're not directly developers, but maybe sys admins etc. Currently I've active projects for three different clients, and juggling priorities on a daily basis between them. (All the while trying to keep my hours down as I'm nominally retired and SWMBO expects me to be available for walks / shopping / chores at home!)
My "planning" process is essentially a notepad file per client of high-level requests. I charge for "reactive" stuff by the hour (e.g. 1st line support, urgent fixes) and for new features on a fixed-price basis. The fixed-price stuff means that I have effectively drawn a line around how much is going to change and how long I should be spending on it. Where I know that these mini-projects have an interdependency (e.g. they involve changes to the same module) I'll combine them and quote for the combination. Because I've been the sole "IT person" working with these clients for an average of 5 years, I know their businesses very well and am (almost) integrated into their staff. That means that, while ultimately they set the priorities and authorise work, I'm in a position where I know the impact of changes and can give a good steer as to what is going to have the most positive impact per £ of my time on their business. I can back that recommendation up and 95% of the time they are happy to go with it. Of course new requirements come into the business, often driven by specific customers, but I can assimilate the pros and cons of changes very quickly and suggest changes to schedules to accommodate. As far as my clients are concerned, they're each my primary focus. I try to make sure that work for one never adversely impacts projects for another. If it looks like there may be a clash coming up, I ask one of them a difficult question that needs a decision; that usually delays things for a couple of weeks!
Because it's "just me" and the projects are big but not massive, I can internalise all the pending changes and understand what the dependencies are. If it were a bigger project with a bigger team, that probably wouldn't be possible and we'd need to plan it all out in much more detail.
Before going freelance (some 30 years ago now! ), I was in a role called "Design Authority" which involved co-ordinating all the various development projects of a fair-sized corporation. My job was to make sure that things didn't clash, that we weren't re-inventing the wheel, that we were using common standards and terminology, consistent UIs and so on. It was sort of meta-project management but even there, because I was working mainly at the conceptual level, there was no need for a formal methodology. The individual projects used their own management structures and tools and effectively I was there as a source of "best practice" but also assisting in cross-project communication and knowledge sharing. Looking back, it should have been a really fun role but I was too inexperienced at the time and didn't make the most of it. The company went bust - nothing to do with the IT processes, they'd insured a North Sea drilling platform that exploded, and they couldn't pay the resulting claims. 
|
|
|
|
|
|
Sander Rossel wrote: It's basically constant changes, shifting priorities, loose deadlines (if at all), etc.
No offense, but I would not want to work with someone like you. That sounds like a lot of unnecessary stress.
|
|
|
|
|
It's not that bad.
But yeah, you'll probably work for two, sometimes three, different customers in a day.
In the case of this designer, he works for one customer, but that customer has... Specific wishes and multiple projects
And I'm not one to say "no" to a customer.
It's like someone else here said, it's about getting things done.
Customer calls, I'll start working on it (mostly, depending on some priorities).
I really wouldn't know how else to plan it when you're a small shop with different clients.
He's just used to working in a bigger team for a single client on a single project.
But yeah, I guess there's a difference in working for a small startup or bigger companies.
Some prefer one, some the other.
|
|
|
|
|
Being in a very similar position, I'd agree it can be stressful. But most of the time, it's just "interesting" whilst occasionally "exciting". Unfortunately as two of my clients are in the same industry, their seasonal swings coincide and that makes February and August in particular quite pressured. But because I know that, I can prepare them and get one of them at least thinking a couple of months ahead of the other.
What it does mean is that whilst I can usually concentrate on one particular thing for up to a day, I frequently chop and change so there's no chance for boredom to set in. I'm not away from a bit of code for long enough to forget what I'm in the middle of, and frequently a break and a look at something different will allow an answer to some complex problem to just pop into my head, which doesn't happen so easily if you're focussed on it for too long.
The only time it gets really confusing is if an end-user phones me up with an issue (which I discourage, as I prefer to work funny hours). Then it can take me a few moments to work out which client is involved and we can be at cross-purposes briefly. Worse, there's one service supplier I liaise with who supplies services to TWO of my clients... 
|
|
|
|
|
If he is a designer, then he should be an analyst too. Tell him to reverse engineer what's been done so far and come up with leveled (function) diagrams. You can then discuss things, moving forward, from a common base.
Level 0: context diagram; 1 page
level 1: main functions (max 7) 1 page.
level 2: explosion of level 1.
etc.
Stop at any level / function once achieving enlightenment.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
