Staredit Network > Forums > Lite Discussion > Topic: How quick can programmers program?
How quick can programmers program?
Jul 24 2016, 1:45 pm
By: TiKels  

Jul 24 2016, 1:45 pm TiKels Post #1



As many of you know, this summer I have traveled to México to learn about culture, language, and engineering. As part of my study abroad/internship I was put on a programming team and assigned a project to develop a software tool. This tool was intended to communicate with standard car radios.

The three of us were given 8 five day weeks, 8 hours a day, to do absolutely everything. Learn the excel sheet format for the different radio models commands, design a program to retrieve that data, design a database to store the data, create a friendly user interface, design a program to turn the data into encoded messages of standardized format for the serial radio communication, etc etc ad nauseum.

Or supervisor said such a tool would require around five months to properly design. It took us seven weeks and we weren't that serious.

How long do you think such a project would take? Is five months absolutely outrageous? Why?

Also: has anyone else been to México?



"If a topic that clearly interest noone needs to be closed to underline the "we don't want this here" message, is up to debate."

-NudeRaider

Jul 24 2016, 3:03 pm lil-Inferno Post #2

Just here for the pie

A decent programmer can program quickly and efficiently, getting the job done well ahead of budgeted time.

A really good programmer programs slowly for job security.




Jul 24 2016, 3:49 pm Corbo Post #3

ALL PRAISE YOUR SUPREME LORD CORBO

But did you use tabs or spaces? You probably used oop too. :mad:

I have been to mexico.




Jul 24 2016, 6:42 pm Roy Post #4

An artist's depiction of an Extended Unit Death

Quote from TiKels
Or supervisor said such a tool would require around five months to properly design. It took us seven weeks and we weren't that serious.
You're both right. If you throw design out the window, you can get a lot accomplished in less time, which is an appealing approach if the code is not expected to be regularly updated or maintained. In fact, the upfront cost of properly designing a project with a tight deadline is foolhardy in this scenario, and moving those costs to potential refactor work in the future to get a deliverable out as soon as possible is one of the principles behind agile methodologies.

As a programmer, you program as fast as the deadline dictates. The quality of your work is what is impacted.




Jul 24 2016, 8:33 pm Lanthanide Post #5



In my last project at work, about 70% of the effort went into handling error cases that we didn't expect would occur to customers, but to make a robust commercial product, had to be done.

Theres a big difference between writing software, and writing commercial software that you expect people to pay for.



None.

Jul 25 2016, 10:38 am TiKels Post #6



Quote from Roy
Quote from TiKels
Or supervisor said such a tool would require around five months to properly design. It took us seven weeks and we weren't that serious.
You're both right. If you throw design out the window, you can get a lot accomplished in less time, which is an appealing approach if the code is not expected to be regularly updated or maintained. In fact, the upfront cost of properly designing a project with a tight deadline is foolhardy in this scenario, and moving those costs to potential refactor work in the future to get a deliverable out as soon as possible is one of the principles behind agile methodologies.

As a programmer, you program as fast as the deadline dictates. The quality of your work is what is impacted.

I didn't think about it but the AGILE method was explicitly mentioned as a standard method. However, it was definitely expected that code be able to be reused later. I would say we attempted to make the code as readable as possible and had to make the design "abstract"



"If a topic that clearly interest noone needs to be closed to underline the "we don't want this here" message, is up to debate."

-NudeRaider

Jul 25 2016, 4:24 pm Vrael Post #7



Provide a metric and perhaps we can even begin to answer your question. Otherwise, I'll just answer "Programmers can program at 12 goolak's per day."

In a more qualitative sense however, I think Roy and Lathanide have the gist of it. Programmers program fast when they have tighter deadlines, at the expense (sometimes) of quality. Also, the nature of the work has a huge effect on things. Lanthanide's 70% overhead figure is not unrealistic at all. Sometimes overhead tasks like testing and stuff can literally take up over 90% of the task time.



None.

Jul 25 2016, 4:39 pm Roy Post #8

An artist's depiction of an Extended Unit Death

Quote from TiKels
I didn't think about it but the AGILE method was explicitly mentioned as a standard method. However, it was definitely expected that code be able to be reused later. I would say we attempted to make the code as readable as possible and had to make the design "abstract"
Did you follow any particular methodology? The agile development process itself is not a methodology, though there are agile methodologies (such as Scrum). If by "reused" you mean "copied/pasted/tweaked", then yes, basically anything you write can be considered as such, but that's not what developers usually mean by the word. "Abstract" is also quite vague, and pointless abstractions are just making the code messier.

Given your description, I find it hard to imagine the code is anything more than sloppily hacked together—which is perfectly fine given the constraints of the request—to get it all accomplished in seven weeks. Here are a few questions that would confirm or deny it:
  • How many unit/integration tests did you write?
  • What database did you decide on, and how did you design your data access layer?
  • Did you put your parser in its own library?
  • Do your methods/functions follow the Single Responsibility Principle?
  • Do you have to update the parser logic if the excel document changes (e.g., adds/removes columns)?
  • How does the program that encodes messages know the serial radio format? Is it hardcoded, or does it retrieve it from the database or config?
  • Do you even have any configuration files? What can be configured?
  • Why is the encoder a program and not a library? Do you have to pipe the results of your parser to your encoder?
  • If you broke out any of your work into libraries, what does their API look like? Did you write any documentation?
  • What architectural design did you use when you wrote your UI? Did you use a framework?
  • If the format of the excel document and the way you need to encode messages changes completely, do you need to update your UI application?
  • How modular is your application? Do you have an IoC container / use dependency injection?
  • How much error handling do you have? What happens if the parsed file is malformed? What happens if the application cannot communicate with the database?

