while (true) {

[sinious]

Perpetual thread on what you either learned today, is haunting you or just what you need to get off your chest.

Just let it fly..

So today our client, mid HTML5 project, handed us a random PDF to assure our single page application conforms to for their CMS. It is a simple project that is replacing a simple Flash animated page, designed responsive.

We gave a nice pencil sharpened estimate for the project to hit it head on the nail. We sharpened so much because they had us remove all SEO costs like direct URLs, etc. Got approved and moved forward. Too good to be true, just replicate their supplied design exactly, mostly solid colors. Woohoo!

A month later (it's a 40 page app) we showed results and then received this strange requirements PDF. Our SPA done with AngularJS and jQuery, now had requirements like:

- Direct URL for each of the 40 pages (this was formerly removed as a requirement as mentioned)

- Must run within a layer over the original site, over a shaded layer to modally pop it forward

- Must conform to a specific file structure

- All files must conform to only using lowercase a-z and 0-9, not including the dash.

- Must have a fluid design to fill any screen

- On and on, you get the idea....

Over half way through development! Are you serious? Restructure and rename everything, change all layout from responsive to fluid, work with full animation performance in a LAYER over a whole website shaded out?!

Of course, for the same price...

I can live with scope creep, but things like an entire file name and structure requirement along with responsive to full fluid design swap?

Am I crazy to think they should understand what (our estimate explained) a responsive design is versus fluid? This is full, phone to desktop.

Do you get these crazy project scope changes last second? How do you handle it?

[Nancy OShea]

<Of course, for the same price...>

Uh, oh.  All this should have been laid out in the planning phase, not midway when most things are already completed. I would politely explain they will have to pay extra for widespread changes.  When they ask how much more, quote something close to double the original price.  Then negotiate to bring the changes down to an acceptable level that you can both live with.   You've got to stop scope creep in it's tracks.  Otherwise they will own you & you'll resent them forever.

Good luck!

Nancy O.

[sinious]

Thanks Nancy,

I wish it was that simple, but to your point, they do understand it will add to the estimate. They just HATE to hear that because they need to tell someone above them that their vendor project costs more. You know that blame comes right back to the vendor. And you also know the vendor is not at fault.

I wish the agile process was far more popular with our clients. I want them to see faster updates to correct and adjust time more appropriately. Unfortunately my clients all have no idea what they want in the end, for a fixed budget price.

*facepalm*

Luckily my company is considerate and had always dealt with this. Our job, #1, is to make the client a rockstar.

Tough to do free work.

[Nancy OShea]

I hear ya!  Is this a repeat client?

If yes, you might be able to recoup some of this loss on a future project for them.  Client saves face this time around understanding they will need to pony up more next time.

Nancy O.

[sinious]

12 year client that actually knows to spread the cost to localizations.

We make it up but the best move is just to know what they're asking ahead of time.

[Nancy OShea]

<12 year client that actually knows to spread the cost to localizations.>

Great!

<...the best move is just to know what they're asking ahead of time.>

Web developer:

     70% tech/design/business acumen,

     30% psychic  

[Rob Hecker2]

  Is this a repeat client? If yes, you might be able to recoup some of this loss on a future project for them.

Right thinking. I once let a client really screw me out of $500 and took it on the chin with a smile because I foresaw a lot more business was ahead. But if I had quibbled over the $500 I would probably have lost that future business.

[sinious]

That's always my gotcha. If I mention it and my client needs to get more budget, their boss will see it's their fault for failing to give a stack of requirements. Now they're not in a good place, thus neither am I with my client. That can cost us the next job just out of spite.

For our size clients we're just a tiny vendor and only as good as the last job (mostly).

My end of last week peeve was different though. Two things I really wish more coders took a brief second to do is:

1) Please put a comment at the end of any fairly large block of code (more than halfish or more acreen) indicating what it is closing. HTML or code, it really helps, especially when loops start nesting.

Just this easy:

function Foo() {

   //.... Lots of foo

}// func Foo

2) In consideration to #1, in those nests and nests of loops, can we strive for a variable other than 'i' to iterate on? And longer, descriptive references as well? It becomes pretty hectic when you're inside a triple nested loop looking at r.cb(m(r.id),r.data);.. Yes that's nonsensical seeming, but mid dev, I've seen strugglers start cutting down on sane things.

If my IDE didn't support scoped refactoring or begin/end brace highlighting, I'd be nuts.

[Rob Hecker2]

Of course using PHP classes makes it easier to keep track of what's what, but I don't always do that.

No one else ever sees my code, but my single project is hundreds of thousands of lines of code and the database has 114 tables, so I try to be strict about commenting, naming conventions, and structure, for the sake of my own sanity. I use long descriptive variable and file names. The extra typing pays off in the end.

An example of failed consistency on my part is naming tables. My invoice table is "invoice," singular, but my customer table is "customers," plural. This small lack of consistency has led to a thousand times a query I wrote didn't render the first time because I got singular/plural wrong.

I frequently see beginners who post code in the forums using case inconsistently, which quickly leads to head scratching over why the variable doesn't hold the value they set when the variable they call is $price but the one they set was $Price.

If my IDE didn't support scoped refactoring or begin/end brace highlighting, I'd be nuts

