Development approach definition

When it comes to developing the software, one thing, which is, most of the time, neglected, is the approach.
Often it happens that if people are not correct in the approach that they're following, might fall prey to some "unplanned" hazards.

According to you, what is the best approach to be followed for development?

 

I think the best approach is outline what are your goals developing a project and make them clear to those who want to join, opening also a communication channel used exclusively for feedback, suggestions and questions so anyone can participate, modify or add, but without losing focus on the main goal.

 

As the leader, plan for your project to take twice as long as it was planned and plan for it to cost double as much as it was budgeted. Then tell your team it should cost half as much and take half as much time as they intended.

In the end, you might have a decent project.

Hehehe.....that was a joke of course.

Scott

 

My experience tells me that Communication between the Leader and the Client is of utmost importance and an equal importance goes to Documenting the needs of the client. Most of the projects fail because they lack understanding the needs of the client and planning out how to meet them.

Documentations importance has been felt many times and faulty documentation and communications have led to several projects failing, delays in delivery and enhanced costs for the organization where I worked. Today, I am a freelance developer and as such I get the better scope to discuss the requirements and document them so that I and my team deliver better.

 

So, according to you, the leader is a Project Manager, Tech Lead or the Business Analyst?
I think, business analyst jots down the requirements in the very beginning, so he is the right person to communicate and document the things?

 

Locking the client in a closet and not letting them change anything.

Seriously, though, I see a couple things neglected constantly by the development team I work with, and it irritates me.

Comments in the code. This is horrible. My team is literally the only people who can understand this code, and our head developer (also my boss) will not do anything about it. No standards for commenting, just a big pile of spaghetti.

Documentation. We deal with some pretty complicated things, with even more complicated interactions. We have three potential ways to document them: 1. Document them as we go, because we are knee deep in the logic and we understand it clearly. 2. Document as things are completed and tested, so documentation is consistent with our releases. Or 3. Document after everything has been in production for months and customers complain. We almost always go with 3, because why waste money on documentation that nobody is going to read (despite the fact that they do read it when we do have it).

Long-term planning. This is what causes spaghetti code. For example, instead of taking 10 minutes to figure out that having a page with a variable number of links depending on the user's security level should not be hard coded, you take those ten minutes throwing together a convoluted series of if statements that cover all eventualities and make the page display properly. In the future, we remove one link, which leave a big hole in the list, and we have to recode the whole thing the way it should have been done in the first place.

Sorry if those are bad examples, but they are ones that have irritated me today.

 

What language are you coding in?

Oh, and how about documenting before you even start? And update that documentation as things progress and finally finish it up for consumption purposes by the user, once the project is done?

I agree, documentation is terribly important for the success of any complicated project.

Scott

 

If I could redo the whole process we use we would be designing test cases, creating documentation from those test cases and how it should work, and doing more design work on the front end before anyone touches code.

As it is, we do none of that. We get requirements from the client, hand those requirements verbatim to whoever works on it (sometimes this is our India team who barely have a handle on English) and wait to see what comes out. Now our US guys are good enough to ask questions and do things that make sense from a continuing development perspective, but the India team not so much. I really think they are only interested in making our code as spaghetti as possible so only they can understand it (job security).

We primarily code in asp classic and vbscript (as well as javascript, jquery, HTML, etc). We are moving over the C# (thank god), but most of our application is in vbscript.

vbscript with no comments is hell.

 

Isn't vbscript sort of like....old fashioned? I guess that is why you are happy you are moving to C#. Ever do any work with PHP?

Scott

 

In school. I'm actually finishing up in March, and hopefully moving on to a different job or getting brought on permanently with my current employer. I like the US people I work with, but I worry that the shop is so small that they couldn't afford to bring me in permanently, and if they did the salary wouldn't be competitive.

I would massively prefer our site being in php to vbscript. vbscript is indeed an old language. I would be happier with the C# transition if I was doing anything but first tier support, testing, and documentation (all three of which keep me very busy).

I am glad to have experience while still in school but I'd rather my experience be in a relevant language than one nobody will use.

 

Are you not also American?

Scott

 

No, I am American, I just work with a team of half US developers and half Indian developers. I don't much care for the India team, as they do the bare minimum they can and aren't forward thinking in their code.

 