My guess is that many of these questions are going to have negative answers (such as "We have no tests and only tested it manually") because you simply weren't given the time to build something flexible and stable.

I'll also guess that some of your answers are more reasonable (such as "The encoding rules are government-regulated, and it would be a waste of time to engineer a configurable way to encode messages considering they will likely never change").

Post has been edited 2 time(s), last time on Jul 25 2016, 4:45 pm by Roy.




Jul 25 2016, 6:04 pm CecilSunkure Post #9



In my experience it's very difficult to scope a project well. It's hard to spend time on what's important and easy to burn time on things that don't matter much. The more people involved the more bureaucratic and lagged the process becomes. You guys probably finished quickly by keeping a small scope and keeping the working team tiny.

If more features, more testing, or more of whatever else is decidedly important then development time can skyrocket to the moon and back.



None.

Jul 26 2016, 1:02 am TiKels Post #10



Quote from Roy
  • How many unit/integration tests did you write?
  • What database did you decide on, and how did you design your data access layer?
  • Did you put your parser in its own library?
None the program is for in house use only, I didn't design the database, don't understand what you mean by parser.
Quote
  • Do your methods/functions follow the Single Responsibility Principle?
  • Do you have to update the parser logic if the excel document changes (e.g., adds/removes columns)?
  • How does the program that encodes messages know the serial radio format? Is it hardcoded, or does it retrieve it from the database or config?
  • I think? No. It's too confidential to store like that, hardcoded.
    Quote
  • Do you even have any configuration files? What can be configured?
  • Why is the encoder a program and not a library? Do you have to pipe the results of your parser to your encoder?
  • If you broke out any of your work into libraries, what does their API look like? Did you write any documentation?
  • They are in libraries. Confidential. Documentation is being written this week.
    Quote
  • What architectural design did you use when you wrote your UI? Did you use a framework?
  • If the format of the excel document and the way you need to encode messages changes completely, do you need to update your UI application?
  • How modular is your application? Do you have an IoC container / use dependency injection?
    I read a lot of principles of design stuff, paid close attention to usability and aesthetics, and iterated.

    Changes COMPLETELY? Yes, clearly.

    Don't know those words.
  • Quote
  • How much error handling do you have? What happens if the parsed file is malformed? What happens if the application cannot communicate with the database?
  • All handled. The only thing we didn't handle was if the end user (an engineer) replaces system files with renamed junk files. We cut the line there.
    Quote

    My guess is that many of these questions are going to have negative answers (such as "We have no tests and only tested it manually") because you simply weren't given the time to build something flexible and stable.

    I'll also guess that some of your answers are more reasonable (such as "The encoding rules are government-regulated, and it would be a waste of time to engineer a configurable way to encode messages considering they will likely never change").




    "If a topic that clearly interest noone needs to be closed to underline the "we don't want this here" message, is up to debate."

    -NudeRaider

    Jul 26 2016, 7:35 pm NudeRaider Post #11

    We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

    Quote from TiKels
    don't understand what you mean by parser.
    The part that goes through the structure of the excel file and extracts the data it needs.




    Jul 31 2016, 2:20 am Sacrieur Post #12

    Still Napping

    I just wrote a python script for work with file paths hard-coded in.

    It's as Roy said: the quality of the work is what suffers.



    None.

    Aug 1 2016, 8:56 am Heinermann Post #13

    SDE, BWAPI owner, hacker.

    TiKels, any software that would ever be used in a production environment would have adequate tests and documentation. Don't be surprised if your code is scrapped after a hand-off because it wasn't sufficiently tested or documented (good if code reads well, but still useless without the other expected components). Ideally you would also get your work code reviewed by at least one or two peers every time you wanted to push a change. "Production" doesn't mean public either, all in-house solutions would follow the same protocol. When I'm developing BWAPI I can move quickly and push whatever I want, but when I develop for Amazon, a day's work on a personal project could take a week in a professional environment, even though we use agile.




    Options
      Back to forum
    Please log in to reply to this topic or to report it.
    Members in this topic: None.
    [01:53 pm]
    Voyager7456 -- This is how you know SEN is active again - we're worth the trouble to spam
    [01:23 pm]
    Corbo -- ...I don't think *I* have the permission to do that xD
    [01:23 pm]
    Corbo -- he also seems to be able to edit his own posts
    [01:22 pm]
    Corbo -- makes you think if they're like evolving/learning or it was custom made to spam SEN
    [01:22 pm]
    Corbo -- even modifies his avatar and signature
    [01:22 pm]
    Corbo -- whole new level of bot
    [01:15 pm]
    Vrael -- yeah SEN only likes salty thigs
    [11:38 am]
    jjf28 -- SEN apparently hates citrus
    [11:38 am]
    jjf28 -- :aofst:
    Please log in to shout.


    Members Online: TiKels, Roy, Dem0n, Voyager7456, joseitol44