|
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
|
|
|
|
|
Gerry Schmitz wrote: then he should be an analyst too
Why?
He isn't, he just makes pretty front-end designs (and implements them).
|
|
|
|
|
I'd hope that the front-ends aren't just pretty, but functional too. That means understanding how a potential user will use it, what the thought process of the user will be, what the key items of information are etc. If you as project leader need to explain every single aspect of the UI then all they're really doing is choosing a colour scheme and font. I would want a dedicated designer to be doing a lot more than that, like suggesting field sequence, types of controls for various pieces of information, availability of visual cues like icons, mouseovers and graphics etc.. etc.. Ideally a designer should understand the business process, the reason for each item on screen, the users' skill level (familiarity with the interface) etc. and then analyze that to come up with the best solution.
So maybe not need to be an analyst in the traditional sense, but certainly more than "just" an artist and HTML/CSS expert.
|
|
|
|
|
Yeah, we've had some talks about that.
He mainly designs consumer websites, but for this we had to pick function over form a couple of times.
He wasn't pleased about that either
|
|
|
|
|
You're kidding right? How can you design something you don't understand? I can't. Why? Because he "said" he didn't "understand". You've set him up to fail.
"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: You're kidding right? [...] You've set him up to fail.
That's a quick conclusion you're coming to, and not one I find flattering.
An analyst, to me, is someone who talks to the business and finds out what they have, what they want and what they need, and based on those discussions, writes a document on what the new software or features should do.
A (UI) designer then reads that document and comes up with a compelling UI so users can do what they should do as easy and quickly as possible.
My guy is the last one and I already did the first.
Besides, I already had software running, showed it to him, and he merely redesigned it.
I actually told him not to think of the business too much because I wanted a fresh perspective.
The client was, and is, satisfied.
Next time, be more like an analyst and ask before drawing conclusions.
|
|
|
|
|
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.
|
|
|
|
|
Greg Utas wrote: ISO-9001.
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.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
