6 ms·

This guy speaks to my soul. A couple years ago I worked on a project that tried to put a 40+ page printed form online. The form is complex. The form has a lot

This guy speaks to my soul. A couple years ago I worked on a project that tried to put a 40+ page printed form online. The form is complex. The form has a lot of intricate guidance and notes, and sections that must or must not be completed based on previous sections or fields. I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate). My proof of concept took 4 weeks, and on the basis of that I estimated a 6 month project. When I presented the idea it was viewed as being too complex, and therefore too risky. So the dev team just started hacking it out, field by field, and saving the whole form into Mongo as a single, nested document. Guidance was hard-coded into the HTML. It was fast, and at the start everyone was awed. Of course soon after the customer decided that the guidance for the printed form wasn't appropriate for the online version. And of course the customer wanted to analyse data across all forms. What was a 6 month piece of work took 3 years. And still no ability to analyse data nested in Mongo documents. Any change requires hours of re-work, regression tests and sign-off. All because agile. In my 20's I'd have been emotionally destroyed. Ego like an aeroplane into the side of a mountain. No survivors, call of the search. Happily I'm in my mid-40's. I know better, and I know better than challenging an inexperienced project lead that has too much authority. So I move on. There's always a project that's more suited to my style of work (slow).

michaelochurch 12y ago
The term "agile" deserves a preceding apostrophe, as in 'agile, because there are two letters (the 'f' and the 'r') being trimmed. I fucking hate that nonsense. It's a total scam.
- einhverfr 12y ago
  Obligatory cite to SQL On Rails http://sqlonrails.org/ http://sqlonrails.org/
- spacemanmatt 12y ago
  I hate that the term has seen total dilution. I have been on outstanding teams that called their methodology agile, but it was an adjective at the time. In that era. Not the fault of the word, though. I'll keep using it.
sweetlandj 12y ago
This post resonated with me as well, but I think for different reasons. At the beginning a team doesn't really know exactly what kind of flexibility and functionality will be required as they iterate. Teams can of course leverage experience with similar projects to come up with possible future requirements, but these are just educated guesses at best, and self-inflicted scope creep at worst. Because very little is known about the stakeholder's needs a team needs to iterate to become more familiar with the domain and the problem space so they can make informed decisions on how to proceed. And in my experience it's easier and less costly to evolve (or replace) something that's dead simple and wrong than to iterate on something very complex and sort-of right. Attempting to anticipate requirements at the outset is always a gamble. If you get it exactly right then you can save months of development time. However, if you get it wrong, even a little bit, then you may find yourself saddled with a not-quite-right solution requiring compromises with every enhancement request. I think part of "slow" (let's say "deliberate") software development is the willingness to put up a straw man for the purposes of getting feedback from the stakeholder and then going back to the drawing board with information gained to build a more appropriate solution. And that's what agile is about--timely feedback and course correction. If in the span of a sprint a team can get a hard-coded form out and learn all of the reasons it isn't a viable solution, then that's valuable information gained at relatively low cost. The alternative, investing many sprints in a more complex solution, may (and often will) yield more technical debt and cost, especially in the long term. That being said, once the project takes form and everyone has a good handle on what the needs are, there is definitely value in shifting priorities from features to design. At that point the insights gained from stakeholder feedback will ensure that the system can be as simple as possible, but no simpler, i.e. easy to understand and test while being abstract and extensible (only) where needed.
lmm 12y ago
> I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate). My proof of concept took 4 weeks, and on the basis of that I estimated a 6 month project. When I presented the idea it was viewed as being too complex, and therefore too risky. Was your flexibility in the right direction? I could tell you exactly the opposite horror story, where an enterprise architect built in a bunch of flexibility that we never used, but we still spent a load of time changing everything as the customer requirements changed. Only we had to spend twice as long because we had to change everything in three places because the "flexible design" required that. > Of course soon after the customer decided that the guidance for the printed form wasn't appropriate for the online version. And of course the customer wanted to analyse data across all forms. What was a 6 month piece of work took 3 years. And still no ability to analyse data nested in Mongo documents. Any change requires hours of re-work, regression tests and sign-off. Why would your way have been different? If you are using the database to store logic in, it's still logic and still needs the same level of testing as it does in code. And you don't get existing tools like VCS, release systems, staging environments to help you with that. I know we're just comparing anecdotes, but everywhere I've worked the business effectiveness has been directly proportional to the extent to which they actually followed the agile principles.
- Spearchucker 12y ago
  "Was your flexibility in the right direction?" Yes. "Why would your way have been different?" Because I had a form that created a form. You know, a lot of failed projects that I've worked on were my fault, because I was that guy. The guy who questioned the seasoned greybeard. The guy that knew JavaScript is the only answer. That agile is the only way to manage development. And if agile didn't work, it wasn't because agile was a bad choice, but because you were doing it wrong. That document databases can replace relational databases. That dependency injection is good. You get the idea. What sounds good, looks good and feels good is sometimes, and sometimes very often, very bad. The thing someone in their 20's doesn't know is that people in their 20's don't know. People in their 30's that are even vaguely in touch with themselves start realising they don't know. In my late 30's I questioned whether I'd wasted my entire career by not learning anything. Today I just know. I know an idiot before he opens his mouth. And I see a bad design decision happening when the team is assembled, before anyone has even started to design anything. That the 5th sentence in the 5th paragraph of this post is badly structured. Most importantly, today I know when I don't know. I still fuck up. Spectacularly so, sometimes. But not as often as 30 years ago. And not as often as last year. Or last month. I happen to have been right in my post above. Hindsight proved that.
