Well, save one useless chick, my group's been pretty busy drawing up diagrams and stuff and posting the pics into the group chat. I feel pretty worthless so far so i told them i'd try to install VS 12 and sfml 2.0 tonight on my laptop (by the way, anyone know how to get VS to install to D:// instead of C?) which seems like a pretty awful choice for this project but whatever.

Told my group leader there are tools like java/eclipse where you can literally drag and drop components and all you gotta do are code the clickevents and we're done with half of it. He didn't go for it though.

Sfml doesn't even have buttons.. You gotta make your own. So maybe we will have a lot of documentation.

To make myself useful maybe i'll draw what i have in mind for class hierarchies and ****. I hate group projects. I wouldn't care as much but he said everyone in the group rates everyone else in the group and that's also part of the grade...

Installing VS 12 on the d: drive should work ok as IIRC user is prompted for a folder location. There is a default suggestion but you can override that. IIRC you are doing a C++ project. If so yeah there are better alternatives than VS12 for C++ GUI development. Btw Microsoft has a pre-release version of VS 15 available. It probably works pretty well. Herb Sutter a C++ Guru is pretty excited about it

Does anyone have a handle on this? Can anyone suggest a good resource?

I feel like 80-90% of the "bugs" we get in QA are actually feature requests, and we usually just build in some buffer so we can agree to "fix" a bunch of stuff and only push back on things that are too time consuming.

We even made a mistake with one client (some of it due to the main two people on the project fathering children days apart) where we just let the client go nuts with requests and set the precedent of including way more than we should have.

The scope creep is real.

This is one of those articles that I think is a third obsolete, a third wrong, and a third right.

I always felt that Spolsky didn't really understand Agile development when he was writing his blog. Although in his defence that might have been because it *was* much less defined and also because his interest in selling bug tracking software meant he had to argue against some things for marketing reasons. I'm sure his Microsoft / shrinkwrap software background wasn't helping any.

I'm far from an agile purest, but I actually love the idea of calling bugs and features the same thing. In an agile universe you're working closely with your 'customer' and so if they can live with a 'bug' because they'd rather have a new 'feature', than that's cool. It's all about what gives them the most bang for their buck.

Regardless of the 'type' of software, this is true. The differences in software types should influence what the customer/product manager cares about, but not really how you differentiate bugs from features. There are still times where its better to ship standalone installed software with some bugs and a killer feature rather than perfectly working software that doesn't have enough features.

The problem is when the business arrangement is very specific about the deliverables. In that case you need to differentiate from a bug (something you agreed to deliver that isn't working properly) and a feature (something the 'customer' hasn't paid for). But I'd argue this isn't agile anyway and is a poor process.

Edit: I also think most ****tily implemented agile processes are still better than waterfall because at worst it usually just is waterfall. Someone comes up with a big spec for a 12-month project. And then the dev teams work their way through the big giant spec in 'sprints'. But at no point is there any meaningful backlog management because at the end of the day the big giant spec 'needs' to be implemented.

This is the reality of client-facing work.

The differentiation is super important and I don't really see how you can have a better process. The client is often times not aware or capable (or willing) to see something as out of scope.

When working on internal development, you don't need to add addendums to contracts everytime you need to add costs. Increasing scope means increasing billing and if you don't differentiate where are you left?

It doesn't need to be the reality of client-side work, but I accept that it often is. But its basically just the waterfall process since everything flows from the contract.

But there are still lots of things you can do to help the client be aware of what is and isn't in scope. Use cases and acceptance tests. And so on. *

We also use to approach these conversations as telling the customer here are the things we agree are in scope, here are the things that we think aren't in scope, and let's have a conversation about if you'd like to trade some stuff. It works pretty well.

If you're doing consulting work though with a customer unwilling/unable to have these conversations I guess its ultimately up to you guys to ensure you build in enough padding.

Edit: * We also did the "You get everything or nothing" type of deliverable. We'd do a 2 week acceptance period where the customer could use the product and give us fixes they wanted us to make. At the end of that 2 week period they could either take (and pay for) what was available or they could get nothing (and realistically I'm sure in most cases this was really the 'get sued' by us option). Obviously they want their software so it kept them from endlessly giving us bugs/feature requests they wanted. It forced them to prioritize the things they really wanted. I'm sure this doesn't work for all situations though.

We have a monthly NoScrum meeting at Yammer It's pretty sweet.

Jj what type of software does your company develop?

We do the same thing with 2 weeks, but it often isn't enough time for the client so it goes over.

All or nothing would destroy our cash flow, so we have milestones, but with seriously problem clients we sometimes have offered to deliver as-is and not collect the final milestone, just to get them the **** out. That is a nice play to have.

We provide a test plan and have all the features/user stories and everything in there.

The issue is when the client gets stubborn and starts calling things "sloppy" etc. when in reality they are 99% of the time admin functionalities that basically everyone using this software is using.

