Saturday, June 21, 2014

jQuery - .load() vs .html() - w.r.t javascript

.html() - will strip out any javascript if present
.load() - will not
http://stackoverflow.com/questions/19614511/javascript-not-executing-after-ajax-partial-rendering-in-rails

Brevity vs Flexibility vs .....

Pimp My Code, Part 14: Be Inflexible! - http://blog.wilshipley.com/2007/05/pimp-my-code-part-14-be-inflexible.html

Excerpt:
 In coding, you have many dimensions in which you can rate code:

- Brevity of code
- Featurefulness
- Speed of execution
- Time spent coding
- Robustness
- Flexibility

Now, remember, these dimensions are all in opposition to one another. You can spend a three days writing a routine which is really beautiful AND fast, so you've gotten two of your dimensions up, but you've spent THREE DAYS, so the "time spent coding" dimension is WAY down.

So, when is this worth it? How do we make these decisions?

The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to:

"START WITH BREVITY. Increase the other dimensions AS REQUIRED BY TESTING."
  
 

Friday, June 6, 2014

Against finely grained management

Below blogpost talks about the negatives of finely-grained project-management (that tools like Jira bring).


Excerpt:
.....
..... 
Why did it all go so wrong? 
Finely grained management of software developers is compelling to a business. Any organization craves control. We want to know what we are getting in return for those expensive developer salaries. We want to be able to accurately estimate the time taken to deliver a system in order to do an effective cost-benefit analysis and to give the business an accurate forecast of delivery. There’s also the hope that by building an accurate database of estimates verses actual effort, we can fine tune our estimation, and by analysis find efficiencies in the software development process. 
The problem with this approach is that it fundamentally misunderstands the nature of software development. That it is a creative and experimental process. Software development is a complex system of multiple poorly understood feedback loops and interactions. It is an organic process of trial and error, false starts, experiments and monumental cock-ups. Numerous studies have shown that effective creative work is best done by motivated autonomous experts. As developers we need to be free to try things out, see how they evolve, back away from bad decisions, maybe try several different things before we find one that works. We don’t have hard numbers for why we want to try this or that, or why we want to stop in the middle of this task and throw away everything we’ve done. We can’t really justify all our decisions, many them are hunches, many of them are wrong. 
If you ask me how long a feature is going to take, my honest answer is that I really have no idea. I may have a ball-park idea, but there’s a long-tail of lower-probability possibilities, that mean that I could easily be out by a factor of 10.
What about the feature itself? Is it really such a good idea? I’m not just the implementer of this software, I’m a stake holder too. 
What if there’s a better way to address this business requirement? What if we discover a better way half way through the estimated time? What if I suddenly stumble on a technology or a technique that could make a big difference to the business? What if it’s not on the road map?
.....
..... 
However, my opinion is that -  Jira or any tool for project management, serves to get at least the 'minimum' work output. And that is valuable, very valuable I think. 

However, if we want to target the 'maximum'  work ouput (including quality of solutions, code-quality, amount of code written),  too much dependence on Jira (or tools that do finely grained management) can become a hindrance as described in the above blogpost.

Followers

Blog Archive