Re: Delphi makes it to digg!

Chris Pattinson (CodeGear) wrote:
m. Th. wrote:

Thats a nice site. I've actually done several formal QA classes
(have a BS in IT focusing on Project Management and Software
Testing :P ) I'll go through it in more detail and see if there are
any gems I should add to my references.
Hah! Son, take care of your crown! If you put to many gems in it, it
will be to heavy for your head to carry! :-)

Touche! Mainly I'm interested in the pursuit of knowledge. A course is
a start, it certainly doesn't teach everything. Nice to have an
opportunity to both learn and apply skills, and try to make educated
decisions/changes aware of the consequences and risks.


Yeah, also I find this dialogue quite useful. OTOH, do you are aware of...

http://www.codinghorror.com/blog/archives/000895.html

OTOH, yes, imho, in the state in which CG is now, Project Management
it's a crucial skill. Perhaps, that's why I found myself citing here
so many times from Steve McConnell's books.

Steve McConnell is one of my favorite authors. Another of my favorites
is Edward Kit, for example the book 'Software Testing in the Real
World- Improving the Process'. The aspect I found most useful from both
is how in every stage of a project, you verify and validate the
results. This 'keeps the kitchen clean'. Changing development culture
from old waterfall thinking to this 'take a few steps and revisit' is
where software development companies encounter a lot of resistance.


About 'kitchen clean': http://en.wikipedia.org/wiki/Cleanroom_Software_Engineering
....which have some things which definitely we must borrow in our agile based methodology. Imho, the base is the agility, today, the most determinant factor in our industry is minimizing the response time at user's request - ie. how quick and exact the IT ecosystem follows - as a 'shadow' - the ever-changing user's needs. I see today the programmer rather like a doctor, curator, social assistant in helping the user in his pains rather than a mathematician in his cubicle trying to implement a certain algorithm dictated by theory.

About 'waterfall thinking' -> 'take a few steps and revisit':
1. The waterfall model throws in fact away the user for the entire development period thus maximizing the possibility that the final result will not be conform with user expectations. We have here the (un)famous "Nothing new since Delphi 7" - the users, in fact expressed their _perception_ about the things which it must have been inside according to _their_ judgment which, of course, prevails. For ex. in my case (exaggerating a bit) "nothing new in database area since Delphi 7". Why? Because I don't use DBX as connectivity layer. To be sincere in my heart I _must_ say that what Steve (Saughnessy) and his team did with DBX4 is a _really_ good thing - but I think that you got the idea.
2. A big bug-fixing stage at the end. Who thinks that he (or she) can cope with this on a project like Delphi, the solution is very very very simple: Leave immediately any development activity, go at http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF
print it, take a good relief and a walk (payed by company, why not? - I'm sure that the ROI will be very high) and read as many times as is needed until he (or she) understands what that man tried to write down there. And perhaps is good to take in account that that man influenced the IT history _way_ more that me and you will have the chance to do it. (Just my 2c.)
3. 'Paralysis by over-analysis' - I'm sure that you know what I mean...

http://www.stevemcconnell.com/rdenum.htm

Fantastic link. The summary at the end helps organize the 'classic
mistakes'. It always amazes me how often you find yourself doing the
same mistakes, though you clearly identify them and as a team declare
the intent to never repeat them.


Hummm.... perhaps you're man?... :-)

(OTOH, I'm glad that it helped you)

Here it will help you to do every day with your team a day analysis what was bad and good in that day. 10-15 minutes. Nothing denigrative. You know, unite like a team. In fact, we all are just men. Also, this is good to be done by everyone alone and also as a team. And try to eradicate them little by little, it's much more effective than an axe hit.

http://blogs.construx.com/blogs/stevemcc/archive/2007/06/15/Classic-Mi
stakes-Updated.aspx

Might be useful to add my set of learned classic mistakes, especially
from the Agile perspective. (We do a post-mortem after every project is
completed).


Yes, that's good but also it must happen at shorter intervals (well, I don't know how big your projects are in time span speaking) but reviewing 10-15 mins every day (as I stated above) it will help you very much.

Before Nick joined us, for example, we had no clear product owner. So
development had unclear direction. Developers did not have a sounding
board to bounce off features or priorities of work, and it was harder
to stay in touch with the community.


Yes, the manager is crucial. That's why the _obedience_ is the base of anything. To an obedient man, even if, perhaps, he don't have the skills which you expected to have, you'll find his place in which he will fit, it's a matter of time, of course, but all the things are peaceful, in a way, even he does some 'unwanted things'. We have a fellow here which has an extraordinary 'talent' in damaging things: hard-disks, devices, cards, glasses - everything. But he has a very good heart and he really want to help. After a period of findings, we found the sollution: beta/usability tester. If one of our programs has a weakpoint he WILL find it. But, OTOH, I cannot express you how painful is to have a even skilled man which disobeys (almost) continuously. It's a continuous war - a tension which tires both you and the team. It's really _very_ hard to cope with him. His work doesn't fit in the global architecture of the product (and here I don't mean code only). And in extreme cases, his work must be redone by the team. You know, good men make a good team making a good product. Saying big-headed men make a big-headed team making a big-headed product it really sounds very 'odd' to my ears, don't you think?...
Also, see on 'big-headed' programs http://en.wikipedia.org/wiki/Big_ball_of_mud

