3 ms·

I have a few questions for people who largely agree with this article. Firstly, where do you stand on developers having input into the design process? From my

by ddek 5y ago

I have a few questions for people who largely agree with this article. Firstly, where do you stand on developers having input into the design process? From my experience, developer input in specification has led to better fitting solutions. Personally, I wouldn't like to be in a situation where I am instructed what to do, that sounds extremely tedious. If you agree that developers should have some contribution to the design process, then two points in this post are in conflict. Either the developer must be interrupted to participate in synchronous design decisions, or participate asynchronously on a much-maligned platform like Jira (better alternatives available). Is there another way?

nofunsir 5y ago
Design and documentation before implementation. Elevate “developers” to “Engineers” and treat the situation like building a bridge or a tunnel or an aircraft. Of course there will be some small changes along the way, but that doesn’t mean we should hold twice daily ceremonial meetings.
deleted 5y ago
[deleted]
mikewarot 5y ago
You can't be having requirements change while you're writing code... those happen in phases, those phases can be years, months or even weeks, but should never be less than that. Coding on quicksand will never work out. I was the programming/tech half of a small company back in the MS-DOS days. The first cycle was 3 months (delivery of program/hardware as specified). When it turned out to meet specifications, but was impractical in real use, we agreed to make changes. The prototype took about a month, and the customer liked it. We then switched to a really interesting form of agile. Every day I drove out to the Will County Generating station. The customer (Russ) would bring in a random generating plant employee, and tell him "Here's a computer, I want you to do X,Y and Z... I know this isn't your job, and you won't be judged if there are problems... This is Mike... anything that goes wrong is HIS fault" Russ was an amazing teacher, in the end. The first thing I learned is that "Press F1 for Help" should always be visible on the screen. We quickly settled into a pattern. We'd build a list of bugs/design changes, and I'd fix all the problems in our list, and then we'd test again... after a year it was judged suitable for wide distribution. I loved that job, I supported that program for about 5 years, driving all over the place, meeting interesting people and solving their problems.
- ddek 5y ago
  I hate to say it, but that sounds a lot like agile! I had a very similar experience building a scheduling app for a UK freight company. They wanted a domain-heavy platform where they could manage their fleet of locomotives and wagons, with a lot of computer assistance. The product owner was a gem. Once he warmed up to the process, we'd get him in a room and he'd talk and talk and talk about everything he found difficult. I mainly worked on the project alone, and bit by bit we addressed his issues. The issues grew more and more specific, until about 3 months post-release, where he came in and had nothing left to add. There wasn't even a wish list left. It was done. This was where I came to agree with the agile 'small batch size' approach. Mistakes come cheap and fast. Most mistakes are usually communication issues, rather than technical. That's not to say that requirements were changing while writing code - it's just that we had good feedback loops, and a short phase had us fixing the real problems faster.

by ddek 5y ago

nofunsir 5y ago

Design and documentation before implementation. Elevate “developers” to “Engineers” and treat the situation like building a bridge or a tunnel or an aircraft. Of course there will be some small changes along the way, but that doesn’t mean we should hold twice daily ceremonial meetings.

deleted 5y ago

[deleted]

mikewarot 5y ago

You can't be having requirements change while you're writing code... those happen in phases, those phases can be years, months or even weeks, but should never be less than that. Coding on quicksand will never work out. I was the programming/tech half of a small company back in the MS-DOS days. The first cycle was 3 months (delivery of program/hardware as specified). When it turned out to meet specifications, but was impractical in real use, we agreed to make changes. The prototype took about a month, and the customer liked it. We then switched to a really interesting form of agile. Every day I drove out to the Will County Generating station. The customer (Russ) would bring in a random generating plant employee, and tell him "Here's a computer, I want you to do X,Y and Z... I know this isn't your job, and you won't be judged if there are problems... This is Mike... anything that goes wrong is HIS fault" Russ was an amazing teacher, in the end. The first thing I learned is that "Press F1 for Help" should always be visible on the screen. We quickly settled into a pattern. We'd build a list of bugs/design changes, and I'd fix all the problems in our list, and then we'd test again... after a year it was judged suitable for wide distribution. I loved that job, I supported that program for about 5 years, driving all over the place, meeting interesting people and solving their problems.

ddek 5y ago
I hate to say it, but that sounds a lot like agile! I had a very similar experience building a scheduling app for a UK freight company. They wanted a domain-heavy platform where they could manage their fleet of locomotives and wagons, with a lot of computer assistance. The product owner was a gem. Once he warmed up to the process, we'd get him in a room and he'd talk and talk and talk about everything he found difficult. I mainly worked on the project alone, and bit by bit we addressed his issues. The issues grew more and more specific, until about 3 months post-release, where he came in and had nothing left to add. There wasn't even a wish list left. It was done. This was where I came to agree with the agile 'small batch size' approach. Mistakes come cheap and fast. Most mistakes are usually communication issues, rather than technical. That's not to say that requirements were changing while writing code - it's just that we had good feedback loops, and a short phase had us fixing the real problems faster.