3

The title might be seem vague, so let me tell you a little bit history what i am trying to clarify question.

I have been hired as a consultant for a corporate's small development division. The company also owns a couple of software development companies. My ex-manager runs a BI team, with reports, analyst and developers. He asked me to evaluate overall design, software development process and code quality.

Here what I found:

  • Lots of copy/paste code everywhere ( no reuse ).
  • Even though they have everything TFS, VS Ultimate etc, they have no build process.
  • No Cruise Control.net / Teamcity...
  • No unit tests.
  • Web Pages with 3700 lines of code, Lots of huge functions ( which can be divided into smaller functions).
  • No naming convention both db and c# code
  • No 3rd party or open source projects.
  • No IoC.
  • No Separation Of Concerns.
  • No Code Quality Check ( NDepend or FxCope or anything ).
  • No Code Review.
  • No communication within the team.
  • They claim they wrote an application framework ( 6 months, 3 persons), but I would hardly call a framework ( of course no unit test, there are some but all commented out). The framework contains 14 projects, but there are some projects with only one file with twenty lines of code.

Honestly, what people are doing fixing bug all the day( which will provide more bugs eventually), they are kind of isolated from community, some team members even don't know github or stack Overflow they probably went there with google but they don't know about it.

So here is question, Is This list ok? Or am I being picky? Since I don't have any grudge against them, I just want to be fair, honest and I would like to hear you suggestions, before I would submit this list.

And since this list also will be review by software division's manager, I don't want any heart break or something like this. http://www.hanselman.com/altnetgeekcode/ For example I would love to such lists, I can't make references.

Here what I think after this question

Since sorf of list wanted I will submit it. But I will definetly reference this question and great answers to make my intention clear ( I dont want to be picky a***e, I respect what they do, but I believe they can do better) . I will recommend them to take it slowly, use their time wisely, and if they let me I will try to investigate the real problem and try to solve it with them. Not as an enemy or a person who didnt like what they do, as a friend, a person who likes building things.

|improve this question
  • Have they been asked to do any of the things on that list? Have they been given autonomy over their environment and techniques? Or have they been given a specific job to perform and a limited deadline? Are they now being asked to tidy up the code? Or are they being asked to fix the bugs? You can't blame the development team for doing as they're told, unless they're being trusted to make certain decisions for themselves. – pdr Oct 31 '12 at 20:48
  • 1
    Have you heard of "Capability Maturity Model"? en.wikipedia.org/wiki/Capability_Maturity_Model Whatever answer I give you here is unlikely to help as I know nothing about your organisation. Please read linked article as it'll give you an idea of where you are now regarding your processes and where you would like to be. Our team has been at it for over a year and we are still somewhere between Level 2 and Level 3. – CodeART Oct 31 '12 at 20:55
  • @pdr The last thing I want to do blame people, this is the main reason i am asking the question. The BI team's head is not a develope backgroun guy, He just think something is not quite right with the team. because they are not being productive at all. Nobody is saying the team "dont use any tools, will make your coding easy" or nobody interfering how do they code, what do thay do. – adt Oct 31 '12 at 20:56
  • @CodeWorks I heard about CMMI, thanks I will look it again. – adt Oct 31 '12 at 20:58
  • 1
    The Joel Test can also help in evaluating the aspects not related to source code: joelonsoftware.com/articles/fog0000000043.html – Ilmo Euro Nov 1 '12 at 8:04
7

Start by being constructive and look for things they are doing right. If you don't you are going to make enemies and you job will be very hard. Make friends, find out what they want, what will motivate (and demotivate) them, before talking metrics.

Have you even tried to find out why they do what they are doing?

This is most likely a people problem - lack of teamwork, lack of leadership, wrong focus (bug fix over bug prevention) etc. There may be a lack of ability, skills, training etc, but in my experience that is a symptom, not a route cause.

One word of caution about metrics: Be very careful what you measure. What you measure becomes all important. What you don't measure becomes unimportant. If you measure the wrong things, you drive towards the wrong results.

Edit - This question might be helpful - although closed as Of Topic for Programmers its almost certainly relevant to your situation. Particularly read the works of Steve McConnel.

|improve this answer
  • 2
    very wise answer indeed, I havent done such a thing till now, Judging other people, how do they do and why. I dont want to break any person, dont want to be the bad guy, that makes me a little bit anxious. I just want to be helpful if i can. I would made #lack of leadership# bold. – adt Oct 31 '12 at 21:05
  • +1 A lot of the trendy practices and tools work great, but there a lot of software shops that were effective and efficient in their own right before such practices and tools came to be. Remove the personal bias first; then observe, measure, and survey; finally make a recommendation. – JustinC Nov 1 '12 at 2:00
3

I totally agree with the points that mattnz makes and offer this aside.

I have seen this a lot. the Prototype Model becomes the Production Model.

Time and time again a "Proof of Concept" gets whipped up in a frenzy to get buy in from certain people and then... someone decides to put the "PoC" into production because a potential customer saw it an offered to buy it today. Then the next day three customers say they want it and the day after, seven customers say they want to buy it.

Once it's sold, you have to deliver and the focus is shifted from building a real scalable application to rolling out features that are on high demand because the PoC didn't include them.

Get some history on the evolution of the system before making recommendations.

|improve this answer
2

Don't confuse symptomatic concerns based on personal bias (preference) with big picture problems.

  • Are they shipping software?

If they are shipping software, there are some things in their process that are working. If they are aren't, then work on who, why, how, and when they can get on a release schedule they can meet.

  • For the software they are shipping, are the sponsers/customers/users generally happy with it? Are they creating mutual value for both their employer and the customer? Are the things the customer needs being built? Is what is being delivered honestly making the sponser/customer/user job easier, or is it another layer of complication or difficulty?

Everything will have bugs. 'Bug Free' is some ideal that really only applies to software of very limited complexity, with a very static environment. It is something to aim for, but sometimes certain bugs are just not worth investing in. Simply because no one has identified a bug in 'bug free' software doesnt mean it's not there, it simply means it hasn't surfaced or been reported. Additionally, it is ok to occassionally say no to the customer, especially when it is a pie-in-the-sky feature that needlessly pushes the release and ship dates: deliver the things that are fixed, or fixable, and defer the others till another ship date when there is time to do those other things. Worry about it later, as later may never come: you may never have to fix or add that feature.

|improve this answer
0

Several years ago I heard a definition for consultant as:

A guy who can tell you a thousand ways to make love to a woman, but can't get a date.

I think you don't have to be that guy, provided you have the hands-on skills to go down the list you made here and decide which you will solve through doing once or multiple times for the customer, by training that you provide or purchase for the staff, and by staff changes that you recommend and help execute.

Perhaps you can ask to not be a consultant, but to instead be an interim manager for software. You will want and need decision authority over policy, and will need to act directly, not from a distance to make the needed changes. I think Machiavelli advised that when the Prince conquerors a city, he must go and live there to exert his ruling power. I believe if you want to make lasting changes, there is no other way than to go there and direct the change you advocate.

Your list seems pretty sound, but can be augmented. Follow the money! Start with the customer, learn how features, prices, and payments work between the company and its clients. Evaluate requirements management, estimation, integrated planning and tracking, and quality. As with SEI CMM, it is good to start with management where the highest leverage changes will occur, then work your way down to the developers. Scrum and agile methods are great, but there is a significant selling task at every step to keep executives, managers, and professionals on task making the changes that will fix the problems.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.