So this brings up another interesting point - talking about SOLUTIONS
to the classic mistakes. To be fair, I can find a few dozen articles
and write-ups, that make us feel good about knowing what problems are
common in software development, it's less rare to find a good article
that describes solutions and success stories. Do you have any favorite
references in that regard?


SOLUTIONS - because you asked me generally I will try to answer you generally. If you'll be more specific perhaps I could give a humble try to answer more specific. :)
But don't put many hopes... :-)

First of all, the general solution:

http://info.computer.org/portal/site/computer/menuitem.eb7d70008ce52e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1&path=computer/homepage/misc/Brooks&file=index.xml&xsl=article.xsl&;jsessionid=GjQzTWMYLlTgq14m1wvG87Sf8n2DL0ZFgmWlQzKW6TJ5v8XXLSWJ!953701857

(it's a quite long link. It's the famous Fred Brook's 'No silver bullet')

Perhaps this will help you as a starting point (the link is at the bottom of the page):
http://en.wikipedia.org/wiki/No_silver_bullet
(Also the entire book 'The Mythical Man-Month' is one of the best books in the area)

Another one is the Dijkstra's landmark paper 'The Humble Programmer' - referenced above, I will post again the link:
http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF

....also perhaps it's interesting a quick look at
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html

....from where the general 'solution' is completing our incapacity as programmers with the user's way of thinking. We cannot really imagine what are the users expectations. That's why we must put the users in the middle of our efforts. See my other post.
Just to add one _very_ important thing here: While the users are very good in 'feeling' their needs they are bad (sometimes awful) with their solutions. That's why you must make the effort of extracting their human problem which lies under their solution. This doesn't mean that their solutions are always bad, but don't ever trust the users. Love them, help them as much as you can, but don't trust them as solution providers. And if you cannot help a certain group of users, well, that's it, drop them as kindly as you can, and focus on that group where you can help them more.

...and another 50% is 'prevention' (which then makes a total of 150%,
pretty good, imho 8-) ).

[...]

Sounds like a good feature request, do you have a QC number for it ? :)


At your orders! #49472, #49473, #49474 (the last one is a bonus... :-))

--

m. th.
.

Relevant Pages

  • Re: VARY too many devices offline
    ... How would you handle a person that scrutinizes blood for a living and mistakes a diagnosis? ... Its possible that a programmer could write a program that misdiagnoses a test result and yes that could lead to the persons death, but presumably there are other fingers in the stew to catch the errors. ... I would suggest an incorrect VARY command might cause some amount of grief but not enough get fired over. ... That is almost as bad as saying your fired as you don't trust your operators so I am going to attempt to intercept commands and double check them. ...
    (bit.listserv.ibm-main)
  • Re: Should this be an object?
    ... Objects exist to help a programmer organize his code more ... repair mistakes if a mistake is made. ... colaboration of various types of objects through well-defined interfaces. ... mechanisms are at one's disposal - Abstraction, encapsulation, polymorphism, ...
    (microsoft.public.vb.general.discussion)
  • Re: OT: Programming in C
    ... I am looking for a couple of good books on learning C. ... at the advanced programmer with that one. ... have to design the data structures, and C++ is object oriented, so while ... car might be car.turnin object code. ...
    (Fedora)
  • Re: Question about fair wage for a machine operator.
    ... Not a programmer or a machinist, but a sharp ... fellow who is always at work on time, makes few mistakes and can be ...
    (alt.machines.cnc)
  • Re: Good reference manual?
    ... learned that it's based on the WAMP stack. ... simpler for the programmer), so I'm not claiming to be brilliant. ... and I really don't have the money to get separate advanced books on ... Moo moo moo ...
    (comp.lang.php)