|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Randor wrote: In order to get ISO certification[^] there has to be a full-time auditor on staff to ensure the process is strictly followed.
No, that is absolutely not the case.
I run a one-person consultancy/development business and it achieved certification[^] at the first attempt in 2007, I believe one of the first 50 such micro-companies to do so in the UK. I passed external audits in 2008 / 2009 as well. Working with the Professional Contractors Group as it was then (now IPSE[^]) we (me and the company!) were given an outline structure for our quality system, plus some (quite a small number) of template documents. I admit it took me quite a long while to get my head around the concept of the system, but it eventually dawned on me that it was just a document change control system. (It was actually hosted on a SubVersion server). The process of working out what the company actually needed was very enlightening and brought about genuine improvements for me and my clients. The initial certification process was tough, as expected. External inspectors went through everything and needed to see evidence that the systems were in continual use. However 90% of the admin "burden" related to managing the limited company, rather than to actually doing any consultancy / development work. By choice I extended parts of the quality system to cover that (around issues like implementations, disaster recovery and backups in particular).
I had hoped that having ISO9001 would open up doors to new clients and allow for rate increases. As it happened, shortly after gaining certification I also gained a major client who gave me as much work as I could cope with, and at silly (high) rates. Contact with him brought in many other clients in the same industry and I was turning work away at one point. When it came to renewal of certification I didn't bother; I had dispensed with some parts of the quality system that were adding no demonstrable value, but continue with others to this day.
I understand that of course ISO9001 has developed since 2007, but I'm sure it's still attainable to any micro-business, at very affordable prices and without massive overheads. Certainly no need for a full-time auditor on staff! 
|
|
|
|
|
DerekT-P wrote: I understand that of course ISO9001 has developed since 2007, but I'm sure it's still attainable to any micro-business, at very affordable prices and without massive overheads. Certainly no need for a full-time auditor on staff!
An existing employee could be designated as the auditor at that time. With you being the sole proprietor it would have been you. We also appointed an employee as the internal auditor for the first year, but the workload was too high. Had to hire a new FTE for that role.
The ISO standard has been revised over the years. After chatting with @GregUtas yesterday I checked and the documentation process was changed in 2015[^]. I wasn't kidding when I said it was damn near impossible to follow.
|
|
|
|
|
It's certainly true that ISO9001 is about processes rather than results. I found that by having documented processes, although there was a setup time initially, things actually did run a little more smoothly / with less input once in place. In that way it was more or less neutral in regards to my time (time saved vs. time maintaining / auditing the QMS) but I had better systems in place in the event of issues arising. By implementing a feedback loop with customers I was confirming that I was meeting their expectations and, with their consent, their feedback formed part of my marketing. But you're right in that there was no direct impact on the quality of the code I wrote or, for that matter, the advice I gave. As I found, there was a steep learning curve initially followed by an a-ha! moment after which it was relatively straightforward.
|
|
|
|
|
Since beginning my work with legacy code I have appreciated order and structure much, much more. One of the first things I asked for (out of need) was a style guide, which I got (after a fashion), and next was to refactor the code to properly nest so that I could collapse bits that I didn't need to scroll through to get to the bit I needed to work on, which got a solid (and well deserved) 'no'.
We have just begun to use sprints and a loose sort of scrum to work through the many updates, and I think it will be very useful in 2 important ways: user story and dod, and documentation. Making clear the definition of done is a huge help to avoiding rabbit trails, and having a product backlog that I can add to means that those trails can be documented for future sprints. Documentation is a thing that has been sorely lacking in our product, so this micro documentation on each task could potentially be pulled together into a cohesive whole. It might be pie-in-the-sky, but I'm the hopeful sort.
I also like being able to see the product backlog and the things being worked on in the current sprint. We use asana for the job so it's all shared - we see it all. It makes me see how my little piece of the puzzle will work toward a bigger picture that I can now better see as well. I despise being kept in the dark where vision is concerned. I need to know what we are aiming for to both do my best work toward that vision and feel like my work matters.
|
|
|
|
|
One of the main purposes of agile (and scrum) it to attempt to protect
developers from constant "instant" change imposed from outside, cut down
on chaos... exactly what you are imposing on your project partner.
I prefer structure.
|
|
|
|
|
Curious... Have you codified your areas of influence?
Are there any limits on what you can arbitrarily change that affects this person?
Typically, in these cases, we separate the resources and isolate their dependencies.
So, you can have the freedom to change, within a framework agreed upon, so the other person has some solid footing.
You clearly brought them in for a reason, and working to leverage that should be the goal.
At the same time, I understand where you are coming from. We had someone refactor code (correctly to clean it up), but it impacted ~20 of other projects, a handful of which, were being actively developed.
The resulting merges wiped out the value of the changes. Adding real costs to other peoples assignments.
Which, to me, simply means... It is about communication and properly splitting areas of control...
Put yourself in their shoes, if every day, you woke up, and you were having to rework everything you did for the last couple of days, because they were so "dynamic"... It wouldn't be long, before you would be better off waiting to see what tomorrow will bring...
|
|
|
|
|
This guy has completely different assignments, most are creating some visual designs without code.
As far as code goes, I told him to make a separate branch and do as he must and I'll figure it out later.
He's only had to rework his original designs because the customer disagreed with a few minor aspects.
And then make some new designs, while still working on old ones, because some priorities changed.
Nothing too extreme, I'd say 
|
|
|
|
|
|
Excellent reads!
You can't really say scrum may not be your best solution without getting some hate, but I agree wholeheartedly 
|
|
|
|
|
Sander Rossel wrote: As far as I know he's not on the autism spectrum.
Also (with few exceptions), everyone is on every spectrum -- hence the name.
|
|
|
|
|
I like waterfall so any last minute changes are things that will take 2 more years to add to the project. Then again clients don't exist in my line of work.
|
|
|
|
|
I agree, Waterfall is just Scrum with two-year sprints. 
|
|
|
|
|
This comment will add very little to Sander's post but it is posted to say I admire the intelligence and thoughts of the folks who responded to the query. What a bunch of smart people.
When I started coding VB 6 I would use what I learned in an elective Basic Programming on a DEC writer NO screen. That was to draw a flow diagram. It was a terrible idea as I had no idea what the VB 6 project would do. Slow forward too many years and I have learned to draw my screens (Forms) and think about the controls that might be needed. This makes the process of writing the code easier. Yes I am up to vb.net now.
Last summer I started woodworking table saw the whole nine yards. Wanted a workbench/outfeed table.
So I did a sketchup drawing made a cut list. It dawned on me that this process was the very similar to my rudimentary design process for coding.
I had to farm out my milling for the table legs as I have no jointer or planner. I wanted the 4 by 4's to be 3 in square.
I have no friends that code and have often thought it would be fun to work on a BIG project with a fellow coder.
I have no idea how working on a BIG project with someone else would work
After reading every comment on this post I am guessing 70% of the people who responded work solo.
It would be nice to know. So someone make a post posing the question.
While I have been here for sometime that type of post for me is above my pay grade.
|
|
|
|
|
The process goes a bit as follows.
An analist meets with "the business" and divides the work into stories.
To create and organize stories the team uses a scrum board with backlog, like Jira, Trello, Azure DevOps, etc.
You then have meetings to estimate how long the stories take to complete the complexities of the stories (complexity can be expressed in T-shirt sizes or numbers from the Fibonacci sequence, for some reason).
A product owner prioritizes the stories based on other meetings.
You then meet to plan the next sprint (any stories you didn't complete from the previous sprint are moved into the next).
During these meetings you also divide the stories into tasks.
Any stories that aren't 100% clear can't be estimated and have to go back to the story owner (mostly the person or manager who requested the change).
After a while you should know just about how much complexity your team can handle in a two-week sprint, so you can plan accordingly.
Every day you have a stand-up with the team to briefly discuss what you did, what you're going to do and if you need any help.
During this stand-up you'll move tasks and stories from "to do" to "doing" or "done".
At the end of the sprint you'll have meetings about how the sprint went and what could've been done better.
You'll have at least two or three one to two hour meetings a week (I've even heard people say they should be three to four hours!) plus a daily 5 to 15 minutes stand-up.
During the sprint it is possible to move some stories around if priorities change, but that should be avoided.
At the end of the sprint you should be able to deliver the stories, and so real value, to the business.
As for the code, you'll use tools such as Git and GitHub, obviously.
So yeah, prepare to lose at least half a day a week on meetings while being more or less agile in two-week increments.
Keep in mind not all teams do everything like this, but this seems to be a popular format.
I've been in three-week sprints, half hour to hour stand-ups, teams skipping meetings like the retrospective, teams doing only the stand-up with a Kanban board and calling it scrum...
Scrum absolutely has its merits, but it's not the golden bullet some people would have you believe.
|
|
|
|
|
Scrum is the absolute minimum amount of process that can be imposed on an organization that is process-averse. That you find it too rigid makes you less of a cowboy and more of a wildman. (I might have said wild indian to carry on the cowboy motif, but that's not politically correct).
If you let customers change horses in the middle of a two-week sprint, you are embracing a degree of chaos that probably hurts your profit as a consultant, or needlessly raises costs to your customers. I bet this is not your friend's first rodeo (Yee-hah! More cowboy metaphors). His experience says this is a bad way of working. That's certainly what I would say.
More discipline is called for. It's better for you, better for your partner, and better for your customers.
|
|
|
|
|
Most of my clients don't have enough work to plan in two week sprints anyway.
It would be a sprint for multiple customers.
So let's say the sprint starts on Monday, a customer (who may or may not have work in the current sprint) calls on Tuesday, and I have to tell him they'll have it at the end of the next sprint (four weeks from now)?
That's a recipe for losing clients.
There's a lot less than scrum that can still count as a process.
SeattleC++ wrote: His experience says this is a bad way of working. That's certainly what I would say.
I'm actually more experienced than him in pretty much every way possible (number of jobs, time in the field, methodologies used, etc.), but he is by far the better front-end programmer.
He's never done anything else than scrum, I have, and that's probably why he's having trouble adapting.
And in my experience, I'm saying everything we do besides what we're doing now is absolute overkill as far as work planning goes.
Although I'm now making sure his tasks are a bit less open for interpretation, some people need a bit more management and I accept and respect that.
So, instead of "can you start with whatever form and fix it like we said last month, tell me when it's done." I'm now saying "can you make sure fields x and y on form z are positioned like a and b and I want it by the end of the week." (this is an example, not a literal conversation, before people start making assumptions based on this too).
modified 21-Jan-22 5:50am.
|
|
|
|
|
I've mostly worked on multi-man-year projects. It's hard for me to imagine a whole project that takes less than a week, but requires iteration and needs more than one worker. You have to do what works for you, and sprints are apparently not part of it.
Your partner was suffering from a need for a more concrete design to grind on, and you have learned to provide it, which is good.
|
|
|
|
|
SeattleC++ wrote: It's hard for me to imagine a whole project that takes less than a week
More like tasks than projects (or tasks that are part of an ongoing project, if you like).
The tasks usually don't require more than one worker, it's just that I'm not a (graphic) designer so those aren't tasks I can do myself.
So this guy goes from a full scrum team from another employer to a task here and a task there for me.
Maybe it's good to mention he doesn't work for me full time, but a few hours a week.
I'm getting a full time employee later this year, will probably switch to a more scrum/kanban approach when that time arrives.
It still won't be a full fledged project team, but hopefully getting there in the next two years or so
|
|
|
|
|
Everybody hates SCRUM. I do, too. But I think, the larger the team and the more innovative the project, the more SCRUM you need. Unfortunately! Haven't seen anything better for teams of 5-8 or more people yet.
|
|
|
|
|
If everybody hated it we'd be doing something else by now.
It's true lots of people don't like it, especially the overhead, but there are still many people who follow scrum religiously.
|
|
|
|
|
With "everybody" I meant every developer. The religious people are usually managers. 
|
|
|
|
|
That's a challenge. In your shoes I would look for parts of the work which can be compartmentalised and ask him to work on them. That means he can work his way and you in your way.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