I think I explained it rather poorly and not directly. The issue is basically that we are building on a full open source stack and are quite literally willing to customize anything within reason (i.e. not doing things that break updates and are security concerns, outside that tho...) so when clients "forget" to get things in the original scope, or didn't know to ask because they didn't see the final product, it's hard to all of a sudden say no. Another reason is at this point the project is 95% done and we want to use them for marketing/ references/ submit for awards, etc.

It ends up with clients having a somewhat imbalance of power where if they want to get all unreasonable on us in terms of acceptance criteria, it puts us in a tough spot.

For the company where I did the custom work we were doing a bunch of different things.

Some things were 'products' in the sense that it was a web application that we had complete control over and sold it on a yearly subscription basis. Basically SaaS before SaaS was a popular term. We also made some mobile device software (good old palm pilots!) that worked with the online app.

And then we had some software that we called a 'product' but was really being built for specific high value customers. For example, Texas might have some highly specific need and so we'd build a 'product' that we could sell to specific organizations in Texas.

And finally we had some pure contract software. Where we'd have a clear spec that had to be met for a specific customer.

We often had milestones as well, but what I meant is that they had to sign off on the features of that milestone in an all-or-nothing way. So if we were building features A-Z, the first milestone might be features A-D, and they'd have to sign off on those features before getting the first deliverable and before we'd work on the next things. Once they signed off on those they couldn't come back and demand we fix a bug with features A-D that existed in the first deliverable.

Of course, that was the legal position. But the actual way to make it work well is to have a good relationship (which certainly isn't always possible) so that you can horse trade and negotiate in good faith.

This is definitely true. And its why I'm happy to not be doing this type of work anymore. It's brutal. I think to make a successful business of it though you have to either build in enough margin for this up front or have them paying time & materials and you can actually build a more useful agile-like relationship with the customer.

It's nice to hear that because right now I'm splitting our company into 2 parts. The first is fixed-price projects, the second is time and materials retainer-based work.

Fixed-price projects are really great for a lot of reasons and help contribute to less process and overhead imo, and results in getting more done for less cost. Time and materials is good for ongoing type work with no definitive start and end.

You could say we are doing fixed-price for waterfall and time and materials for agile.

As an end-user of a few of pieces of software, I think you guys would be surprised to know how much filtering is done by the end-user before "bug reports" or "feature requests" are sent to the development company.

As an end-user, I have two widely different definitions of "bug" and "feature," where the former means we can't do our job, and the ladder is stuff that would be nice to have. The difference is sort of murky at times, but the main differentiator for me is "does this follow business logic?" And if the answer is "no," then I consider it a bug.

And example of a bug:

For various reasons, we would make mistakes when we shipped a product, but the most common reason is that the SKU that is bound to a product was incorrect. When we found the mistake on the product data, we would make the change and the change would propagate across the system, and would overwrite all of the meta data found in the sales history.

So, if a customer ordered a blue shirt and we sent a white shirt, the fact that we sold a white shirt would be shown in the system until we fixed the SKU so that it showed a blue shirt. Now, when customer service looked at the order in the system, it would show that we sent a blue shirt and not a white shirt.

I can imagine you know how many problems this created, but suffice to say that it took a lot of time to train everyone in the company how to work around this issue, we lost our sales history, and ruined our inventory counts.

It took a year to fix this issue, and the screwed up part is that the company didn't even tell us they fixed it, so we were doing things one way and now making a whole bunch of other mistakes because the ways we were doing things were adjusted to the initial issue.

So, assuming you are dealing with a client with one main point of contact, I'm pretty sure that main point of contact is sitting in an echo chamber of demands and filtering out what he or she feels is high priority. I know that I have at least 15 bug reports working, and I have a long list of other demands and bugs that either have to be worked on or totally ignored (Why doesn't this site work on my cell-phone? **** off).

The worst is when the company proudly creates a new "functionality" and it is utterly and stupendously wrong-headed. I feel like most SAAS, et.al, companies have a "know better than Thou" attitude towards the end-users, but to be honest, the companies really need to invest in someone who did the work they are purporting to help the end-users do. I've never once dealt with a company that has this person, and I find it rather disturbing and shocking.

That type of system wide change is unconscionable and clearly done by someone who fails to grasp the wider picture and probably shouldn't be able to release into prod.

Our model is that business logic comes first, and then the technology is molded to it.

I spoke to a former architect at a "competitor" after he had left and went to a prof services company and he was saying that his strategy was to look at the technological features of a product and then mold business logic to it. This guy had 15-20 years experience and I'm guessing none of it was in enterprise.

Good luck telling a fortune 500 that they need to change a single way they do business in order to use your technology. Unless it is something that is intended to change business processes by design, that is a losing proposition.

This makes sense. I think with 'good' customers you can still adopt a lot of the benefits of agile to a fixed-price contract (like I was mentioning before with trading things in and out of scope), but a '****ty' customer is going to be ****ty regardless of the process.

