Structured, yes or no?
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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! :omg: ), 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
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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.
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
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
-
I've always been a bit of a cowboy coder. Has everything to do with my first job and it fits my personality, I think. Not one for lots of rules or things set in stone. My customers prefer it that way too, they're too busy to worry about the development process, they just want a working project delivered. I've always disliked scrum for that reason, way to much red tape! Oh, and I dread the "we can't do that until the next sprint" reply from companies! X| So I'm now working with an external designer (who is also a friend), and he has some problems with this way of working. It's basically constant changes, shifting priorities, loose deadlines (if at all), etc. He prefers to know what's up for today, the next two weeks, and the coming months, in that order. A change should be requested up front, planned, etc. So basically he prefers (the rigidity of) scrum*. It even affects his mood in that he doesn't feel like working because he doesn't know what to expect. As far as I know he's not on the autism spectrum. Needless to say, as a good developer-manager I'm now trying to keep him out of the chaos and bring some structure to his tasks. What are the preferences here? * I know scrum should be the opposite of rigid, but that's not at all how I've experienced it
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander Rossel wrote:
What are the preferences here?
Most of the places I've worked followed ISO 9001[^] standard which has strict requirements for planning and documentation. There really isn't much of a choice for some people. In order to get ISO certification[^] there has to be a full-time auditor on staff to ensure the process is strictly followed.
-
Sander Rossel wrote:
What are the preferences here?
Most of the places I've worked followed ISO 9001[^] standard which has strict requirements for planning and documentation. There really isn't much of a choice for some people. In order to get ISO certification[^] there has to be a full-time auditor on staff to ensure the process is strictly followed.
ISO-9001. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
ISO-9001. :laugh:
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
ISO-9001. :laugh:
Yeah, tell me about it. It's been revised over the years but at one point we were required to write the requirements and documentation *before* we wrote the code. Was damn near impossible to do without revisions. I worked on some of the vessel nav software you see on this site[^]. Looks like they even kept my GUI after 15 years. There was an upside, the beer in Norway is much better than the watered down stuff here. :)
-
Greg Utas wrote:
ISO-9001. :laugh:
Yeah, tell me about it. It's been revised over the years but at one point we were required to write the requirements and documentation *before* we wrote the code. Was damn near impossible to do without revisions. I worked on some of the vessel nav software you see on this site[^]. Looks like they even kept my GUI after 15 years. There was an upside, the beer in Norway is much better than the watered down stuff here. :)
I don't have a problem with writing the requirements before the code. But I have a big problem with detailed design documents. My experience is that trying to do much more than a high-level design is a waste of time. The code will later speak to me, and the details will change. I saw more than a few detailed design documents that ran to 200 pages and more. All that time would have been far better spent coding from the high-level design and iterating the software to make it excellent.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I don't have a problem with writing the requirements before the code. But I have a big problem with detailed design documents. My experience is that trying to do much more than a high-level design is a waste of time. The code will later speak to me, and the details will change. I saw more than a few detailed design documents that ran to 200 pages and more. All that time would have been far better spent coding from the high-level design and iterating the software to make it excellent.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Heh, We were inventing some of the technology. It's hard to document and determine requirements for technologies that don't exist yet. ISO 9001 just doesn't work well for R&D, it works better in other areas. :) One of the things I really miss about working on maritime/navy software was my exposure to high level/new technologies.
-
A couple, but sometimes it's like that. Last month, I had months of work ahead of me, but someone quit his job and months of work kind of evaporated and priorities for this customer changed quite a bit. Yesterday I had a call with the customer and we're now going to pick up a new project while postponing the previous one. So, I now have weeks of work for this client alone, while yesterday I had none, while last month I had months (talk about churn) :doh: Of course, that resulted in other customers getting more priority with their changes. Meanwhile, another customer called this morning, his reporting didn't work, took me half a day to fix. Of course I'm not doing everything ASAP, but when a client calls it usually has to be scheduled in later this week, or at least somewhere this month.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Scrum grew out to solve a different problem that the one you have. It was an answer to the world of large teams running waterfall with Gantt-charts and other horrible things. So I would cross that one our right away in your situation, but I would also recommend you stop with remarks as "I know scrum should be the opposite of rigid, but that's not at all how I've experienced it" as that directly translate to "I tried to use this screwdriver as a hammer, and it sucks so it is a bad tool." Kanban is a known "lighter" alternative, but it might still be too rigid for you. Look at it and see if there is one or two things you can take our of it - maybe as little as a prioritized list where you show restraint from changing the top item unless really needed is enough. I have seen teams receiving "Why is that feature I asked about just before the last two emails asking for urgent features not finished yet" emails while they are still working on the last email. A list makes something like this apparent - it it might also make it easier both for you and the customer to judge "do I REALLY need to change the priority right now, or will tomorrow do".
-
Scrum grew out to solve a different problem that the one you have. It was an answer to the world of large teams running waterfall with Gantt-charts and other horrible things. So I would cross that one our right away in your situation, but I would also recommend you stop with remarks as "I know scrum should be the opposite of rigid, but that's not at all how I've experienced it" as that directly translate to "I tried to use this screwdriver as a hammer, and it sucks so it is a bad tool." Kanban is a known "lighter" alternative, but it might still be too rigid for you. Look at it and see if there is one or two things you can take our of it - maybe as little as a prioritized list where you show restraint from changing the top item unless really needed is enough. I have seen teams receiving "Why is that feature I asked about just before the last two emails asking for urgent features not finished yet" emails while they are still working on the last email. A list makes something like this apparent - it it might also make it easier both for you and the customer to judge "do I REALLY need to change the priority right now, or will tomorrow do".
lmoelleb wrote:
but I would also recommend you stop with remarks as "I know scrum should be the opposite of rigid, but that's not at all how I've experienced it" as that directly translate to "I tried to use this screwdriver as a hammer, and it sucks so it is a bad tool."
I'm really not the only one saying that and I think many people here would agree with me. Actually, I believe one of the writers of the original manifesto said something along the lines of that it was meant to grow more agile, but teams are now stuck in their scrum ways and holy two-week cycles. I think it's so hard to implement correctly because it's based around change and many people don't react to change very well. I've literally been in the situation where we were two days into a sprint when management came in and said, "things changed, we don't need what you're doing now, we need that other thing." And the team was like, bad luck, we're finishing this sprint anyway because that's what we committed to, and then start on the work you need. That's two weeks wasted! Or how about, this story has a very high priority, but we don't know if the business wants the button red or green, so we'll have to refine it further and it'll have to wait for the next sprint. That's not adding value, that's just mindlessly clinging to some process to the point where it does more damage than good. Two distinct teams by the way.
lmoelleb wrote:
Kanban is a known "lighter" alternative, but it might still be too rigid for you.
Kanban is actually fine! Not doing it now since I'm alone most of the time, but a good one for working with that designer. I'm working on growing the team and I definitely need something like that.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Sander Rossel wrote:
What are the preferences here?
Most of the places I've worked followed ISO 9001[^] standard which has strict requirements for planning and documentation. There really isn't much of a choice for some people. In order to get ISO certification[^] there has to be a full-time auditor on staff to ensure the process is strictly followed.
Ugh, that kind of thing is just about having a process to have a process. It probably works for some businesses and some people, or maybe people thought it did because other things didn't. Maybe I'll someday look into it or need it, when I'm bigger and want to attract a specific kind of customer who's willing to pay for such overhead. Although I've worked at an ISO-9001 certified company (or at least they were in the process of getting certified) and it was pretty much a joke. Worst company I've worked at, mostly because of a few very incompetent and toxic people. Because ISO checks processes, not competence or result :)
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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
Gerry Schmitz wrote:
then he should be an analyst too
Why? He isn't, he just makes pretty front-end designs (and implements them).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :laugh: 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.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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! :omg: ), 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
DerekT-P wrote:
SWMBO
Had to google that one :laugh: You make some excellent points! I'm pretty much in the same situation as you. Not helping multiple clients a day often isn't an option. I also charge by the hour for first-line support and small changes and often work on fixed price basis for larger projects (although that also means the customer can't change their mind as much :laugh: ). The problem is I'm now switching from just me to just us, which requires a little extra documentation I guess. Although I've worked like that in a company with five employees, just that the notepad is replaced with a kanban board or something similar. It seems many people work for one client on one project though, and can't really imagine what it's like to have multiple clients and multiple projects. I've been in both, but prefer it this way, more variety that way :)
DerekT-P wrote:
they'd insured a North Sea drilling platform that exploded, and they couldn't pay the resulting claims. :(
Ouch, those things ain't cheap. Sounded like a nice role, not one I've heard of either.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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. :omg: :) 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 :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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 :sigh: 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.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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 :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
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.
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... :doh:
