The Old Joel on Software Forum: Part 4 (of 5) - Is it ignorance or reality: blueprints

Is it ignorance or reality: blueprints

The website I work on is going to be ... heck, no one even agrees on the term, it will be described. I would say that it is getting a blueprint. We will recreate it in another language and it is so huge and been around for a few years so no one really knows all the functions it provides. My first thought is "someone else has done this before" see what they did. Find best practices. See if there are any exisiting methods/standards for doing this. But instead each of the people involved in doing this is just arbitrarily doing it how they think it should be done. I'm a bit flabbergasted but then I'm just a programmer.

Am I unrealistic? Maybe it is fine for each person to just populate an excel spreadsheet entering what they think is pertinent.

Given the last few threads ... maybe I'm incompetent and stupid but don't recognize it.

I'm thinking ... would UML help with this? Also, I think that whatever data they collect ought to be put in a format that can be repurposed and they are creating spreadsheets more like word docs than anything else.

trying to reinvent the wheel
Tuesday, April 20, 2004

I can't say that I've ever used the technique, but it sounds like you are "refactoring".

http://c2.com/cgi/wiki?WhatIsRefactoring

Tom H
Tuesday, April 20, 2004

Actually, it seems to me that he is "requirements gathering".

Kudos to Mr. Wheel for not succumbing to the Not Invented Here syndrome. You and your project still have the smell of doom, though.

Alyosha`
Tuesday, April 20, 2004

I find UML-like process diagrams to be extremely helpful in specifying web apps.

Egor
Tuesday, April 20, 2004

I would second the "it is requirements gathering" and not the "this is refactoring crowd"

A simple spreasheet, or databases would record use cases.

1. who am I (role more than internal moniker)
2. what am I trying to achieve (final output)
3. this is how I currently do it.

that's it.

More fields that can be added include, why do I this, how often do I do this etc.

When you have a substantial number of these, you have your requirements, and you can also start questioning the cargo cults, and refactoring the requirements into common themes and tasks.

Tapiwa
Tuesday, April 20, 2004

Thanks for the good comments. It is more like requirements gathering except the actual requirements are embedded in the code. But refactoring is close as we will be major MAJOR (I hope) changes in the architecture. What we are doing is going over the site to describe what the site does at a fairly high level. But .. each person doing that is following their own preferred method based on what they think is important. And these "pages" are fairly complex in that they call and include a lot of other "pages/applications". It's a bit of a mess.

It just so happened that one person doing this asked me a question and while answering she showed me what she was doing. I asked her why she was doing it like she was and that started a ball rolling and suddenly I'm the bad guy.

I'd like a system that could be validated. Like my program. It runs or it doesn't; this can be tested. Whether it does what it should or does it well is another question. But there does not seem to be ANY kind of validation before programming begins. Not that I know of. Where I've always worked the glib was king. I'd like to see a use case and say "yes ... this adheres to the use case specification BECAUSE a and b and c ..." otherwise imho I think it's just an ad hoc system with flint from software engineering marketing spiels.

Thanks for the responses so far.

trying to reinvent the wheel
Wednesday, April 21, 2004

Going through the last years access logs for the site might reveal what it is really used for.

Just me (Sir to you)
Wednesday, April 21, 2004

In short:

Your job is to analyze a pile of horseshit and reconstruct an identical pile, but this time only using cowshit.

Ah ... the fragrant smell of doom!

Alyosha`
Wednesday, April 21, 2004

> I can't say that I've ever used the technique, but it sounds like you are "refactoring".

Reimplementing in another language is usually not refactoring: "Refactoring is typically done in small steps..."

You might find http://discuss.fogcreek.com/newyork/default.asp?cmd=show&ixPost=4689 interesting.

Christopher Wells
Wednesday, April 21, 2004

horsehist to cowshit was a good one. Hopefully, once we identify what we have to reproduce, we will reproduce it differently.

trying to reinvent the wheel
Wednesday, April 21, 2004

Sounds like the perfect scenario for a new "Camel" type soap blog. Go for it. The main upside is that after your layoff you will get to work for a company that cares about devs.

Just me (Sir to you)
Thursday, April 22, 2004