4 ms·

Starting on evening and weekends is tough. I know one of my clients is alright with that, because our relationship is more casual, but I don't think the rest wo

by kohanz 11y ago

Starting on evening and weekends is tough. I know one of my clients is alright with that, because our relationship is more casual, but I don't think the rest would be comfortable with me operating so casually for their business (they want me to be available for calls, e-mails, etc. during the business day). The thing is, the kind of service I provide is not just "let me go away and program something for you", it walks them through the process from conception all the way to deployment. I'm in a niche field (medical), but the people I'm dealing with are generally non-software folk. To them, I am a product guy, project manager, developer, architect, etc. all in one. When I say top X%, I don't mean in a pure technical sense. I mean in the sense of, from management's perspective, if they had a project that they valued highly and knew they wanted to deliver on, who would they pick as the technical lead for that project. Which technical person would they put in front of the customer? Who would they want to be alongside them during the hiring process to find more technical folk? Those are the ways in which I've found I've been valued. I feel like I am a good programmer (who doesn't?), but I'm not the best programmer in the room. It's a more rounded skill-set and a willingness to do valuable non-programming things. A perfect example is a guy I used to work with - excellent programmer and very well-versed in computer science (whereas my background is engineering). In terms of speaking about best practices, patterns, development philosophies, etc. - he was very good, better than me (truthfully some of that stuff bores me). However, in terms of getting a project done in a high quality way, with predictability (estimation, scheduling, etc.), those are the things he didn't really care for, but I paid attention to. He's a great programmer and a good asset to any organization with a team, but I don't think he's do well on his own. Make sure you are confident in your estimation skills before going it alone.

UK-AL 11y ago
I don't think I've worked with an organisation, or a PM that could actually estimate well in software without using padding. I think the prevalence of story points, and probability based estimates(markov), proves that hard deadline estimates just don't work. I don't trust anyone who says they can actually do it on large projects, because they're either padding or lying.
- HeyLaughingBoy 11y ago
  Padding is not a bad thing if done right. The group I worked most recently with had an estimation target of +/- 20% and we were usually much better than that. It takes a lot of discipline and detailed time recording to get to the point of being able to accurately estimate a task. Padding becomes useful when you know that you always estimate 15% low. Then after you finish your "real" estimate, add 15% and you will be close to the actual value. I like to think of the estimation process as being analogous to Feedback Control theory. It requires good input data and negative feedback to stay on track.
  - UK-AL 11y ago
    How you can predict the future estimates based on recording now? What makes software estimation so difficult is that it's like maze. How long will take you to complete a maze? You don't know what's coming up in a maze, and you cant give an exact estimate. And trying to work out details to work out what is coming up, takes almost as long actually programming it. This is why I promote the idea that variation should be inbuilt into methodology. Remove the assumption software can be accurately estimated, build methodology around the fact it's hard to predict. I use guestimates of 'effort', but I don't hold people to it.
    - kohanz 11y ago
      exact estimate I think you've imposed an unachievable standard here. This is why I promote the idea that variation should be inbuilt into methodology This may well work within an agile team deep in an organization, because the business of turning "effort" into costs is abstracted from you. At the end of the day, if you're a consultant with a client, they are going to ask you up front for a rough cost estimate. If you can't estimate the time you'll need with any level of confidence, how do you propose to land their business?
    - HeyLaughingBoy 11y ago
      Prediction only works for what you know. Seems obvious, but people have a way of "forgetting" that. So you estimate within the parameters of what you know about. If what you know changes, then your predictions have to change. There are various points on the predictability curve. I used to work in an environment that was extremely predictable: projects with well-defined scope that took years to complete and changes were tightly managed. If scope changed, the stakeholders understood the cost to the schedule. An environment like that is perfect for using past time estimates vs. actual time taken to estimate future similar or dissimilar-but-related tasks. In other environments I worked in, it's more chaotic. Things change frequently, so estimates change frequently. Often you your long term vision is compromised by firefighting, so that vision has to be adjusted constantly. If you have a deadline, then tasks need to shift to meet the deadline.
HeyLaughingBoy 11y ago
Curious about that. What kind of "medical" work do you do? I spent a long time developing for Medical Devices and while I shudder at the thought getting back into that specific field, I am thinking of consulting on the periphery where the knowledge of CFR21 & FDA expectations is useful but without getting into full DMR/DHR paperwork.
- kohanz 11y ago
  Software for medical devices. A lot of my clients are very early stage (e.g. prototype development) so the regulatory burden is not as high as during commercialization. That said, one of my current projects is writing an updated SAD (software arch. doc) for a decent size application.
  - Schwolop 11y ago
    You sound extraordinarily like me. I work in the same field, am writing a SAD for a client right now, and have been thinking of breaking off from my employer to promote myself as that guy you get in for concept development phase and establishing an overall software architecture and development process. That's the bit I enjoy, but the final polishing and commercialisation phase around transfer to manufacture just saps my motivation!

by kohanz 11y ago

UK-AL 11y ago

I don't think I've worked with an organisation, or a PM that could actually estimate well in software without using padding. I think the prevalence of story points, and probability based estimates(markov), proves that hard deadline estimates just don't work. I don't trust anyone who says they can actually do it on large projects, because they're either padding or lying.

HeyLaughingBoy 11y ago
Padding is not a bad thing if done right. The group I worked most recently with had an estimation target of +/- 20% and we were usually much better than that. It takes a lot of discipline and detailed time recording to get to the point of being able to accurately estimate a task. Padding becomes useful when you know that you always estimate 15% low. Then after you finish your "real" estimate, add 15% and you will be close to the actual value. I like to think of the estimation process as being analogous to Feedback Control theory. It requires good input data and negative feedback to stay on track.
- UK-AL 11y ago
  How you can predict the future estimates based on recording now? What makes software estimation so difficult is that it's like maze. How long will take you to complete a maze? You don't know what's coming up in a maze, and you cant give an exact estimate. And trying to work out details to work out what is coming up, takes almost as long actually programming it. This is why I promote the idea that variation should be inbuilt into methodology. Remove the assumption software can be accurately estimated, build methodology around the fact it's hard to predict. I use guestimates of 'effort', but I don't hold people to it.
  - kohanz 11y ago
    exact estimate I think you've imposed an unachievable standard here. This is why I promote the idea that variation should be inbuilt into methodology This may well work within an agile team deep in an organization, because the business of turning "effort" into costs is abstracted from you. At the end of the day, if you're a consultant with a client, they are going to ask you up front for a rough cost estimate. If you can't estimate the time you'll need with any level of confidence, how do you propose to land their business?
  - HeyLaughingBoy 11y ago
    Prediction only works for what you know. Seems obvious, but people have a way of "forgetting" that. So you estimate within the parameters of what you know about. If what you know changes, then your predictions have to change. There are various points on the predictability curve. I used to work in an environment that was extremely predictable: projects with well-defined scope that took years to complete and changes were tightly managed. If scope changed, the stakeholders understood the cost to the schedule. An environment like that is perfect for using past time estimates vs. actual time taken to estimate future similar or dissimilar-but-related tasks. In other environments I worked in, it's more chaotic. Things change frequently, so estimates change frequently. Often you your long term vision is compromised by firefighting, so that vision has to be adjusted constantly. If you have a deadline, then tasks need to shift to meet the deadline.

HeyLaughingBoy 11y ago

Curious about that. What kind of "medical" work do you do? I spent a long time developing for Medical Devices and while I shudder at the thought getting back into that specific field, I am thinking of consulting on the periphery where the knowledge of CFR21 & FDA expectations is useful but without getting into full DMR/DHR paperwork.

kohanz 11y ago
Software for medical devices. A lot of my clients are very early stage (e.g. prototype development) so the regulatory burden is not as high as during commercialization. That said, one of my current projects is writing an updated SAD (software arch. doc) for a decent size application.
- Schwolop 11y ago
  You sound extraordinarily like me. I work in the same field, am writing a SAD for a client right now, and have been thinking of breaking off from my employer to promote myself as that guy you get in for concept development phase and establishing an overall software architecture and development process. That's the bit I enjoy, but the final polishing and commercialisation phase around transfer to manufacture just saps my motivation!