Dave, I've seen/heard about some companies that sell enterprise/niche software where I have no idea how they stay in business. Although I assume I'm missing something. Maybe that a lot of these are just so niche that its hard to get a good competitor?

I think having a 'domain expert' type person is good, but ideally (imo) you'd actually just have a good relationship with various customers and build most features in a very agile way and see how it goes. Obviously not practical for many systems, but totally reasonable for most people doing SaaS.

Amazon Web Services are actually incredible at this. They'll release a new product or feature that is so bare bones you can't believe they're releasing it. But some people will find it useful and over time it grows to be incredibly powerful.

My group project is a confirmed nightmare.

I brought up my ideas for being able to edit the labels on the buttons.. Titling it "changing menu items" or something and drew it out. Everyone really liked my idea but he freaked out and said no one knew anything about architecture and how it was way harder than we think to do something like that etc.

I told him allowing a user to change an arbitrary string value shouldn't affect the architecture of the program... Come to find out he intends to hardcode the buttons (with the text on them) as sprites. LOL god help us.

Basically told us to "let him deal with this stuff" so i guess i get to sit back and watch him struggle with **** that i could probably make a skeleton of in a few hours with java. Right on dude

Actually, if you don't architect it correctly you could do the thing daveT just explained where you order 5 "chicken salads" and then the user changes that label to "tuna salad" and orders 1, but running a report shows 6 tuna salads because of the change.

I could see in general how he is kinda correct that there are a lot more things to take into account, and thus a lot harder to accomplish.

That doesn't mean you are wrong tho, his solution sounds sloppy and lazy, whereas yours sounds like you might be underestimating the level of effort, but are going about it correctly.

Yea any feature added is gonna introduce a host of issues, my problem is more that he's keeping everyone out of the conversation.

He told me since i've only made applications with java that i dont know what a headache it would be on his platform.. My question is then, why the hell are we using your ****ty platform? It's used to develop games i guess.

The other thing that bugs me about his solution is that it's not really software that serves any kind of purpose other than getting a mediocre grade

Well, the one I'm talking about here is a niche product, but it has a lot of components that aren't particularly niche. For example, inventory and sales history. There is also a component of tracking distributors (B2B CRM, which is utterly unusable), multi-warehouse management (once again, utter failure), and various storefronts (ha!).

In this particular case, we are talking about products that are cheap and targeted to companies with a very small market potential (I'd guess 20M tops).

When I say companies need people who did the work companies are purporting to solve, I mean, don't make an inventory ERP system when your company has zero people who ever seen the inside of a warehouse, just stuff like that. The knowledge space it takes to automate things like counting inventory is surprisingly expansive, and integrating that with sales history adds more complexity to the issues. I'm not saying developers are not smart enough to figure it out, but when you are told "we did it like this because that's how the developers wanted it to work," that's not excusable.

I'm also pretty sure that, if some of these companies have any processes, it is not agile in the slightest. I also think it'd be very difficult for them to separate the signal from the noise without a domain expert, or at the very least a usability expert who goes to each company and watches how people work and listens to the end-user's frustrations. This, of course, would be far more expensive than just hiring a single domain expert who you trust to figure things out an prioritize, which is basically a mirror of the point of contact at the company.

Some products are so terrible I don't even understand who they are trying to sell to, and I'm simply shocked that anyone would try their system at all. It is one thing if the system is slow since I'm sure that, after a few new customers, they can hire a language expert to come in and fix up the issues, but...

So, one company contacted us for inventory and warehouse management. After promising the moon they gave us a demo. The UI demo was "Can we do this?" No. "What about this?" No - but we'll have this feature soon and this other feature you will just love is coming down the pipeline.

Fine, whatever, how does it work? I'm sorry, did you just tell me I have to supply each picker, packer, QC, and forklift driver with a Chromebook and they have to scan every single item they touch? What are we going to do, attach a computer to their foreheads? What happens if the barcode doesn't scan or the product doesn't have a barcode? "What? What products don't have barcodes?" Is that a joke question?

At the end of the day, I think many end-users, especially companies that have no focus on technology or numbers, just figure something is better than nothing, but I disagree with this sentiment. I suspect many products companies buy would be better done with a collection of Excel sheets and a few formulas. This isn't measuring convenience; it is measuring the sunk-loss and hedging negative numbers.

Right, but I'd call AWS domain experts. They are backing one of the largest sites in the world.

But yes, I would love to work with a company that releases betas, gets feedback, then iterates. That would be pretty cool.

What makes him an expert on architecture? Why wouldn't you guys just do what every other site does? Preview the order, press "x" if you don't want it, drop down list to change quantity, etc?

Waterfall with points. That's what we do. But we're agile because we have Kafka-esque 2-hour meetings about what points mean.

Hours? No can't translate points to hours. Great. What's 3 points? It's less than 5 points. Ok what's that? More than 3 points.

Ok any more questions? Good. What's our velocity?

FU - that's our velocity.

Please upload your 300-400 page document to Dropbox when done so we can all enjoy it.