Hmmm......Outsourcing ey? How hard is it to collaborate with them? I mean, do issues arise due to time zone difference, language, culture, etc?

Scott

 

I'm of two minds about them really.

On one hand, had they not been a part of the development of this application, the company I work for would have been out of business many years ago. On the other hand, they don't communicate well at all, and we have to go back and forth constantly to get anything done.

The problem is English is very obviously not their first language, and they are not very proficient with its usage. It is difficult if not impossible to get it right on the first try with them, no matter how specific you are (I've done just about everything I can think of to communicate with them, including pictures). I really wish we didn't outsource those jobs to India, but like I said, without them, this company would not exist.

 

Even with the waste you have with communication and not ever getting it right the first time, their work is still so cheap it saves money?

Scott

 

I don't know much about their financials, but I would assume so if our CEO hasn't gotten rid of them yet. That said, it would take us a couple years to completely unravel their code and turn it into something that we can understand. I've been brought on in the last year, and our entire US team (except our office manager/lead developer) is less than 3 years with the company. With the company being 15 years old and having no US developers except the office manager and CEO, I don't think I need to say much more about why our code is in the state it is.

The real funny thing is that our India team is supposedly really good at .NET. Considering they code VBScript in the most convoluted and non-OO way possible (going out of the way to not define functions or classes and using complex bits of code they copy and paste from place to place instead of defining it in a function). I don't know how you can be good at .NET, but horrible and OO programming.

 

That is some interesting insights you are posting.

I myself, don't believe in outsourcing. I would bet money, the problems the outsourcing causes cost just as much, if not more, than if in-country engineers would be used.

We have sort of the same issue, but with weldments coming from Poland and Hungary (I live in Germany). There is so much rework needed to be done. so much "quality checking" constantly going on (which doesn't help the quality much) and the shipping costs for the weldments just can't figure in as a savings overall. The only thing that is saved is production capacity and it really isn't saved, it is just spread out over two more smaller factories, so theoretically, it means more can be produced. But, we aren't in any need of that extra capacity currently. No one wants to make the decision to stop that outsourcing though. Oh well.

Scott

 

Most likely that is because the rework costs aren't realized as true costs. In some meeting somewhere you have a bunch of important people calculating that product X costs Y Euros to produce and ship in Poland, while it would cost 50% more to produce in Germany. They don't see that you have a 60% increase in costs because of rework and problems.

There is also a problem sometimes of the costs of retooling. For example, let's say it will cost 100,000 Euros to move production from Poland to Germany, but would save 5,000 Euros a month. Well, that's a ROI of 20 months. Good businessmen think that far ahead, but most businessmen thing 3 months ahead (if that). They want to get to their next quarter stockholder meeting without dumping 100,000 Euros on a move that won't have a profit realized for 2 years. This is the same reason that governments in the US sell their buildings only to lease the same building, making a short term profit to tidy up their books, but costing themselves more in the long run.

 

Yep, we think alike.

Scott

 

The costs of 1st country developers vs 2nd or 3rd country developers can be factor 3-10. It's not uncommon for a educated European developer to charge 70-95 euro. In many cases the 1st world developer is not that good, motivated or is difficult to work with for most managers. Exporting the headache sounds very attractive from that perspective. If you are subcontracting then chances are high that work secretly gets outsourced or locally sub-subcontracted, which can often lead to communication issues which mess up a whole project.
So unless you have a good team of developers that you can 'read and write with' and they do not get rockstar wages, then there is something to be said for outsourcing to a good company. Personally, I prefer to work with specific talented developers and PSD-html coders that I have good communication with and a trusting(in most cases) business relation has been build with.

The welding example is illustrative of the work of some developers.For example: I have one Russian PSD-html coder who is lightning fast to implement whatever we list, but there are always quite a few details that he misses. I solved this by adding a Dutch Q&A staff to first review his work and create a new list of style fixes. The combination of the Russian coder with a Dutch Q&A is still much cheaper and faster than a Dutch PSD-html coder.

I also like to work with talented expats in 2nd or 3rd world countries.
Projects completely developed in Europe tend to quickly grow into 5 figures. And unless I personally manage them or have a very good manager on them there is significant chance of failure.