maigret 12y ago
> "All because agile." Let me disagree with that one sentence. Martin Fowler has described how design and agile can work together well [1]. What many people describe as "agile" is actually what the agile community names "cowboy development". [1] http://martinfowler.com/articles/designDead.html http://martinfowler.com/articles/designDead.html
err4nt 12y ago
I come to coding from a Graphic Design background and I wish I had computer science under my belt as I test the waters of programming, but what I'm learning reading HN is that many programmers could benefit from the thinking they taught us in design school. What's the difference between an 'artist' and a 'designer'? One is employed! When you are designing something (even with code) your measure of success is how well you deliver what needs to be built. With 'art' there is no such requirement—art can become whatever your whims desire. One thing they warned us very strongly about in Design school was never to become 'married' to our designs. If a client pays you to make something and doesn't like it it's NOT good design because it didn't meet their needs. Don't be personally offended, it's not art, it's design. You can do art when you're paying yourself for your time. I write code and add things like subtle text-shadows and gradients to enhance legibility (scientific reason) to make my designs more accessible, but if I look at the commit logs I often find that my supervisor goes back and removes all text-shadows, box-shadows, and gradients just because he believes gradients and drop shadows are a passé design trend from Web 2.0 that he probably read in an article. I could get offended that he's essentially neutering the accessibility of the designs I'm making and nobody will ever see the full design as I intended it - but I got paid for writing it just the same so what do I care?! He has the website he wants and I have employment. Bottom line is I'll keep delivering value whether he wants it or not and once that handoff is made it's his to do with as he pleases.
- _dps 12y ago
  > subtle text-shadows and gradients to enhance legibility (scientific reason) Honest question: can you provide citations for this claim? I have been trying to produce a compendium of all the empirically-supported claims about visual design affecting usability. I have yet to find citable claims for these cases, and would greatly appreciate a leg up in the effort :)

michaelochurch 12y ago

The term "agile" deserves a preceding apostrophe, as in 'agile, because there are two letters (the 'f' and the 'r') being trimmed. I fucking hate that nonsense. It's a total scam.

einhverfr 12y ago
Obligatory cite to SQL On Rails http://sqlonrails.org/ http://sqlonrails.org/
spacemanmatt 12y ago
I hate that the term has seen total dilution. I have been on outstanding teams that called their methodology agile, but it was an adjective at the time. In that era. Not the fault of the word, though. I'll keep using it.

sweetlandj 12y ago

