131 reputation
8
bio website thinkboard.wordpress.com
location Frankfort, KY
age 47
visits member for 2 years, 7 months
seen Jul 8 at 17:50

I have worked as a software developer designing and writing client/server applications, mobile applications, and asp.net web applications. In May 2010 completed a graduate degree in Computer Science at Kentucky State University. Only two apps in the Apple App Store.


Jan
11
awarded  Peer Pressure
Jan
11
awarded  Commentator
Jan
11
comment What are the causes that lead to an overbloated software?
Lean development can be summarized by seven principles: 1 Eliminate waste 2 Amplify learning 3 Decide as late as possible 4 Deliver as fast as possible 5 Empower the team 6 Build integrity in 7 See the whole en.wikipedia.org/wiki/Lean_software_development
Jan
11
comment What are the causes that lead to an overbloated software?
But we also want to avoid this: "Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory/diskspace or processing power, or have higher hardware requirements than the previous version whilst making only dubious user-perceptible improvements." Size for the sake of size is not good either. Making a big program smaller does not necessarily make it better or more efficient. Again the important goal should be program efficiency irrespective of program size. en.wikipedia.org/wiki/Software_bloat
Jan
11
comment What are the causes that lead to an overbloated software?
Talking perceptibility, benefits and improvements? "If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible." Obviously, we want to avoid that, specially when there's no critical or important necessity.
Jan
11
comment What are the causes that lead to an overbloated software?
It is one thing "if programmers don't have to worry about how large their code is" when writing only the necessary and right code, and a very different thing having programmers carelessly write and add code which will unnecessarily increase the size of a program just for the sake of shipping sooner. But code size is NOT really the problem; the problem is that most if not all bloated programs are inefficient, slow, buggy, unreliable, frequently crash, cause a lot of inconveniences and frustrations to users, or cause fatalities. Bloatware is bad. Want to ship sooner? Write lean programs.
Jun
6
comment What to do when a company request permission to use open source code without attribution?
@tdammers You are not understanding the OP concern. I was showing that because of the MIT license under which he released his software, the company could not use it without attribution.
Jun
6
comment What to do when a company request permission to use open source code without attribution?
MIT license in Wikipedia en.wikipedia.org/wiki/MIT_License
Jun
6
answered What to do when a company request permission to use open source code without attribution?
Jun
6
awarded  Scholar
Jun
6
accepted What can be used in lieu of use cases to gather requirements?
Apr
24
comment How do tight timelines and scheduling pressure affect TCO and delivery time?
Steve McConnell enumarates "Overly optimistic schedules" as one of the classic software development practice mistakes, and a major source of project problems; this would be the cause of scheduling overruns in the first place. stevemcconnell.com/rdenum.htm
Mar
18
comment What can be used in lieu of use cases to gather requirements?
I was trying to find a substitution for the 'use case' part, not for the whole user requirements document. The reference in John Niedzwiecki's answer to 'user stories' seems pretty good and it could face less resistance than 'use cases'.
Mar
18
comment What can be used in lieu of use cases to gather requirements?
We create what we call User Requirements Documents (URDs) with the typical long narrative; we separate out requirements into sections, including business need, scope, time frame, some design specifications as well as screen shots where appropriate; never included 'use cases'. Our URDs might not be correct technically speaking but, have been good and have worked out fine in many instances; and we are going to create another URD again. However, it was pretty obvious that including 'use cases' this time would be very helpful, only to face unexpected answer the BA not liking use cases.
Mar
15
comment What can be used in lieu of use cases to gather requirements?
Good questions which, I did not ask but will ask next time we meet.
Mar
15
awarded  Student
Mar
15
asked What can be used in lieu of use cases to gather requirements?
Oct
8
awarded  Teacher
Sep
16
comment How can I quantify the amount of technical debt that exists in a project?
@ErikDietrich I would suggest to put that "kind of number" to indicate cost in the following manner: because our code base is 'this bad' it is taking 'this long' to implement 'this change', consecuently our 'time to market' (or time to delivery) is 'this'. 'this bad' would be your code metric, whichever is best for your particular needs, 'this long' would be, and this is my suggestion, your technical debt cost because you could put numbers on it as time and money; if implementation effort takes 'this long' and dev rate is $/hour, you could find out how long and how much the changes cost.
Sep
1
awarded  Supporter