Absolutely. Of course DW matches braces. I use ZEND Studio for PHP IDE, although I actually do a lot of PHP work in DW as well. I highly recommend ZEND server as a development web server because of the built-in debugging tools.

[sinious]

Today I learned... nothing... (at work). Happy Labor Day!

[sinious]

Alright just for JavaScript, where does everyone lie on these four common areas. Regardless if your convention is personal preference or environmentally regulated..

1) Tabs or spaces for indenting?

Tabs for me, almost always set at 4-ish spaces (depends on the font/screen size). Drives me nuts when IDEs actually ask you in preferences if you prefer to indent with tabs or spaces and then you turn on invisible characters (spaces show as dots) and the entire document is littered with dots, but ACTS like they're tabs..!!

2) Brace on the same line or next line?

For quite a long time I was same-line to save one extra line of code. On some classes we're talking hundreds of lines. However I always found matching braces so much easier to find by simply following the indent level. Lately I'm hybrid. In back-end languages or applications I still do it. In languages like ActionScript, JavaScript, etc, I end up saving those lines of code and starting the brace on the same line. Perhaps it's just because looking at the way the sheer volume of library writers seem to prefer it, it's just peer pressure for me.

3) Code comment placement and frequency?

How often do you find yourself commenting? One simple thing I always do now is at any closing tag or brace I always add a comment to indicate what it's closing if the brace is 3+ lines above the brace, or sometimes things grow so I just do it every time. So it'll be <div class="calendar"></div><!-- /.calendar --> or in code, function Foo() { } //func Foo.

As for any other commenting, that'll lead to question #4.

4) How often do you follow a strict auto-documentation building commenting routine and which do you prefer?

Since I write amazing ActionScript and PHP while only using the best practices you can read the code like a poem.

Ok back to reality, as I take on more and more JavaScript work I'm finding my files are growing to some crazy levels. That and I work with a variety of people. In this situation I'm preferring to use JSDoc3 to (somewhat) auto-document, which is a pretty well known solution. Robust enough IMHO to do what I find none of the other contractors care to do, build documentation. I almost use it as a validator for myself. If the documentation generated is wacky looking then I need to rethink my code approach.

What do you use and any special reason why you use it?

[Jon Fritz]

Usually use whatever automatic indenting DW uses when apply source formatting is hit, I think it's 4 spaces right now, otherwise I don't indent.
Usually same line for braces unless I'm trying to make the script more "obvious" for others to use (like in the forums)

Commenting, if necessary, where necessary, otherwise none. (this bites me every now and again when I make something and forget what the heck is going on a few months later)

No auto documentation

[sinious]

I'm entirely on board with the no documentation but no comments either? Remember I'm talking HTML here too, or all languages for that matter. When I'm in the middle of someone's <div> soup in our highly injected and dynamically generated generation so when I'm in the developer tools and I see this is drives me nuts:

                    </div>

               </div>

          </div>

     </div>

</div>

[osgood_]

sinious wrote:

I'm entirely on board with the no documentation but no comments either? Remember I'm talking HTML here too, or all languages for that matter. When I'm in the middle of someone's <div> soup in our highly injected and dynamically generated generation so when I'm in the developer tools and I see this is drives me nuts:

                    </div>

               </div>

          </div>

     </div>

</div>

You're obviously looking at Bootstrap or Wordpress (a framework at least) - drives me nuts as well - simply awful coding to have to work with.

[sinious]

Mostly SPA via AngularJS with directives and included partials generating a ton of content. Only takes a few simple loops to generate a crazy amount of content. But yes, I do use my share of WordPress templates (*shudder*) and also Bootstrap. WordPress is just crazy amounts of includes and Angular, as you grow, ends up being a crazy amount of injection. Don't take me too literally though, it's not all div tags.. Even a good stream of ending tags of any kind which can be of any type ends up being a giant mess when the injection/include indentation is lost. The example above would be best cast to me, but we all know it ends up like:

</div></div>

               </div>                         </div>

</div>

That said the commenting was the point there and even if it is the above, I can deal with it like this:

</div><!-- /.box-comment --></div><!-- /.carousel -->

          </div><!-- /.highlight-list -->                    </div><!-- /.highlight container -->

</div><!-- /.you-get-the-idea -->

[Rob Hecker2]

In my own code I use symantic tags in place of divs as much as possible, as I imagine everyone else does too. Really helps avoid confusion.

[osgood_]

Rob Hecker2 wrote:

In my own code I use symantic tags in place of divs as much as possible, as I imagine everyone else does too. Really helps avoid confusion.

That's a useful approach now!

[sinious]

I agree, but in highly atomic environment where you're building just one widget such as I was trying to illustrate above rather than the fundamental building blocks of an outer layout, there are no tags that really cover these complex DOM structures. They are the tagless masses, which is why I rather enjoy AngularJS's directives, so all of the above looks like </highlights> in the source but a </div> storm in the developer tools..

[Rob Hecker2]

Yes, of course in the environment you describe, you would not want creators of plug-ins, classes, or modules to use semantic tags. That prerogative belongs to the fundamental site layout development.

[Nancy OShea]

I am not strict about indenting. Personally, I don't like looking at indented HTML code. It doesn't really help me much.  I comment quite a bit.   Most of it gets stripped out when I minify my code though. So I maintain my non-minified work files for future reference.

Nancy O.