Warning Signs that Agile Is Declining - <AUTHOR> http://www.javacodegeeks.com/2012/01/4-warning-signs-that-agile-is-declining.html <comment><USER3> Agile is just another in a long line of fads that try to use management "methodologies" to make programming a commodity that can be done by line- workers. It's not, and it can't be made so. Programming is a highly skilled craft.

Good code is written by good programmers. Bad code is written by bad programmers. Bad management can hobble good programmers, but no form of management can make bad programmers write good code.

(I'm not saying agile is bad, necessarily, just that it does not live up to its hype.)

<comment><USER4> I feel you got it backwards. The whole idea behind agile is to treat programming as a craft and to focus on the people, as opposed to treating development as a production line.

Some good readings on the subject: Extreme Programming Explained, Agile Software Development Ecosystems, Balancing Agility and Discipline.

<comment><USER5> My problem with this is the 4th tenet: "Responding to change over following a plan".

Some tasks require lots of planning. When you are building a complex system, you cannot plan as you go, and in some cases your first usable release cannot happen after the first 'sprint'. In this way, agile programming assumes that the programmer cannot make long term development plans, and in fact prevents him from doing so. While this eliminates some of the risk, it also prevents programmers from reasoning about their problem holistically, and can deliver inferior or non functioning solutions for projects that do not happen to fit the model well.

This refusal to allow programmers to reason holistically is part of what us critics mean when we say that agile attempts to turn programmers into line workers.

Complex projects, like building a jetliner (or the programming equivalent), cannot be "continuously integrated" with no up front planning. For projects like this, you need to decide the thrust of your engines before you start to design the airframe, or your entire project may fall apart, literally.

<comment><USER4> It really depends on the kind of project you're working on. Some modern Agile authorities (see Balancing Agility and Discipline: A Guide for the Perplexed) will tell you that you should tailor the process to your specific requirements. They would never recommend that you use XP for the development of life-critical software that has hundreds of engineers working on it.

Agile is born from rapid prototyping and makes a lot of sense for that environment. If you're doing work where one day you might be developing one thing, and the next day you might be working on a completely different product altogether, then reducing the cost of change is the only thing that makes sense. If you're not, then don't use pure agile, it doesn't make that much sense.

There's obviously an issue with one size fits all approaches to agile, and as agile matures people realize that more and more, instead of forcing you to do everything by the book. The point is, as you get more and more experience with driving software projects, you need to be smart enough to understand what will make sense and what won't.

<comment><USER6> I agree with your general direction, but I have a quibble.

Agile methods were born from in-house enterprise software projects. The ur- project for Extreme Programming was a payroll system, and SCRUM's was something similarly dull. The original SCRUM paper says, "Scrum is concerned with the management, enhancement and maintenance of an existing product[...]. Scrum is not concerned with new or re-engineered systems development efforts."

If I'm doing rapid prototyping, that's when I'm least interested in Agile techniques like pair programming, test-driven development, and refactoring. Those only really pay off in the long haul.

</comment></comment></comment></comment></comment><comment><USER7> Assuming facts not in evidence error at line 1: Presumption that Agile ever ascended.

The basic problem with the Agile movement is that it took a few proven helpful practices -- almost all of which were well known and often used by experienced software developers before the buzzwords were attached, even if managers didn't realise -- and instead of promoting those, it wrote a "manifesto" so vague that it would make a political speechwriter proud, which didn't actually say anything at all about the _practical_ steps that were useful.

Then concrete examples of "Agile" processes started to appear, and a few less proven or even discredited practices were added to the basically good ideas. Suddenly, despite valuing people over processes or some such vacuous claim, it's all about The Process again.

The predictable result was something non-technical managers thought sounded good but didn't really understand, and technical people who didn't drink the Kool-Aid looked at sceptically while asking where the evidence was that it was better than what they had been doing already.

And the only answer the Agile community has collectively agreed on in the ten years since then seems to be that people aren't doing Agile properly in most cases, but look at the successes where smart people have made it work! Of course, those smart people probably could have run a successful project starting from any other process, too, because if it didn't help they would have thrown it out in favour of things that did, just as they always had. And if most of the case studies of your supposedly superior process don't show significant benefits, you start to lose credibility after a while by claiming that they're all doing it wrong.

And now, we're doing the same thing all over again with the not-at-all- pretentiously-titled Software Craftsmanship movement, and the result will be the same: lots of people selling books and charging consultancy fees to peddle snake oil mixed with just enough actually proven ideas to be credible for a while until the results come in, by which time they will have moved on to the new hotness.

I am not normally a fan of Zed Shaw's style, but in this case, I sympathise with his point of view:

<http://programming-motherfucker.com/>

<comment><USER6> That is approximately the opposite of how it happened.

Several different groups of people invented processes that worked for them (e.g., Scrum (1995), XP (1996), FDD (1997), DSDM (1994)). They all liked what they had done, but discovered they had commonalities that were worth talking about. They got together for a long weekend and came up with the Agile Manifesto (2001).

Having lived through the transition, I promise not all the good practices were "well known and often used". Frequent releases were generally considered dangerous, and weekly iterations were seen as heretical. Unit testing was done by a small number of projects, but mainly in safety-critical areas. Test- driven development was unheard of. Continuous integration was certainly rare, as was using refactoring (supported by high test coverage) as a way to manage change.

Personally, I think the Agile movement is irredeemably doomed at this point. It's basically a question of incentives:

[http://agilefocus.com/2011/02/21/agiles-second-chasm-and- how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell- in/)

However, the current sad mess happened in spite of the good intentions and major discoveries of the people behind the methods that got rolled up into Agile(TM).

<comment><USER7> You're not the only one who lived through the transition. And IME the _good_ practices that are used in Agile processes mostly are the ones that were well- known and widely-used.

People have written automated tests for decades. People have been testing at the interface level since the dawn of OO and before. Put those together and you've got what is now called unit tests.

People have been making small changes to improve the design of code without changing its behaviour forever, too. Fowler published _Refactoring_ in 1999, but even then it was common practice among experienced programmers to work that way. I assume you're not seriously going to suggest that no-one thought of doing things like moving a method up and down a class hierarchy or splitting a long function into a higher level control function using lower level functions for the details before the book was out. (I'm not disputing that Fowler did a good job of pulling a lot of common knowledge together in a way that is helpful to those just starting out.)

I also assume you're not seriously going to dispute that long-term projects have been managed using shorter-term milestones for a very long time. That's hardly unique to software development, never mind to Agile processes.

Every project I've ever worked on professionally has seen developers naturally pair up or form small teams around the same computer or whiteboard to work through difficult problems or review each other's solutions.

People have been doing what is called continuous integration today for as long as there have been source control systems with check-in hooks.

I first had the idea of organising a big project by keeping a pool of little projects and picking out the most important one to do next when I was about 13 or 14, so I rather suspect that plenty of managers were using the same idea to prioritise long before anyone called it a backlog and worked through it in sprints.

I could go on, but I think you get my point.

Now, there are plenty of other practices required by various Agile processes that weren't (in my experience) almost universal among good programmers before Agile came along. They include:

\- TDD

\- Full-time pair programming (same computer, two keyboards)

\- Collective code ownership (everyone owns everything)

\- Forcing short-term milestones into periods of exactly the same length

\- Frequent meetings (daily in some processes)

\- Relying on organic designs that evolve through arbitrary refactoring by individual developers rather than a carefully planned architecture and smaller-scale designs that are peer reviewed by multiple people

If you want to claim those as the gifts Agile has given us, you're welcome to them. As I said before, most of the _good_ practices were already in use, and the consultants mixed in a bunch of unproven ones later.

<comment><USER6> You're again wrong on the history of the Agile movement, and I'm disappointed that you entirely ignore the meat of the point that you're replying to.

As to your assertion that everything good was in wide use before: that's not how I recall it. For example, CI: the Joel Test, written in 2000, suggests that the vast bulk of shops couldn't even manage to do a daily build, and he didn't even mention CI as an option. Also, it's not clear to me what a 13-year-old's imaginings proves about what a majority of development shops were doing in the mid 90s. My recollection is that waterfall was the majority, with most of the rest of the shops doing code-n-fix. And the first edition of McConnell's Rapid Development, which was a mid-90s book, either doesn't cover or treats as exotic most of the Agile notions.

But honestly, I don't know that it matters. I'm not sure why, but you seem eager to prove that there was nothing good about it based on your incorrect version of the history. The good news from your perspective is that what's sold as Agile has turned almost entirely into dismissable buzzwords, and as a fad I expect it will be extinct soon. There's nothing left to fight off.

But personally, I plan to keep using and evolving what I learned from it. If you want to see what a shop like that looks like (including all those practices you mention above), feel free to drop by in SF sometime. We like visitors.

<comment><USER7> There are millions of programmers in the world, and plenty of us have been doing it professionally since before Agile was all the rage. It sounds like you have too, but are you really arguing that just because you personally didn't encounter these ideas before Agile advocacy came along, no-one else did either? Or perpetuating the false dichotomy between Agile and Waterfall? I have never worked on a project that followed a strict Waterfall model without any kind of cycle or iteration in the process, not once in my whole career. Now get off my lawn!

Seriously, though, you've cited Spolsky and McConnell, but you seem to be appealing to their authority on the basis that if the techniques we're discussing had been in common usage, they would surely have been mentioned in those authors' writing in the late '90s. I would point out that the first edition of McConnell's _Code Complete_ was published in 1993 and didn't say much about OOP, yet OOP was already in use by many professional developers, and books about languages supporting it had been published many years earlier: the first edition of _The C++ Programming Language_ was published in 1985, for example. Similarly, the second edition of _Code Complete_ was published in 2004, yet contains no index entry for the word "concurrent" or "parallel" (though there is a passing reference to multithreading on page 337). So perhaps it is unwise to infer too much from any absence of references in the kinds of source you mentioned.

<comment><USER6> I have never argued that "no-one" encountered those ideas, and your repeated exaggeration of my position is frustrating.

Nobody in the Agile movement claimed novelty for individual pieces. What was different was the way the pieces went together, and the shift in values and cultural norms that they required. That wasn't purely novel either; the fact that several people invented similar processes at the same time suggests that, as with most inventions, change was in the air. But what the Agile people undeniably did was to define and promote that difference in a way that gave people something to rally around. At the time, waterfall and a waterfall-ish RUP were the big processes people were discussing, and the notion that one would focus on people over process, or working code over documentation was heretical.

Also, I'm having a hard time taking your approach to evidence seriously. Rapid Development was a major survey of current software project management and a catalog of best practices put out by a large tech publisher. Splosky was also writing clearly about current practices. Your counter-evidence is the (unnamed) projects you've (anonymously) been on. Plus that one of them wrote a different book that you can pick nits on.

And honestly, I don't get why you're arguing the nits and ignoring my main points. You clearly have some big issue with your version of Agile and it's imagined history. But I honestly don't care what process you follow as long as it doesn't suck for you, so arguing it with me isn't really helping anybody.

<comment><USER7> I'm sorry you're feeling frustrated with this discussion. I'm afraid I just don't understand what your "main points" are supposed to be, if you think I'm only picking nits with the details.

I started this subthread with some fairly black-and-white statements about the relative timing of good practices being adopted, Agile taking off, and less proven practices entering the picture:

<http://news.ycombinator.com/item?id=3476171>

Since then, you have accused me, repeatedly, of being wrong about the history of Agile. Is your objection that early versions of a few Agile processes already existed, albeit in relative obscurity, before the Manifesto was written, but I talked about how 'concrete examples of "Agile" processes started to appear' after the Manifesto was written?

If so, I'll happily concede that point. I don't think it really matters whether you define Agile as starting from the evolution of the general approach/abstract philosophy (which had evidently started by the time of those initial processes) or the writing of the concrete Manifesto and popularisation of the Agile moniker. Nor do I think it really matters whether you define processes like XP and Scrum as appearing as "Agile" processes when they were popularised and given that label (around the time the Manifesto also became widely known) or from when the original processes that became what we now call XP and Scrum were first used anywhere. Any way you cut it, we're talking about the same groups of people, the same general period of time, and the same end results.

 _My_ main point is simply that many of the good practices that were adopted by those early Agile processes and are often considered to fall under the Agile umbrella today did not actually originate during that period of time or with the people who worked on those early processes and the Manifesto. However, many of the Agile practices I consider unproven _did_ originate during that period of time and with those people.

While you may wish that no-one in the Agile community claims otherwise, unfortunately that is not always true. While I was researching my post with sources, I found a comment on Martin Fowler's personal web site claiming that Kent Beck coined the term "refactoring" in the mid-'90s, for example, and numerous comments from various posters on other forums suggesting that Fowler's book was the definitive original reference. I think it is important to debunk such claims and any attempt to paint Agile and Waterfall as some sort of dichotomy. That just isn't how software development works, and being "Not Waterfall" is not an argument for switching to any given Agile process.

<comment><USER7> > I found a comment on Martin Fowler's personal web site claiming that Kent > Beck coined the term "refactoring" in the mid-'90s, for example

No, I didn't. Sorry. I had read something similar in several other places, and when I did a search (since Fowler's site itself was blacked out) the resulting excerpt was truncated in a critical place that made it look like the above was true. Still, there are plenty of people who _have_ claimed that the Agile movement originated ideas like refactoring in on-line forums and the like, so aside from setting the record straight regarding Fowler's site, my original point stands.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Warning sign 0: When it became Agile-with-a-capital-A