This post resonated with me as well, but I think for different reasons. At the beginning a team doesn't really know exactly what kind of flexibility and functionality will be required as they iterate. Teams can of course leverage experience with similar projects to come up with possible future requirements, but these are just educated guesses at best, and self-inflicted scope creep at worst. Because very little is known about the stakeholder's needs a team needs to iterate to become more familiar with the domain and the problem space so they can make informed decisions on how to proceed. And in my experience it's easier and less costly to evolve (or replace) something that's dead simple and wrong than to iterate on something very complex and sort-of right. Attempting to anticipate requirements at the outset is always a gamble. If you get it exactly right then you can save months of development time. However, if you get it wrong, even a little bit, then you may find yourself saddled with a not-quite-right solution requiring compromises with every enhancement request. I think part of "slow" (let's say "deliberate") software development is the willingness to put up a straw man for the purposes of getting feedback from the stakeholder and then going back to the drawing board with information gained to build a more appropriate solution. And that's what agile is about--timely feedback and course correction. If in the span of a sprint a team can get a hard-coded form out and learn all of the reasons it isn't a viable solution, then that's valuable information gained at relatively low cost. The alternative, investing many sprints in a more complex solution, may (and often will) yield more technical debt and cost, especially in the long term. That being said, once the project takes form and everyone has a good handle on what the needs are, there is definitely value in shifting priorities from features to design. At that point the insights gained from stakeholder feedback will ensure that the system can be as simple as possible, but no simpler, i.e. easy to understand and test while being abstract and extensible (only) where needed.

lmm 12y ago

> I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate). My proof of concept took 4 weeks, and on the basis of that I estimated a 6 month project. When I presented the idea it was viewed as being too complex, and therefore too risky. Was your flexibility in the right direction? I could tell you exactly the opposite horror story, where an enterprise architect built in a bunch of flexibility that we never used, but we still spent a load of time changing everything as the customer requirements changed. Only we had to spend twice as long because we had to change everything in three places because the "flexible design" required that. > Of course soon after the customer decided that the guidance for the printed form wasn't appropriate for the online version. And of course the customer wanted to analyse data across all forms. What was a 6 month piece of work took 3 years. And still no ability to analyse data nested in Mongo documents. Any change requires hours of re-work, regression tests and sign-off. Why would your way have been different? If you are using the database to store logic in, it's still logic and still needs the same level of testing as it does in code. And you don't get existing tools like VCS, release systems, staging environments to help you with that. I know we're just comparing anecdotes, but everywhere I've worked the business effectiveness has been directly proportional to the extent to which they actually followed the agile principles.

Spearchucker 12y ago
"Was your flexibility in the right direction?" Yes. "Why would your way have been different?" Because I had a form that created a form. You know, a lot of failed projects that I've worked on were my fault, because I was that guy. The guy who questioned the seasoned greybeard. The guy that knew JavaScript is the only answer. That agile is the only way to manage development. And if agile didn't work, it wasn't because agile was a bad choice, but because you were doing it wrong. That document databases can replace relational databases. That dependency injection is good. You get the idea. What sounds good, looks good and feels good is sometimes, and sometimes very often, very bad. The thing someone in their 20's doesn't know is that people in their 20's don't know. People in their 30's that are even vaguely in touch with themselves start realising they don't know. In my late 30's I questioned whether I'd wasted my entire career by not learning anything. Today I just know. I know an idiot before he opens his mouth. And I see a bad design decision happening when the team is assembled, before anyone has even started to design anything. That the 5th sentence in the 5th paragraph of this post is badly structured. Most importantly, today I know when I don't know. I still fuck up. Spectacularly so, sometimes. But not as often as 30 years ago. And not as often as last year. Or last month. I happen to have been right in my post above. Hindsight proved that.

maigret 12y ago

> "All because agile." Let me disagree with that one sentence. Martin Fowler has described how design and agile can work together well [1]. What many people describe as "agile" is actually what the agile community names "cowboy development". [1] http://martinfowler.com/articles/designDead.html http://martinfowler.com/articles/designDead.html

err4nt 12y ago

I come to coding from a Graphic Design background and I wish I had computer science under my belt as I test the waters of programming, but what I'm learning reading HN is that many programmers could benefit from the thinking they taught us in design school. What's the difference between an 'artist' and a 'designer'? One is employed! When you are designing something (even with code) your measure of success is how well you deliver what needs to be built. With 'art' there is no such requirement—art can become whatever your whims desire. One thing they warned us very strongly about in Design school was never to become 'married' to our designs. If a client pays you to make something and doesn't like it it's NOT good design because it didn't meet their needs. Don't be personally offended, it's not art, it's design. You can do art when you're paying yourself for your time. I write code and add things like subtle text-shadows and gradients to enhance legibility (scientific reason) to make my designs more accessible, but if I look at the commit logs I often find that my supervisor goes back and removes all text-shadows, box-shadows, and gradients just because he believes gradients and drop shadows are a passé design trend from Web 2.0 that he probably read in an article. I could get offended that he's essentially neutering the accessibility of the designs I'm making and nobody will ever see the full design as I intended it - but I got paid for writing it just the same so what do I care?! He has the website he wants and I have employment. Bottom line is I'll keep delivering value whether he wants it or not and once that handoff is made it's his to do with as he pleases.

_dps 12y ago
> subtle text-shadows and gradients to enhance legibility (scientific reason) Honest question: can you provide citations for this claim? I have been trying to produce a compendium of all the empirically-supported claims about visual design affecting usability. I have yet to find citable claims for these cases, and would greatly appreciate a leg up in the effort :)