Capitalization means it's become a proper noun. A specific Thing. And everything that comes with that: canned methodologies, books on how to implement specific "Agile" processes, management retreats, certifications and all sorts of other senseless bureaucracy.

In other words, processes, tools, documentation, contracts, and plans. Not quite the kind of agility they were talking about in the manifesto. ( <http://agilemanifesto.org/> )

</comment><comment><USER9> I Can't agree more. I successfully applied agile ONCE during my 6 year tenure at a fortune 100.

When approached with the question of what I thought was needed to make agile work, my reply was simple: "start with a good team who can handle it."

That advice was of course tossed aside as corporations (especially middle managers) whose primary concern is the ability to shift resources cannot fathom the notion that agile starts with the individuals who compose the team. The sad truth of it was that there very few individuals who are actually capable of being "agile" after being subject to heavy handed processes for years.

<comment><USER10> From being on a few agile projects at Fortune 100s, I can attest to this. I once worked in parallel with another agile team that was doing a separate but integrated portion of an entire solution (it was a bunch of apps under one umbrella/initiative). At the risk of tooting my own horn, the other team was disbanded after three months without progress.

The inherent problem that I saw was how those companies treat developers. I'm a consultant, so I was able to do the projects and move on, but it's clear that the companies look at developers as commodities and cannot fathom why somebody who says they can write code is not equal to another person who can write code. After all, aren't all accountants the same? (They're really not.)

Regardless of whatever process you throw at these large companies, if you have a mediocre staff, expect mediocre results.

<comment><USER11> _Regardless of whatever process you throw at these large companies, if you have a mediocre staff, expect mediocre results._

I agree about staff, but I also think that mindset is a huge component. There are organizations out there that consider software to be a necessary evil, something that they _have_ to do in order to do the real stuff that needs to get done.

Other organizations consider software development to be a strategic advantage. Something that they can do more quickly or more effectively to make the organization succeed.

If you're at a "necessary evil" organization, neither talent nor methodology will save you.

</comment></comment></comment><comment><USER12> I've worked in a global company pushing agile, as well as currently running my own start-up. My problem with Agile (with a capital A) is that it has become something it didn't set out to be.

 _Individuals and interactions over processes and tools_

Agile has become about processes and tools. Tools for burn rate management, estimation processes, test-driven development is a process.

 _Working software over comprehensive documentation_

Documentation is now done, just in a different place. We seem to document everything but the product. Processes/interactions/estimation accuracy. And then this point is just used to not even produce any helpful/lightweight documentation by the end.

 _Customer collaboration over contract negotiation_

BA's and managers speak to customers. They claim to be collaborating, but in reality, it's just a contract negotiation. You want x, we can deliver y, it will cost z. Even within a corporation, it's just contract negotiation. Devs still aren't pushed to talk to customers, and managers still don't understand estimation. Incentives are poorly aligned.

 _Responding to change over following a plan_

People following Agile still have a plan. It just takes into account burn- rate, and a few other metrics. Changes still hurt, because the deadlines don't change. However, customers are now told it's OK "We can respond to change!".

These days, my aim is to get stuff working and maintain motivation. No more, no less.

</comment><comment><USER13> I worked at a company which tried to push agile process upon us in a 'top- down' fashion. I believe this is a cargo cult behaviour caused by a lack of understanding of underling development issues.

Late-running projects that don't meet requirements are often a result of poor communication and a lack of concrete requirements. This is clear to most business people. What isn't so noticeable to many is that software development looks a lot like an iceberg. The business domain decisions are visible above the water while the architecture and implementation decisions are below the water line. The fundamental point I am asserting is that software projects grow in implementation complexity at a greater rate than the complexity of the business domain does. Software projects run into scalability issues far earlier than non-software projects.

At low-scale, increased centralisation of decision-making and communication increases quality and timeliness. However, at high-scale most companies make the mistake of continuing to increase centralisation on the business-domain and let this centralisation of project decisions be imposed upon the more complex implementation-domain. Doing so can backfire for the following reasons:

(1) There are too many decisions which need to be communicated and specced out by one person.

(2) Increasing the vertical height of an organisation creates 'chinese- whispers' type communication problems.

(3) Business-domain knowledge held by project managers is often not enough to make informed decisions that require specialist technical knowledge.

Now I have to be blunt. If your employees aren't high quality enough to make decisions or communicate on their own then there is very little you can do to improve your process. You can try to create mini-hierarchies of lead developers smart enough to make informed decisions and communicate in between groups of drones but this which will not solve implementation problems and yet again the centralisation will create similar issues as before. However, if you've hired smart employees you will have much better luck since you can: (1) scale decision-making and communication completely horizontally -- be careful to avoid coupling problems, (2) help people to form an iterative process that takes into consideration long-term goals, and (3) implement social interfaces (stand-up meetings being the classic example) to simplify and increase the quality of communication.

The reason this should be done from the 'bottom-up' is that people aren't so much as following a process but instead are iteratively _learning their process_. You need to step away to let this happen.

<comment><USER14> Thanks for this post. I agree wholeheartedly. A lot more effort has to be put into the 'learning your process' part. The problem is that this requires self- reflective and humble individuals who are willing to work on improving their skills. I see far too many who are not willing to improve and learn, and most of these individuals lurk at big companies. Such an individual sees only imposed constraints in the methodology, and no possibilities. Since these passive individuals are easy to control, management has formed as a constraint-imposer and controller above them. Introduce a new methodology, and the workers will only (rightfully) complain while the management translates it into control constraints. So the problem lies not within the process, but the individuals. Start with improving the attitude, then let the team members bring in useful parts from methodologies as tools to reach the goals you have set together.

</comment></comment><comment><USER15> Badly managed businesses that are run the "top down" way the author describes typically have no respect or desire to understand the product development process they depend so heavily on for success and profit. No amount of "Agile" or "Lean", no consultant or trainer, no Kanban or Scrum board can really ever hope to change this for them if these organizations cannot self reflect and see that they are standing in their own way.

The concepts and learning that has come from the agile and lean software movements are still valuable though. Valuable for those who choose learn and are willing apply them, test them, validate them and actually self discover what is and is not effective. But they are absolutely snake oil and worthless for those who are unwilling to put in this basic effort.

<comment><USER16> _No amount of "Agile" or "Lean", no consultant or trainer, no Kanban or Scrum board can really ever hope to change this for them if these organizations cannot self reflect and see that they are standing in their own way._

You neglect the larger scale life cycle of such companies. Over time, in a large and varied environment, some group manages to do the right things. The real value of such group is recognized for a time, but then is lost to time and attrition. The project ages and becomes another outdated and sclerotic barrier to further progress.

 _The concepts and learning that has come from the agile and lean software movements are still valuable...But they are absolutely snake oil and worthless for those who are unwilling to put in this basic effort._

Basically, you want good people and a team culture that actually works.

<comment><USER15> _Basically, you want good people and a team culture that actually works._

Bingo. Which is of course, the hard part to do and maintain. The rest of it is really mostly hand waving. I do believe in a lot of the lean philosophy, and I believe that finding a process that works is crucial to success, but I also believe only a team capable of defining, developing and refining a process will ever have one that "works".

</comment></comment></comment><comment><USER17> The devil is in the details. You still need competent people to determine and estimate tasks, and to implement those tasks. Implementation is the biggie. How do you design the implementation? How complete are your tests? What are the important requirements of the task?

There seems to continue to be this idea in management that process will take the place of skilled programmers. That you can then just plug any programmer in, and the process will produce a usable product.

It's amazing how most other skill based industries require certification exams, to verify that you truly do know how to build a bridge, prepare a legal defense, or perform a hip replacement. Software development is the only place where process is thought to replace skill and knowledge.

<comment><USER6> _There seems to continue to be this idea in management that process will take the place of skilled programmers._

This is true, but it's not what Agile originators meant. The early Agile stuff was exactly the opposite. E.g. the initial SCRUM paper starts out talking about "Small teams of competent individuals, working within a constrained space that they own and control." Extreme Programming specifically removed from management the power to arbitrarily mandate a schedule:

[http://www.techrepublic.com/article/extreme-programming- bill...](http://www.techrepublic.com/article/extreme-programming-bill-of- rights/5121760)

<comment><USER17> But if the programmers are running the show, what is management supposed to do? That's why there's a scrum master. Yes, you need a leader, but often that role gets pushed to a manager, who focuses too much on process. They should rename it the scrum playmaker, with each sprint focusing on a new playmaker, returning control to the team.

Managers also have a much different understanding of the word "competent" than the people on the team.

</comment></comment></comment><comment><USER18> I hate to use the word "Agile" because the very act of naming seems to encourage the nonproductive behaviors the OP is talking about. Calling it a "process" is even worse, because it's a metaprocess, not a process.

Like he says, "it's the doing, the reflecting, and the adapting that count the most." That doesn't really _need_ a name; that's just how you become good at _anything_. Software, jazz piano, raising chickens...anything.

Any productive methodology is a local adaptation to local conditions. Any codified methodology should be treated as a suggestion, not a constraint. If you stop observing and adapting your methods, they rapidly become less relevant and eventually turn into useless dogma. I'm pretty sure that just about anyone who is good at doing anything does this without being told, or giving it a name.

<comment><USER11> I hate to use the word "Agile" because it has lots of baggage at this point. There's the lingering smell of snake-oil salesman, the push-back against hardcore zealots who can't cross the gap between theory and practice, and the overly simplistic "I know what the English word 'agile' means" interpretation.

And while I love what a lot of people are doing around "Lean" software/startups, I'm starting to hate using that word, too.

</comment></comment><comment><USER19> "Those things that looked "shiny" a few years ago, like TDD or continuous integration, have lost their shine, and aren't attractive anymore. Don't believe me? check out the big conferences – seen these topics lately?"

I don't know about TDD, but IMO continuous integration isn't mentioned at conferences anymore because it has won. I haven't seen a software shop not doing continuous integration in years: ranging from huge private companies to government contractors to small fly-by-night shops. Outside companies for which software is part of their product, you still see a lack of it, but in terms of the software industry CI has won.

<comment><USER20> Never in twenty years have I had the opportunity to do CI with a team, mostly because nobody I've ever worked for invested in such comprehensive automated testing that manual regression tests could be abandoned. Where I'm at now, we literally schedule integrations and releases around what QA has had time to test, and they're guided by project priorities rather than whatever got finished earliest.

<comment><USER21> This is extremely common in my experience (and the corrollary effect - <USER2> cannot refactor that code, it will be too expensive to retest. Dont touch that code path, add a new one with cut and paste)

Anyway, it _is_ possible to bring Agile to a large organisation, but it generally needs _first_ to solve tooling and build problems - I would not start a single sprint until there was source control, complete automated build, and enough tests to be reasonable. Amazing how much pain can be endured by teams. That much pain can teach you not to care.

</comment></comment></comment><comment><USER22> Required reading: "We tried Baseball and it didn't work."

<http://xprogramming.com/articles/jatbaseball/>

<comment><USER23> I always have the impression that Agile is sort of like the True Scotsman or the Communist Manifesto

"If it didn't work, it's because it isn't really agile."

<comment><USER22> Absolutely this is the case. But not to single Agile out unfairly: Although people are doing a lot of great work researching processes and so on, Software Development as an industry is like this.

Consider Waterfall. If you try it, and it doesn't work, proponents will tell you that you were doing it wrong with all the changes late in a project. If you try Ruby and your code is a mess, Ruby programmers will say it isn't the language, you failed to write good Ruby code.

And so on, ad infinitum.

So, if I agree with you, why did I post this? Not because I assert that Agile will "work" if you just do it right, but that I think it's wrong to modify it and then blame it for not working.

Come to think of it, if you do it "right" and then succeed, I also think it's wrong to give it the credit. But that's another story.

</comment></comment></comment><comment><USER24> Getting things done is not that hard. I don't need a burn down chart and some dude with a Dilbertesque PHB role to do my job effectively. I view anyone waxing on about so-called agile in the same light as those who speak of synergistic paradigm shifts in innovation etc.

<comment><USER25> Have you read the Agile manifesto? What about the Software Craftsmanship manifesto?

<comment><USER26> Bob Martin couldn't get enough corporate gigs selling his Agile snake-oil so he invested "Craftsmanship".

Just wait, once Craftsmanship runs it's course he will have a new "methodology" hell tell you about, for a fee.

</comment></comment></comment><comment><USER23> Is "Agile" is still the best out there? If I have a team of 4-5 bright people, the best way to get them working as a team to produce software for a limited group of people is agile/scrum, right?

<comment><USER27> As usual it depends. At the risk of spouting a cliche, there are no silver bullets.

The best way to get a team working is to analyze and enumerate the current problems and shortcomings, and find a way to reduce or eliminate them.

Is the problem with your team:

* They don't make deadlines?

* Too many defects?

* Disconnect between software and customer?

* etc.

Armed with that information, you can see if any of the multitude of Agile methodologies addresses the issues you have, and is something that will work with your team. You can see if you can cherry-pick a technique here or there from a given methodology.

Asking other people what methodology is best is like asking if Java/.NET/rails/django/php/lift is the best way to write a website. You'll get a lot of opinions that sound good and point you in the right direction, but ultimately you need to roll up your sleeves, investigate the options, and make decisions based on your current circumstances.

[And ultimately, this is the problem with the current state of agile. A consultant or evangelist will promote their brand of Agile as a silver bullet without taking the time to look at _your_ organization's problems.]

</comment></comment><comment><USER28> This dilbert take on it still makes me smile: <http://dilbert.com/strips/comic/2007-11-26/>

</comment><comment><USER29> Oh boy, could I give a good rant about how we're seriously screwing up Agile. In fact, I did -- [http://www.whattofix.com/blog/archives/2010/09/agile- ruined-...](http://www.whattofix.com/blog/archives/2010/09/agile-ruined- my.php)

But as bad as the average Agile adoption is, I disagree with the author. Let's take each of his points:

 _Companies are "doing agile"_ Yes. As an example, last year I had a huge manufacturing company (which I will not name) ask me to come in to help as an Agile coach. It was a weird gig -- no teams, no traction, just a couple of guys in an office somewhere. It took me a while, but I finally figured out what they wanted. They wanted an "Agile Expert" to help them rewrite all the processes so they could be Agile! To them, it was top-down, create and monitor the process, etc. This was a control game, and they just wanted an imprimatur for the whole thing so they could gain more control.

So you might think that I would agree with this point, but I do not. The reason is the same reason why these guys brought me on: Agile is being implemented from the ground-up whether companies like it or not. The natives are restless, developers are seeing the difference, and change continues to happen. Most of this top-down stuff you see is more a reaction to that than anything else. So yes, the guy in the top office is trying to take a big hammer and "do" Agile like he did everything else, but the guys on the shop floor are doing their best to do it the right way, no matter what.

 _The business and development divide has grown...we now have project managers as ScrumMasters_. Yes we do in many places, but not always. Lots of teams are doing it different ways. I think you could look a this either way, depending on your personal experience. When I wrote a blog article last week about rotating the ScrumMaster role among different folks in the team ([http://tiny- giant-books.com/blog/scrummasters-get-no-respect...](http://tiny-giant- books.com/blog/scrummasters-get-no-respect/)) I had one CST come by and say basically "That's not a good thing. I've never seen it done like that!" But I also had a few people email me and thank me for bringing it up. It varies.

 _We can't even appear as a united front._ This is a biggie, but it's a feature, not a bug. Remember: Agile is not like Scrum. Scrum has a certification process and an ivory tower where you go and get blessed. Agile is just best practices for iterative and incremental development. It's a superset of Scrum, sure, but don't mix them up. Because it's best practices, there's a lot of conflict out there. But that's great! Give me a dozen different options and opinions, let's talk it out, and then I can make an informed decision. The noise is a good thing. People get mad because Agile seems so slippery. One guy said, "It's almost like 'whatever works the best' is then just called Agile." Yes! Exactly! It's changing as we continue to try new things and share more.

So cheer up! I'm starting to hear from companies that want to use Agile for _all_ of their business processes, not just technology development. Eric Ries is doing an awesome job of taking Agile/Lean ideas into the startup world. I'm so optimistic I even spent a few weeks putting down my best thoughts for how to start your team on the best foot. (<http://amzn.to/xUgFxL>) I wouldn't have done that if I didn't think the market was out there for it.

I think Agile adoption is always going to suck -- but it's just because of the nature of trying to get large numbers of people to think differently. If your experience with Agile adoption sucks, it's probably because you are working in a place where a lot of things suck. That's a much bigger problem than just Agile.

<comment><USER30> I took a quick look at your ebook - $50 seems pretty steep, particularly when I can't view more than the first page, and I don't know how many pages there are. A table of contents would definitely help know what the book's about.

Also, it's confusing how you've laid out the "You're doing it Wrong" parts. I'd merge them, call it "You're doing it wrong if..." (the if... is important) and make it all bullet points or else separate the points a bit to make them stand out more (I'm not 100% sure you can do that last bit in Kindle though).

There are other things, but those are the two that I immediately noticed.

<comment><USER29> Thanks! I have a TOC -- just need to figure out how to make that available on Amazon.

The book is very short, perhaps 20-30 pages. I make no apologies about that. The point is to be direct and provide lots of instruction. So if you're looking to pay for your book depending on it's weight, not it's usefulness, probably not for you. I know some of the best hacking books I've owned have been short. I'm hoping to make this book more like them and less like those huge encyclopedia monsters I have on my shelf.

For anybody who wants to see some sample pages and the TOC, just shoot me an email. Happy to help out. Also for more book information, check out the landing page I made for it, <http://tiny-giant-books.com/scrummaster.htm>

<comment><USER30> The landing page is definitely a better place to send people to than Amazon, at least until you get the TOC issues sorted out. And you probably want to expand the book description on Amazon too - currently it's only a couple of sentences.

</comment></comment></comment></comment><comment><USER26> Isn't this a sign that "agile" as he is defining it simply isn't working?

More importantly, why is this a bad thing? We don't really think that this process was "the" process that would stick for the next hundred years, did we?

<comment><USER6> When Gandhi was asked what he thought of western civilization, he replied: "I think it would be a good idea." I feel the same way about the widespread adoption of Agile methods.

What most people are doing under the name "Agile" bears little resemblance to what many of the early adopters used the name to mean. Not that anybody thought it would be the One True Process. As one of the XP originators says, "Extreme Programming isn't where you'll end up. But it's where you should start."

</comment></comment><comment><USER31> I once worked in a very nice team. We used Scrum. We delivered before deadline and the bugs were few. The scrum master was a developer gone PM but with total understanding of which problems you come across as a software developer.

The project would probably have been ok without agile since most of the team was good at their job but I felt it made the process more inspiring and fun. It makes me sad that a lot of people seem to just dismiss it because of bad practices.

</comment><comment><USER32> It's frustrating to me to see So many discussions around "agile" practices. Agile is a set of principles. That's it. I hear less disagreement with the principles and more disagreement with the process in which case I ask, why are you stuck with that process if it doesn't work for your company? It isn't because you're Agile. It's because you're not.

</comment><comment><USER33> A relevant parable is "Meditation Driven Development": <http://www.ckwop.me.uk/Meditation-driven-development.html>

</comment><comment><USER34> Original url here:

[http://www.gilzilberfeld.com/2011/12/4-warning-signs-that- ag...](http://www.gilzilberfeld.com/2011/12/4-warning-signs-that-agile-is- declining.html)

</comment><comment><USER35> I don't believe that agile is really going away, but it is definitely not really the hot thing anymore, at this point, many years since it first became a trend.

And probably a growing number of people are going to be put off by their experiences with "agile", if they are anything like mine have been.

Managers love the idea of releasing more often and understand that. And that part can be an improvement.

However, quite a few people seem to think that means you can fit that many more features in, which is false.

This is the big challenge for agile in my opinion: automated testing or even testing at all, is hard for many development teams for a number of reasons. Not to say that the actual skills or knowledge are particularly difficult to acquire. But practically speaking, putting into place a good testing and release system are challenging for many teams.

And doing "agile" (read: code and release more features faster) without solid automated testing or at least one real QA analyst who is busy, will guarantee that you have a ton of regressions and broken deployments. Now, since you are releasing much more often, you will still gain from getting much more feedback from customers, but there will be loud drone of bug fixing conflicting with the "agile" manager's push to release more features.

If your implementation of "agile" actually includes frequent refactoring and you don't have unit or at least integration tests, you are definitely going to be sorry.

Test-driven development requires a little bit more discipline, sometimes more up-front design, and sometimes investment in developer training. If TDD or the like is off the table or only partially implemented but you are still going ahead with "agile", then you still might survive, if you have a real QA analyst and solid process. My perception and experience is that most managers will decide that hiring an additional person "just for testing" is "not in the budget" and if they do bring someone onto the project for QA they will think they can use just any person rather than hiring a single QA professional.

That has been my experience with agile. Several years in, I am still working on trying to discipline myself and with my latest project I am having a bit of success with vows-bdd integration tests. But TDD/BDD etc. is a skillset that takes time to develop and a discipline that I believe young developers will greatly benefit from if it is part of their early training and experience.

</comment><comment><USER36> tl;dr: Agile is snake oil.</comment>


Ask HN: How to interview a full-time designer? - <AUTHOR>

We're planning on hiring a designer with some html/css skills and a sense of usability. I have no clue on how to conduct the interview.
I was wondering if i could/should ask him to mock or design something (the same way I ask a developer to resolve a problem).
Do you have any advices or resources ? <comment><USER2> Yes, do ask them to design something if that helps you, but make sure you're having him/her design something on the fly that's _related_ to your product, not a real problem you're actually having currently. When interviewing for my summer position at Milk, a part of the application process was re-designing a product that was similar to what Oink could eventually be. The exercise is supposed to be theoretical anyway, so this just furthers the amount of time a designer has to think about the problems and to just get to the solution. This could also be a take-home assignment where they allocate Xhrs to the problem.

More than anything, recognize that the purpose of this exercise isn't to see the designer's abilities (you should be able to see this in their portfolio of previous work), but more about how they approach problems and how they think critically. Understand that no one can ever really outline their design process specifically, but should be able to speak to about the way they solved problems in the past (again, see portfolio) and how they came to solutions.

Talk to them about what they view as "good design" and why they think it. A good designer is ultimately a good communicator and should be able to talk you through why they think it's "good" (in their opinion).

Something that might provide insight is this Behance interview of Ben Barry, Facebook's communication designer: [http://the99percent.com/articles/7118/Facebooks-Ben-Barry- On...](http://the99percent.com/articles/7118/Facebooks-Ben-Barry-On-How-To- Hack-Your-Job). It's not completely specific, but it will give you insight into the way most designers (in Silicon Valley, at least) think about their jobs and their work.

Hope that helps!

</comment><comment><USER3> I would stray away from an on-the-spot design task. Design and UI is a very research and strategy oriented task. The result of an hour or day long test may not be an accurate representation of what the designer is capable of.

If you like his work, commission him for a freelance project as the test. Give it milestones and specs like any other project. Based on the results - concerning time management, style, ability to digest the specs, etc, you can have a better idea of the applicant.

<comment><AUTHOR> Great feedback ! We'll seriously consider hiring him as a freelance first.

</comment></comment><comment><USER4> this sorta thing is pretty religious, so i'm just going to note the following points:

1\. i've known traditional print designers that have jumped headfirst into html/css/js/etc and many of them have left behind artifacts that still live on the web: blogs they've themed, mini web apps, random code snippets, their own web portfolios, etc. investigate these and see if they mesh with what's on their portfolio or what they claim about themselves.

2\. formally trained designers have had lots of experience with critique (and, by proxy, one hopes, critical thinking). Lots of crit is bs, but i tend to favor designers who are _thoughtful_ and can back up their work critically or be honest about their motives.

3\. you can assign "design tasks" if you want, but you need to be clear about what you're measuring and how your questions elicits that. If you're having trouble picking a design task, try a classic system design task (let's design usb from scratch...) and then see what _that_ measures and if you can find some analog in your own problem domain.

4\. the process is not foolproof and you will likely turn away very qualified people regardless of your metrics.

5\. be clear about what you're looking for: do you want somebody that makes stuff look totally sweet, or somebody that solves problems well, or a person that codes monday, designs tuesday, and then specs out a new feature on wednesday... be realistic about your expectations.

6\. people interpret the term 'designer' in a bunch of ways. lots of people take this to mean: "i can think about user flow, use visio to make wireframes, etc" and others take this to mean "how can this look awesome." others take this to mean "i thought through where a menu tree went in an enterprise java application" and others take this to mean "i make graphics design, do you need a logo?" and some others are like the wolf from pulp fiction, they just fix underspecified problems and are good brainstormers. none of these are better than others, they all are useful for different reasons and end-results.

but what i'm saying is "you want a designer? why?" be honest about what _specifically_ motivates your desire to hire a full time designer. this will make any interview you run easier to evaluate as a success or failure.

</comment><comment><USER5> One thing I do is that I show the person our current UI, and ask them what changes would they propose to make things better and the reasons behind their decisions. This really helps to see how the person approaches problems and what kind of design mentally he/she has.

<comment><USER6> While I agree that a live test like this might be a good indicator, I don't know if the candidate would get a vibe that you're trying to get free work (A bunch of suggestions to try after you show them the door). Maybe using some other site, like a competitor or something unrelated.

</comment></comment><comment><USER7> If you do ask someone to mock something up, make sure it's very small (1-2 hours of time max). There's a fine line between an evaluation and spec work, the latter of which will drive away a lot of good candidates.

</comment><comment><USER8> Ask them what they think about the TechCrunch and Kotaku redesigns. If they actually like them, let them go on for a few more minutes, thank them for their time, escort them out, and throw their application away.

Those redesigns are everything that's wrong with young designers (me included). Looks over usability, creative over predictable is the WRONG way to design. Good design is about usability and usability is about predictability, not over complicating what isn't broken for the sake making it different, not hiding elements and loading up info on rollovers just to give the site a "cold, heartless, minimistic, look at me I'm the next Steve Jobs, look", not segregating information pointlessly.

If they can't tell you what's wrong with the designs in detail, let them go.

<comment><AUTHOR> I agree with the usability issues.

We hired a freelance designer few months ago, all their work was gorgeous but the usability sucked.</comment></comment>


Improving maintenance of your Jenkins(file) pipelines - <AUTHOR> https://robertnorthard.com/improving-maintenance-jenkins-pipelines/ <comment><USER2> Rather than coupling your abstractions to Jenkins/Jenkinsfile/Groovy, I strive to put all commands ran from CI in a `Makefile` or something similar. Ideally, a Jenkins step/stage is a single shell command just with the correct environment variables set. This makes it super easy to reproduce locally, switching to another CI tool is much easier, and your Jenkinsfiles are 20% of the length and only focuses on things directly related to the CI tool itself: parallelization, cleanup, notifications...

<comment><USER3> You should definitely keep your Jenkins steps around a single command, like executing a Makefile as you suggest. The problem is maintaining the job configuration itself.

I've seen some places configure Jenkins jobs for a project in the repo itself, so running a specific type of build depends on it being defined in that revision of the repo you're using.

<comment><USER4> And this is why Jenkins is horrible. You have a Jenkinsfile, which describes jobs in code, but... you need to create a job... to use those other jobs... and there's no simple, officially supported way to do that as code.

There are 4 _basic_ ways to manage the initial job configuration: By Hand, Save The XML File, JCasC, and Groovy init files. JCasC is of course the most ideal, but also the least intuitive, and requires further server setup. Putting a Groovy file in an init directory is the most straightforward way, using code. And if the Jenkins server is already running, you need a specific interaction with some API call to actually update the job in the running server.

You can also do more horrible things, like Jenkins Job Builder, but I think making someone manage that is against the Geneva Conventions.

<comment><USER5> I haven't used Jenkins in 2 years, but before that I used the Groovy DSL plugin.

A job that would run that and create the other jobs.

Incidentally, a similar (but native and more streamlined) approach is taken by Buildkite: job that processes a DSL that then generates other jobs (could even be recursive if you like that sort of thing) [1]

[1] [https://buildkite.com](https://buildkite.com)

<comment><USER4> I know that in some cases that's the best solution to a problem, but I try hard to stay away from generative processes. There's a raft of complexity issues that arises from the need to reproduce exactly the same behavior and results, and usually you're introducing several new layers of complexity (a DSL, a job to process it, jobs generated from it, actions taken by those jobs, the input and output of each process... versus one giant static job with minimal variability).

<comment><USER5> It was certainly unpleasantly complicated.

</comment></comment></comment></comment></comment></comment><comment><USER6> I've used Jenkins in a few places, right back from when it was Hudson. Back then I was amazed at the concept of CI in general so it was pretty great.

Over the years I've worked with most of the major players, most recently Gitlab CI. The one thing that makes it hard to go back to Jenkins is the poor quality of the plugin ecosystem. So many are abandoned or buggy that any upgrade comes with a breath and a prayer.

I'm probably gone for good. Appreciate everything they did for the industry but there are more robust choices around.

<comment><USER7> What can you do with Jenkins and not GitLab CI that made you go back to Jenkins?

<comment><USER8> > The one thing that makes it hard to go back to Jenkins is the poor quality > of the plugin ecosystem.

I don't think they went back to Jenkins.

</comment></comment></comment><comment><USER9> We have great experience with this!

Developed shared libs that serve full enterprise organization and do complex deployments. If project follow same rules, it is easy to encapsulate logic into shared lib and have jenkinsfile to call it with few params.

e.g. Jenkinsfile ``` @Library('common-libraries') _ deploy(product: 'xyz', environment: 'exyz') ```

Then, updates in shared lib propagate to all projects.

<comment><USER10> Same here. All deployment and build is provided by one library. Made it exceptionally easy to change the deployment model and update things because of changes in the build environment.

</comment></comment><comment><USER11> Nowadays I actively avoid Jenkins for almost everything after seeing it _fail_ in companies of different sizes (mostly medium/big ones).

Not that Jenkins itself is bad but keeping the base and plugins up-to-date is really painful. There are a lot of plugins, yes, but many are basically inactive or poorly written (some are really good tho).

The good thing is that there are some alternatives to Jenkins, even very good ones if you have money to spend.

</comment><comment><USER12> I don't understand the jenkins hate in the comments. It's very flexible, and if you limit your plugin use you can use it to do pretty much anything you want.

It's also easy to run locally despite what some people have said in the comments. You can literally download a war file and run it with java -jar jenkins.war.

Jenkins is powerful, flexible, and easy to set up. Just avoid most plugins and run your own Groovy/python/shell scripts. Easy peasy.

Also - what are people running in place of jenkins? The only tech I've seen mentioned is gitlab.

<comment><USER13> Modern CI easily loads the pipeline definition from the source branch.

Getting Jenkins to load a pipeline definition from the source branch is extremely complex, so much so that I've yet to see it done well.

</comment></comment><comment><USER14> Jenkins is bad. I have the displeasure of using it for the first time in my current role and I find that its too complicated and abstracted for the 90%. I am sure its great for complex pipelines but for just the 90% of CI/CD pipelines I just do not grok it well. Perhaps I was spoiled with managed solutions like CircleCI?

</comment><comment><USER15> Does anyone still use Jenkins willingly?

<comment><USER9> what is your problem with it? :) It is usually not the tool bad, but ppl using it can't do it right.

<comment><USER16> Not the OP, but I'm wary about implementing build logic in a form that's only executable on a server. Pipelines are one step better than the old style build configuration, but still inferior to just having the whole build/test/release cycle defined in scripts in the branch which can be run anywhere.

<comment><USER17> We have started using Makefiles for this. Our Jenkinsfiles are only used for the orchestration and reporting. All our applications can be build, tested, and released by our employees on their machines. Works great for us!

</comment></comment></comment></comment><comment><USER18> But how to retrigger all jobs that are loading a plugin, when the plugin is updated?</comment>


Show HN: Word Stats - Find most used words of Twitter users - <AUTHOR> http://klivk.com/wordstats/

<comment><USER2> Any plans to open source?

<comment><AUTHOR> Yes, when I tidy up the code in the next version :)</comment></comment>


UX: Why do washing machines have windows? - <AUTHOR> http://ux.stackexchange.com/questions/50259/why-do-washing-machines-have-windows <comment><USER2> I love the first answer. Demonstrates the folly of these UX people.

Common sense design: "to see if the machine is full."

UX design: "the water is dynamic and responsive, exciting to look at, calming, relaxing, inviting."

This is why so many startups die.

<comment><USER3> Thank you, I'm not alone into thinking most UX stuff is BS. Another platform for 'talkers' to look like they build.

I understand the concept of making the interface intuitive and easy to use and I am all for it. But my God, some of the BS I've heard from people to justify crap is insane.

Most of them aren't worth their salaries.

I'm interested in UX as much as any of these goons. Difference is, I can actually code/build it as well.

<comment><USER2> _Precisely_ my thoughts. I can add nothing else so I shall not.

</comment></comment></comment><comment><USER4> From personal experience I can attest that the answer 'so you can see the machine is full of water when it stops mid-cycle' is the right one. I've had my washing machine break down while full of water, and if I hadn't known when I got home and opened it unsuspectingly, I would have been very, very unhappy. You'd be surprised how much water the machine contains when it's full...

<comment><USER5> That wouldn't explain why dishwashers don't have them.

Opening one of them that has broken down full of water isn't much fun either.

<comment><USER6> Dishwashers don't fill with water. They just spray a high temperature water at the dishes and the water is drained immediately.

<comment><USER5> They do when the outlet pipe gets blocked.

<comment><USER6> Anything can happen when not operating as indented.

</comment></comment></comment></comment></comment><comment><USER7> According to Wikipedia ([http://en.wikipedia.org/wiki/Washing_machine](http://en.wikipedia.org/wiki/Washing_machine)): "For front-loaders without viewing windows on the door, it is possible to accidentally pinch fabric between the door and the drum, resulting in tearing and damage to the pinched clothing during tumbling and spinning."

</comment><comment><USER8> And why don't dishwashers?

<comment><USER9> Because dishwashers don't fill with water, hot water is sprayed on the dishes from the rotating hoses and drains more or less immediately. The only way for a dishwasher to fill is that the drain is blocked.

See [http://commons.wikimedia.org/w/index.php?title=File%3AGeschi...](http://commons.wikimedia.org/w/index.php?title=File%3AGeschirrspuelertv.ogg) for a (low-quality) demonstration.</comment></comment>


$100 marketing budget for launching mobile app - <AUTHOR> What is the most effective use of $100 to promote the launch of a mobile app? <comment><USER2> facebook ads.

I work in adtech but also own an ad agency.

Buy installs using fb ads. Target your target market tightly.</comment>


But Can You Make Pong? (2003) - <AUTHOR> http://tinodidriksen.com/2003/05/06/but-can-you-make-pong/ <comment><USER2> Another good game is to try and make Tetris - that was my first, and illustrates the author's point pretty well: a game is more than just the small bit the player sees, but rather a whole host of orchestration to get to that point. Though I'd argue game makers should use HTML5 or something like Unity these days rather than writing their own engine :)

</comment><comment><USER3> I made a single-player "squash" pong in about an hour in HTML, CSS and Javascript but that's just the paddle and bouncing. The author has a very good point that could probably be rephrased like this: Making a complete end-user program may require quite lot of studying, planning, wrong choices, rewriting, testing etc. It takes time.

</comment><comment><AUTHOR> I find this to be a really good reality check for new game programmers. It's a really simple game to make but most new people are still surprised at how complex it is to actually do.</comment>


Ask HN: What is the modern stack of SaaS products for a SaaS company? - <AUTHOR> What are the common tools needed to start a SaaS company? <comment><USER2> I used to work with a lot of SaaS companies at my previous consulting company, these are the most common tools I saw:

\- _Sales_ : Salesforce, Gong.io, Intercom, Outreach, Highspot

\- _Product Development_ : Github, Jira, Pendo or Heap, Sketch, InVision

\- _HR_ : BambooHR, Lever

\- _Other_ : G Suite, Slack

That being said, this is what's the most common, not what's the _best_ that's available. There's plenty of other SaaS products that might be better for your company and use cases!

</comment><comment><USER3> That's kinda like asking "what is the modern car for executives?"

It really depends on what you're making and what you're familiar and productive with.

I still use jQuery along with Bootstrap and PouchDB on the client side and the Apache web server and CouchDB on the server side.

</comment><comment><USER4> Start with a "boring technology" [0], something that has been around for a long time and is likely to remain around for a long time. You don't want to waste too much time fighting with the new and shiny tech because building and running SaaS is so much more than just writing code. The reason I'm bringing this up is because the technology choices that you will make, will inform a fair amount of tooling-related decisions down the road.

I started working on Hexadecimal [1] earlier this year, and chose Rails, Postgres, and Redis for the job. It allowed me to get up and running quickly without wasting my brain cycles on wrestling with the unproven tech. Another benefit of using a boring technology is that there are lots of written and spoken material (e.g., blog posts, Q/A, conference talks) accumulated over time, so there is a high probability that someone already had a problem that you might encounter.

> What are the common tools needed to start a SaaS company?

That will depend on many factors: how big is your team, how much money and time you are willing to spend on particular problems, etc.. I'd say if you are a solo developer (or a small team), try to use managed services as much as possible but keep a sharp eye on your monthly costs. If you are on a shoestring budget (think bootstrapping), those $19 / mo subscriptions here and there can add up very quickly.

I do share my costs (and tools) that I use to run Hexadecimal publicly [2]. That should give you a vague idea about what tools it takes to run a bootstrapped, one-person SaaS. There are similar pages on the Internets that delve into that topic [3][4]

[0] [http://boringtechnology.club](http://boringtechnology.club)

[1] [https://tryhexadecimal.com](https://tryhexadecimal.com)

[2] [https://tryhexadecimal.com/costs](https://tryhexadecimal.com/costs)

[3] [https://cushionapp.com/running-costs](https://cushionapp.com/running- costs)

[4] [https://www.candyjapan.com/behind-the-scenes/running- costs-f...](https://www.candyjapan.com/behind-the-scenes/running-costs-for- candy-japan)

</comment><comment><USER5> (Node, Redis, Mongo) pushing things to React/Vue/Angular

Everything else is just to keep nontech people busy on things you'll never do so they feel like they have a purpose and their presence helps people take your company more seriously</comment>


Why is it acceptable for Chrome to serve me ads right on my homescreen? - <AUTHOR> I opened my browser to this today! A Nest ad right inside my browser.
https://imgur.com/gallery/NeL09au
Anyone else bothered by this? Are they testing the waters, as usual, and if there is a backlash they pretend its an internal error? <comment><USER2> To be fair, Firefox also frequently displays ads for their own products (and sometimes affiliate links) on their new tab page. Maybe something like Opera would be better about that, but I don't know.

<comment><USER3> And, again to be fair, you can turn those off by clicking the gear in the upper right.

(maybe you can turn the Google stuff off in Chrome, too?)

</comment></comment><comment><USER4> Empty New Tab Addon: [https://chrome.google.com/webstore/detail/empty-new-tab- page...](https://chrome.google.com/webstore/detail/empty-new-tab- page/dpjamkmjmigaoobjbekmfgabipmfilij)

I use it for years now.

</comment><comment><USER5> I use Blank New Tab Page on Chrome - [https://chrome.google.com/webstore/detail/blank-new-tab- page...](https://chrome.google.com/webstore/detail/blank-new-tab- page/jaadjnlkjnhohljficgoddcjmndjfdmi?hl=en)

Originally I got it because I noticed that seeing the same few sites on the new tab page influences my browsing patterns. I suppose it also works for avoiding messages from Google.

</comment><comment><USER6> I use Markdown New Tab so my default tab is whatever I want it to be.

Currently it has links to my most common visited sites, a TODO list and some bookmarks for a subject I'm heavily absorbed in.

No ads whatsoever, and it shows whatever I need/want it to show. And of course, markdown is pretty slobberproof.

</comment><comment><USER3> I think they try to make the "blank page" screen like a fancier google.com, which frequently has similar ads.

Switch to Firefox :D

</comment><comment><USER7> If you want to get rid of it, the chrome plugin named Momentum is nice.

</comment><comment><USER8> Doesn't everyone know the answer to this question by now? How much have you paid for Chrome? If it's nothing, then why wouldn't they serve you ads?</comment>


My husband disappeared and sent a rapist to attack me - <AUTHOR> http://itisnotmyshametobear.blogspot.com/2013/11/it-is-not-my-shame-to-bear-part-1.html

<comment><USER2> >I had gotten myself raped. I had allowed it. And I just needed to get over it.

No, nobody should just "get" over it. This was a powerful outpouring over a very difficult, and very complex, issue.

I'm going to make a possible unpopular series of statements but first I want to get the following out:

What happened (over and over again) was horrible and should never have happened and there's no excuse for it. All of those responsible should be punished severely. I mean this in the strongest possible way. Nobody has the right to do this to another person and no victim should ever be to blame. It is _critically_ important for any victim of rape and physical or sexual abuse to report it to the police.

Now on to the possible unpopular part, which I think I should motivate a little lest it seem I'm being callous.

Some select statistics [1]:

\- According to the National Victim Center, 683,000 women are raped each year. (1992)

\- Sexual assault is reported by 33-46% of women who are being physically assaulted by their husbands. (AMA 1995)

\- 6 out of 10 rapes are reported by victims to have occurred in their own home or home of a friend, relative or neighbor. (US Dept. of Justice 1997)

\- In a study of 6,000 students at 32 colleges in the US, 42% of rape victims told no-one and only 5% reported it to the police. (Warshaw 1994)

\- Only 2% of rapists are convicted and imprisoned. (US Senate Judiciary Committee 1993)

\- 77% of rapes are committed by someone known to the person raped. (Bureau of Justice Statistics 1997)

\- _In a 1999 longitudinal study of 3,000 women, researchers found women who had been victimized before were seven times more likely to be raped again. (Acierno, Resnick, Kilpatrick, Saunders and Best, Jnl. of Anxiety Disorders 13, 6.)_

Now the possibly unpopular part:

When I was growing up, there was a popular radio show on called Loveline (it might still be on) hosted by Dr. Drew Pinsky (an addiction medicine specialist) and Adam Carolla. As a teen it was fun to listen to people calling in with various oddball sex and relationship questions. But about once a show, some poor girl would call in with a sad story about all the abusive boyfriends they had had. _Every Single Time_ Dr. Drew would ask the question "who abused you when you were little?" and _every single time_ there was somebody in the girl's family who had physically, emotionally or sexually abused her.

Dr. Drew would then patiently explain that she needed to get some very serious psychiatric treatment and that, something about that experience seems to fundamentally break a person's ability to find and form functional healthy, intimate, relationships. They'll continue to seek out abusive relationships and it'll keep happening until they properly deal with it or they find themselves at a very sad end.

Something about that hit me and stuck with me, and over time I've noticed that my friends and family who seem to have the worst repeated relationship problems all have had abusive (on some level) childhoods -- men _and_ women. It wasn't just that it was surprising, or paradoxical, but that Dr. Drew answered it almost on autopilot. It was such a common pattern that, even when the caller tried to avoid answering it, or coyly tried to redirect, eventually it always came out at something like near 100% of the times I heard the story. It somehow slotted into an addictive behavior pattern that people who suffer from it are not really even aware of -- even if they can talk at length about it and sound quite lucid.

As I read this story, those episodes came back to me: the abusive childhood, the rapist husband, continued assaults, and I kept reading, hoping to see that "notmyshame" had sought out such help. But it never came.

Coming out about being raped is an incredibly brave thing, writing about it and sharing it is one of the most difficult things a person can do. But moving on and getting the right kind of professional help is _just as important_. I hope that the next post I read from "notmyshame" is that she went and found somebody professional to not only help her with the pain of the rapes and the abuse, but for the possible relationship issues that she may continue to have unless it's properly dealt with.

1 - [http://www.webpages.uidaho.edu/monsters/drake/Lecture%20Note...](http://www.webpages.uidaho.edu/monsters/drake/Lecture%20Notes/rape_statistics.htm)</comment>


Visual Studio 2012 New Features: Solution Explorer - <AUTHOR> http://blogs.msdn.com/b/zainnab/archive/2012/06/21/visual-studio-2012-new-features-solution-explorer.aspx

<comment><USER2> Being able to see the classes in a file is a nice touch. Good to see some of the cooler parts of Eclipse making it over. I find the sentence "searching within file contents doesn't mean what you think it means." a little strange though. If it doesn't mean what the user thinks it means, maybe they should give it a different name :|

One feature I wish the solution explorer had would be to setup a view of only pre-selected files. I find sometimes I'm working between 4-5 files and the only way to keep track of them is to have them open in my tabs. If I have to check two or three other files, my tabs become a mess. What would be nice is to have a 'view' in solution explorer that lets me just see those 4-5 files, maybe even let me jump between views through tabs on the solution explorer instead.

<comment><AUTHOR> You can open them and then select a filter view just opened. Or you can open the ones you don't want to keep opened with just a single click (the new preview feature)

</comment></comment><comment><AUTHOR> The amount of polish that goes into VS is incredible. It's a pity these little useful features are quite hard to find

<comment><USER3> I haven't used the betas of the new version, but I'm not sure I would describe VS as particularly polished. It's better than Eclipse, but IDEA beats it handily. Even Xcode (newer versions) comes out in front, in its own XCode-y way.

I actually rather enjoyed VS as a whole, especially the debugger. But we're talking UI polish here.</comment></comment>


Mixins, Subclass Factories, and Method Advice in JavaScript - <AUTHOR> http://raganwald.com/2015/12/28/mixins-subclass-factories-and-method-advice.html <comment><USER2> This is probably a somewhat fringe sentiment, but reading this reminds me very much of [http://codeofrob.com/entries/you-have-ruined- javascript.html](http://codeofrob.com/entries/you-have-ruined-javascript.html) (I was making very similar comments while reading this)

I'll readily admit I'm biased against OOP; I much prefer functional approaches. When I write Javascript, it tends to be pretty functional, with minimal OOP conventions.

But that said...all the problems this addresses are self-inflicted problems. The very start of the article even says as much, "Mixins solve a very common problem in class-centric OOP" \- that is, "these problems are only problems because you want to write Javascript in class-centric OOP", something it wasn't really designed for (and the constant attempts have led to Ecmascript 7 and the 'class' keyword, which I find myself shaking my head at; again, see prior link, at trying to make Javascript feel 'enterprisey').

Find another way to go about it maybe? The subclassFactory example he gives...if I saw that in a code base I'd want to punch someone. Because without the writeup he gives, I'd be staring at it, and the functions it calls, for a good 20 minutes before figuring out what it's doing. And all it's doing is trying to shoehorn a specific paradigm into a language not written for it. I mean, you can do it, sure, but -why-? I don't really like Javascript but at least I feel pretty productive in it; why would I make it harder on myself, and everyone who reads my code after me, by trying to make it something it isn't?

<comment><AUTHOR> Perhaps the author ought to spend some time reading a book like JavaScript Allongé and learn how Functional Programming in JavaScript is done ;-)

[https://leanpub.com/javascriptallongesix/read](https://leanpub.com/javascriptallongesix/read)

<comment><USER2> Sarcasm aside, I know raganwald (you?) can approach things functionally. :P My comment isn't to imply he can't (nor that I'm particularly good at it), nor to imply anything about his choices when writing code (as I said, he correctly notes that this is an issue when trying to write class-centric OOP in Javascript; this says nothing about his views on whether class-centric OOP in Javascript is a good idea or not). And, certainly, come ES6, mixins get some language help with Object.assign.

My point is simply that if in ES5 you have to fight this much with the language to try and shoehorn it into a particular paradigm, maybe you've picked the wrong paradigm for that language. And the fact so many people try, and so many authors have written ways to try and shoehorn that paradigm into the language (as it stands at ES5), tells me that it -really- is probably not the best choice.

And the insistence in doing so seems like a misplaced "make it behave like Java" that brought to mind that URL I linked.

That's not to say thinking about it isn't itself a worthwhile endeavor. That's not to say that seeing that it can be done in Javascript isn't a point in Javascript's favor. That's not to say there isn't a demand by people for the language to behave this way, and that others understandably try to meet that demand. But it is to say that it's solving a problem that is self-inflicted, by dint of choosing to use classical inheritance in a language that was designed to support prototypal inheritance.

<comment><AUTHOR> It's a question of taste.

To me, hierarchies of classes are not very JavaScript, but mixins written as decorators are very JavaScript.

To me, overriding functions and calling `super` is not very JavaScript, but writing function combinators like `before` and `after` is very JavaScript.

To me, JavaScript is about composing bunches of single-responsibility things, not writing big things.

So to my taste, mixins and decorators are in a deep way, strongly related to functional programming, while the sugar for stuff like classes and special syntax for getters and setters is not.

<comment><USER2> That's fair, and I'd agree that mixins and decorators can be more closely related to FP than I initially took them for.

I just tend to keep my objects as, basically, structs, and functions bound outside of them, rather than treating them as objects, so questions of composability in such a manner don't come up. Rather than have to write a lot of abstracted out code to support mixins, and then know what assumptions a mixin has about the object choosing to mix it in, there are instead just functions; you want them then reference them, and what they take is spelled out (somewhat more) clearly in the function header, if you can pass in the right arguments, the function can be reused. If you want a set of functions that all work together, then composition, sharing state, etc, falls on you, rather than being implicit in assumptions the mixin and mixing class may make about each other. As you say, a question of taste (especially as to what steps you take to avoid those assumptions).

But that said, I've done similar things in merging two objects prior to serializing them out across a REST endpoint. So there it was less a design consideration of composable function containers, and more one of data transformation (not that they're separate beasts; functions as data and all that), but at the same time a lot of the complexities were avoided.

</comment></comment></comment></comment></comment><comment><USER3> Great write up, and neat ideas. One of my biggest hurdles on learning Javascript so far is that because definitions are so flexible, its very difficult to pick up a code base with an unfamiliar structure. Mixins in particular spread code between files, and the mixin itself is often hidden, or not obvious. At least in Java, I know I can look at extends, and trace it from there.

The decorator pattern seems like it would be pretty obvious. But its yet another non standard way to create objects. If I saw without explanation, I would be at a loss on how it works, or even what it does. At least method overriding is consistent when it is baked into a language. But having to learn a new mixin/inheritance/definition pattern for each codebase has given me serious troubles recently.

<comment><AUTHOR>
      > At least method overriding is consistent when it is baked into a language

Right there you have one of the two great families of programming. You like things like Python, where there is only one obvious way to do anything, and if it isn't obvious, you just don't do it. These ideas are from the other family, where you have a number of small but powerful ideas that you can combine in various ways.

The ones that solve problems and have great timing and get some marketing oomph establish community traction, the rest fade away. This is the UNIX and Lisp tradition.

I can't tell you whether one is better than the other. I can tell you that the first thing is IBM. And opinionated frameworks. And benevolent dictators. The second thing is startups. And libraries. And tinkerers. There's no shame in preferring one to the other. Both have produced great things.

<comment><USER3> I look forward to the day when the rest fades away from Javascript. Right now it is the wild west in terms of pattern usage, especially when it comes to implementing "private" variables with some scope tricks that result in unreadable code.

</comment></comment></comment><comment><USER4> I like what raganwald writes but let's get real here. People asked for the class keyword because it made classes easier to write AND read. OOP with prototypes is dreadfull, from a "clean code" perspective.

Javascript should get the same perks for mixins, because going back to "builders" is going back to everybody writing his own flavor of the same stuff and doesn't make things readable anymore.

Is there a mixins proposal for ES7 ?

a simple thing would be to allow multiple inheritance :

        class Foo extends Bar,Baz {}

just like Python

I think the Python way is the simplest one.

<comment><USER5> You know, given the sheer amount of JS that has been written successfully in the last ten years, I think it might be worth asking: is it really _needed_ to continue mudballing that type of stuff onto the language?

Especially with mixins and things, it's really easy to add so much magic to the code that getting up to speed on what something is doing becomes prohibitive. It's really great for flavor-of-the-week frameworks, but long term maintenance can become a nightmare and proper performance tuning difficult.

Then again, maybe we don't care about maintenance and performance anymore.

<comment><USER4> > You know, given the sheer amount of JS that has been written successfully in > the last ten years, I think it might be worth asking: is it really needed to > continue mudballing that type of stuff onto the language?

That's a good question. If it helps write a specific pattern and make it more readable I think it's worth it.

People are going to write these stuff anyway, why not help making things more readable for anybody else ? it's not going to change the nature of javascript, I'd argue that things like proxies or decorators are far more questionable than multiple inheritance, yet they made/are making it to the spec.

Nobody can deny Python code looks usually clean and mostly readable. Nobody can deny that Javascript code is often unreadable because ES3/5 developers didn't have the syntax to convey specific ideas in a eloquent way(thus all the prototype plumbing, module pattern and co that made js code look like brainfuck,don't even get me started on ninja coding).

<comment><USER6> Javascript is not readable to you because you're attempting to apply OO patterns to it.

Javascript is not an OO language, it doesn't work like that.

It is an incredibly powerful and elegant language, please take the time to learn how it works and appreciate its beauty. Then by all means make suggestions about how it should be changed. But only then, please.

Not all languages would be improved by being "more like Python".

<comment><USER4> > Javascript is not an OO language, it doesn't work like that.

What ? it certainly is today with the "class" syntax. Or it is like saying neither Ruby or Python are object oriented.

> elegant language,

Elegance is in the eye of the beholder

<comment><USER5> Minor point of order...Ruby is OO because it very much follows the Smalltalk- style message-as-function-invocation pattern.

Javascript (at least before ES6) is perhaps too minimal in its language affordances to qualify for "true" OO status.</comment></comment></comment></comment></comment></comment>


Audi's Self-Driving Car Hits 150 MPH on an F1 Track - <AUTHOR> http://www.wired.com/2014/10/audis-self-driving-car-hits-150-mph-f1-track/?mbid=social_twitter#slide-id-1610905

<comment><USER2> Not sure how impressive this is. Isn't this just processing power and different performance profile data? If they could solve the driving in a busy urban environment in torrential rain I would be more impressed.

<comment><USER3> It's impressive. Making anything completely driverless working at incredibly high speeds is challenging.

<comment><USER4> Much easier to test a race track than a busy street too.

<comment><USER5> The impressive part about Audi's technology is that it doesn't use very detailed track data to achieve this but is mostly depending on a variety of sensors to anticipate to current road conditions 'on the fly'.

<comment><USER6> From the article:

 _While the RS7's computer had a detailed digital map of the track and was following an optimized path through it, Audi did not preprogram things like torque or steering._

<comment><USER5> "Audi did not preprogram things like torque or steering."

And that was my point, unlike BMWs famous testrun (with Jeremy Clarkson) where the car was programmed to steer and give gas for every inch of the track, the Audi is actually able to make those decisions on the fly with the information it gets from its sensors.

EDIT: So yes it does use GPS data, but does not rely on it as much as others (including Google).

<comment><USER7> You missed the part about the F1 test track?

This obviate the need for deeper GPS depenendence.

You have a 3D track designed with graduated radius turn transitions, smooth topological surfac transitions, and predictable fiction levels. All in a general layout that is suited to safety at speed.

Try running this car at 150mph on glendora mountain road, at night, during a bout of santa-ana cross winds.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> To put the 2:10 minute round time in perspective [http://en.wikipedia.org/wiki/Hockenheimring#Record_laptimes](http://en.wikipedia.org/wiki/Hockenheimring#Record_laptimes)

I wonder why they didn't use a [http://en.wikipedia.org/wiki/Audi_R8](http://en.wikipedia.org/wiki/Audi_R8) if the goal was racing?

<comment><USER9> They're likely not working with the R8 because their self-driving capabilities are a marketing tool to compete with the likes of the Mercedes S-Class.

The R8 is also at the end of its product life-cycle so they're probably trying to keep it out if the limelight as much as possible.

And yes, formula 1 comparisons are unfair, but if they're actually within 30 seconds of DTM cars that seems pretty impressive.

<comment><USER10> >And yes, formula 1 comparisons are unfair, but if they're actually within 30 seconds of DTM cars that seems pretty impressive.

The comparison that's really missing is to put a good racing driver in the same car and same conditions and seeing how much faster he can go. We're not testing the car here after all just the self-driving tech.</comment></comment></comment>


Tell HN: A small HTTP/REST dev utility I made. Hope you find it useful. Enjoy. - <AUTHOR> http://whatheaders.com/

<comment><USER2> Not sure I get it. It seems to me that the headers are always going to be the same when I use your page (maybe an exception would be the referer.)

For technical feedback: you have a bug. The request isn't displaying properly. It showed mine as:

      GET HTTP/1.1
      accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
      accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
      accept-encoding: gzip,deflate
      accept-language: en-us,en;q=0.5
      connection: keep-alive
      host: whatheaders.com
      keep-alive: 115
      referer: http://news.ycombinator.com/
      user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

Notice the "GET HTTP/1.1". It should probably read "GET / HTTP/1.1"

<comment><AUTHOR> Thanks for the feedback. Re the request path, that was intentional: since the path will _always_ be "/", I didn't see a good reason to explicitly print it; and instead just show the request method and protocol version. That said, I get your point: it's a bit surprising, so will consider modifying it.

As for how it's useful: Whatheaders.com is interesting and useful when you are working with some "black box" HTTP client, and which you cannot conveniently know what request headers it is sending. In particular, mobile-device web browsers, which are wildly divergent, capricious, and undocumented in their behavior; sometimes the only way to know what they are doing is to measure it directly. That's why I made it originally, in fact.

I imagine it would be similarly useful with any other kind of proprietary HTTP or REST tool or library if you don't have access to the source, and need to know exactly what headers it's sending in order to troubleshoot, etc. For something like Firefox with (e.g.) livehttpheaders installed, or standard vanilla web browsers like IE or Safari, IMO whatheaders.com isn't terribly interesting.

Be sure to read <http://whatheaders.com/about/> for more details.

</comment></comment><comment><USER3> This is effectively the the output from the sample CGI application that prints the CGI environment variables, filtered for the ones that start with HTTP_. [http://httpd.apache.org/docs/1.3/howto/cgi.html#whatsgoingon...](http://httpd.apache.org/docs/1.3/howto/cgi.html#whatsgoingonbehindthescenes)

I believe the sample that came with the original NSCA was two lines, echo -e "Content-type: text/plain\r\n\r" and /bin/env.

Sample code is now a web service.

</comment><comment><USER4> Handy! But I urge you to keep a list of addresses which have opted in to receive email (just HMAC their address and send a challenge). Spammers will definitely try to abuse this, probably with ASCII art in their HTTP headers.

<comment><AUTHOR> Gotcha, thanks!

</comment></comment><comment><USER5> Fails on CONNECT requests, and you should probably override the TRACE response, even if it means braking the protocol. It's for testing, after all =) And what's so REST about it? I would understand if it received requests to any url, then you could change the host in the application you're testing, but still keep the path.</comment>