Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I had a piece of work thrown out due to a single minor spec change that turned out not to have been spec'ed correctly. If it had been done right at the start of the project then most of that work would have never have been needed in the first place.
What are some good tips/design principles that keep these things from happening?
Or to lessen the amount of re-working to code that is needed in order to implement feature requests or design changes mid implementation?
Modularize. Make small blocks of code that do their job well. However, thats only the beginning. Its usually a large combination of factors that contribute to code so bad it needs a complete rework. Everything from highly unstable requirements, poor design, lack of code ownership, the list goes on and on.
Adding on to what others have brought up: COMMUNICATION.
Communication between you and the customer, you and management, you and the other developers, you and your QA department, communication between everyone is key. Make sure management understands reasonable timeframes and make sure both you and the customer understand exactly what it is that your building.
Take the time to keep communication open with the customer that your building the product for. Make milestones and setup a time to display the project to the customer at each milestone. Even if the customer is completely disappointed with a milestone when you show it, you can scratch what you have and start over from the last milestone. This also requires that your work be built in blocks that work independent of one another as Csunwold stated.
Points...
Keep open communication
Be open and honest with progress of product
Be willing to change daily as to the needs of the customers business and specifications for the product change.
Software requirements change, and there's not much one can do about that except for more frequent interaction with clients.
One can, however, build code that is more robust in face of change. It won't save you from throwing out code that meets a requirement that nobody needs anymore, but it can reduce the impact of such changes.
For example, whenever this applies, use interfaces rather than classes (or the equivalent in your language), and avoid adding operations to the interface unless you are absolutely sure you need them. By building your programs that way you are less likely to rely on knowledge of a specific implementation, and you're less likely to implement things that you would not need.
Another advantage of this approach is that you can easily swap one implementation for another. For example, it sometimes pays off to write the dumbest (in efficiency) but the fastest to write and test implementation for your prototype, and only replace it with something smarter in the end when the prototype is the basis of the product and the performance actually matters. I find that this is a very effective way to avoid premature optimizations, and thus throwing away stuff.
modularity is the answer, as has been said. but it can be a hard answer to use in practice.
i suggest focussing on:
small libraries which do predefined things well
minimal dependencies between modules
writing interfaces first is a good way to achieve both of these (with interfaces used for the dependencies). writing tests next, against the interfaces, before the code is written, often highlights design choices which are un-modular.
i don't know whether your app is UI-intensive; that can make it more difficult to be modular. it's still usually worth the effort, but if not then assume that it will be thrown away before long and follow the iceberg principle, that 90% of the work is not tied to the UI and so easier to keep modular.
finally, i recommend "the pragmatic programmer" by andrew hunt and dave thomas as full of tips. my personal favourite is DRY -- "don't repeat yourself" -- any code which says the same thing twice smells.
iterate small
iterate often
test between iterations
get a simple working product out asap so the client can give input.
Basically assume stuff WILL get thrown out, so code appropriately, and don't get far enough into something that having it be thrown out costs a lot of time.
G'day,
Looking through the other answers here I notice that everyone is mentioning what to do for your next project.
One thing that seems to be missing though is having a washup to find out why the spec. was out of sync. with the actual requirements needed by the customer.
I'm just worried that if you don't do this, no matter what approach you are taking to implementing your next project, if you've still got that mismatch between actual requirements and the spec. for your next project then you'll once again be in the same situation.
It might be something as simple as bad communication or maybe customer requirement creep.
But at least if you know the cause and you can try and help minimise the chances of it happening again.
Not knocking what other answers are saying and there's some great stuff there, but please learn from what happened so that you're not condemned to repeat it.
HTH
cheers,
Sometimes a rewrite is the best solution!
If you are writing software for a camera, you could assume that the next version will also do video, or stereo video or 3d laser scanning and include all hooks for all this functionality, or you could write such a versatile extensible astronaut architecture that it could cope with the next camera including jet engines - but it will cost so much in money, resources and performance that you might have been better off not doing it.
A complete rewrite for new functionality in a new role isn't always a bad idea.
Like csunwold said, modularizing your code is very important. Write it so that if one piece falls prone to errors, it doesn't muck up the rest of the system. This way, you can debug a single buggy section while being able to safely rely on the rest.
Beyond this, documentation is key. If your code is neatly and clearly annotated, reworking it in the future will be infinitely easier for you or whoever happens to be debugging.
Using source control can be helpful too. If you find a piece of code doesn't work properly, there's always the opportunity to revert back to a past robust iteration.
Although it doesn't directly apply to your example, when writing code I try to keep an eye out for ways in which I can see the software evolving in the future.
Basically I try to anticipate where the software will go, but critically, I resist the temptation to implement any of the things I can imagine happening. All I am after is trying to make the APIs and interfaces support possible futures without implementing those features yet, in the hope that these 'possible scenarios' help me come up with a better and more future-proof interface.
Doesn't always work ofcourse.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My team is building a product that has a lot of components that rely on each other. For example, whenever we add a new type of data to the system, we also have to add logging code to track the changes that use that data type. Or, when we add a new UI screen, we have to make sure that its strings are externalized so they can be translated. These things slow down almost every task we do, and sometimes one of the the steps gets forgotten.
The traditional way to handle this problem is to add required checklists and documentation and things like that. How do Agile methodologies handle it?
The design you describe sounds like it might be a little too tightly-coupled. A renewed focus on enterprise patterns (such as Inversion of Control, programming to interfaces, etc) could help a lot.
If you are doing pair programming, you should be checking each other's work, making sure all of the i's are dotted and the t's are crossed.
If you are doing Test Driven Development, your tests should not be passing until all requirements for that particular portion of the development effort are satisfied.
If you are developing a large, complex system, you need experienced developers who understand the design and development process. You may also need a hands-on (read:coding) architect who can oversee the whole process.
Oh, and checklists (despite their traditional nature) are good too.
I'd suggest reading Alistair Cockburn's "”Agile Software Development: The Cooperative Game" - he takes quite an intelligent approach to Agile that's largely "do what gets the job done". That might help you work out how to get some kind of checklist / documentation into what you're doing without making everything horribly top-heavy.
Could some of your problems be solved by better tests? When you talked about not doing things that need to be done, my first thought was "why hasn't a test failed?" Maybe you need to look at tools for testing user interfaces? (edit: or even some small script on commit that greps code for whatever indicates the need for translation strings and checks against the files with the translations in?)
Also, can you change your design so that it's both less coupled and "forces" you to do the right thing. Perhaps making those data types implement a logging interface that the logger delegates to, or similar...?
Depending on your IDE there are various tools to help identify strings that need to be externalized, but if you are in a habit of just not putting in static strings this can be avoided.
If you need to add logging I would suggest AOP, as, at some point you will want to remove the logging code and you risk breaking the application.
But, a long-term, complex system is ideal for agile development, as, while you are developing, the needs of the client/customer may change, and you can adapt to it.
You need to ensure that the customer has feedback on a regular basis (ideally daily, and in a perfect system the customer has a rep sitting by for questions).
When I have many steps that must be done, esp for something like datatypes, I will resort to using a spreadsheet, so, you add a datatype, you add a row to the spreadsheet. Then you can track everything that needs to be done before that datatype is completely added to the application.
Have cross-component teams. That way when you add some functionality, the member(s) from the logging component will update their part and the translator(s) will update the strings.
I think it is important to understand that Agile methodology is only a process framework, not a process in itself. For example it says to follow test driven development and do pair programming but it does not say how to write the tests, or suggest a review checklist or suggest a coding guideline or say what documents to write. Those parts are entirely upto you or your organization to define and follow.
When planning a feature, you can add a engineering task called "review" and allot time for it. You could do the review task in whatever way works best for you and your organization. If pair programming doesn't work as well as a formal inspection for you, you should do formal inspections.
Do what needs to be done, but not more:
better definition of done (the definition of done is a kind of checklist to me),
better testing,
"just enough" documentation (Agile != no documentation),
etc.
Well, where I work we have QA that can catch some of the bugs if there are missing requirements or something slips through. I'm not saying the development team is intentionally putting in bugs, but as a codebase grows, it becomes harder and harder to remain nimble and thorough in checking everything.
Wikis can be useful for capturing methods used to try to get the clearest requirements. By clear I mean that the story card isn't likely to list all the requirements and that there may be discussions with an end-user or business analyst to get their understanding of what is desired. Part of our sign-offs involve getting an end-user to see the functionality and approve it before moving from the development environment.
Once every handful of sprints, we may have most of a sprint devoted to bug fixing/refactoring so that things can be cleaned up that would otherwise not get done as they aren't likely to be important. This can be cosmetic bugs or broken windows that while they have little business value initially can be useful in the long run.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Recently, we've come across an issue at work where if one person is working on some code by themselves, it seems to come out with the other team members looking at it and going "Huh? That's ugly, unmanageable, I need to rewrite that"
In fact, recently, I myself have had to re-factor something that was written the week before so that I'd be able to add in my (related) feature.
I know that Pair programming is the way to go for this, but we have an uneven team (3 members). As our team is being pushed pretty hard at the moment, we really don't have time for Peer Reviews (though we can do Pair Programming, as we're allowed to estimate that into our task estimates)
I'm just curious as to how people would suggest we overcome these issues with poor code being generated.
When you work alone, and produce code which your colleagues find ugly and unmanageable and needs to be rewritten, then do you:
(a) agree with them when you look at it a second time,
(b) disagree?
If (a), then the problem is that on your own, you aren't fully clarifying your code when you write it. Since pair programming is the only thing making you write decent code, I suppose I'd recommend that the "odd one out" should work on tasks which do not involve writing long tracts of bad code: bug-hunting; maybe writing test code, since that tends to be a bit less fiendish. Meanwhile, work on improving your skills at writing better code - perhaps do reviews of your own code from a few months ago, and make notes as to what was wrong with it.
If (b), then the problem you have is incompatible ways of expressing your ideas. The code may not be bad by your standards, but it's mutually incomprehensible, which in a corporate setting means it's bad code. Pair programming means what you write is a compromise that 2 out of 3 of you understand, but that's not really a solution. You need to come to some mutual agreements about what you find most difficult about each other's code, and stop doing that. And you all urgently need to start thinking of "code quality" in terms of "my 2 colleagues will like this code", not "I like this code".
Either way, you all need to work on writing code for the purpose of being read, rather than for the purpose of getting the immediate job done as quickly as you possibly can. Personally I have done this by trying to express things in the way that I think other people might express and understand them, rather than just what makes sense to me at the time. Eventually it becomes habitual. When I write code, I write it for a public audience just like I'm writing this post for a public audience. OK, so on my personal projects it's an audience of people who think just like me, whereas at work it's an audience that thinks like my colleagues. But the principle is to write code as if someone's reading it. You're explaining yourself to them, not the compiler.
Not that my code is the best in the world, but I do think I benefited in that my first job was in a company with 30-odd programmers, so I got to see a wide range of ways of thinking about things. Also a few examples of "what not to do", where one programmer had done something that nobody else could easily understand, and therefore could definitively be said to be bad. With only 3 people, it's not clear whether a 2 v. 1 difference of opinion means that the 1 is a freak or a reasonable minority. When I did something and 4 or 5 people could glance at it and immediately say "eeew, don't do that", then I started to really believe it was just a dumb idea in the first place.
I'd also recommend that if you aren't allowed to budget for code review, lie and cheat. If you're heavily re-writing someone else's code, you're effectively taking the time to review it anyway, you just aren't providing the feedback which is the worthwhile part of code review. So sneak the review in under the radar - write a function or three, then ask a colleague to look at it and give you instant feedback on whether it makes sense to them. It helps to have a conversation as soon as you've done it, with the code on the monitor, but do try not to interrupt people when they have "flow", or to get into lengthy arguments. It's not pair programming, and it's not formal code review, but it might help you figure out what it is you're doing on your own that's so bad.
I'm surprised that you don't have time to do peer reviews but you have time to do paired programming. Is the latter not a much bigger sink of time?
We also have three developers only at our company and, surprise, surprise, we're being pushed hard at the moment. I'm pretty sure my boss would laugh at me if I suggested paired programming because that would be viewed as doubling the number of man hours for a task even though in practice that's not the result it should produce. Our peer reviews are never more than an hour and that is an extreme case. On average I would say they are probably about 10 minutes and, per developer, only happen once or twice in a day.
IMO you should give peer reviews a try. You often find that the offending people (i.e. the people writing the lower quality code) eventually realise that they need to make more of an effort and the quality improves over time.
If you have three developers and each of you think the others code is not good, you urgently need peer reviews.
So:
you are being pushed pretty hard
your code is of poor quality
Do you think the two could possibly be related? The answer is to fix the schedule.
Pair up all three at once.
Set up some coding standards.
Use a dunce cap for build breaking developers.
Perform daily stand up meetings to communicate progress.
Also try peer reviews twice a week, like Tuesday and Friday.
Pair Programming doesn't have to be all day every day to be effective. I have seen good results from even an hour or two working together each week. One way to go would be to pair A & B for a while, then A & C, then A & B... with a lot of individual time in between.
It also depends a lot on the personalities and chemistry of the team members. Two of the three might work exceptionally well together and you'd want to benefit from that.
You should still pair. Set up sessions say 1 day per week and rotate the pairs. This should keep your manager happy and increase the quality of the code, improve communication. If you keep metrics on how many faults happen in paired vs solitary coding you should start to see the benfit and display this to your manager,
eg This took x man hours but saved on average y in defect fixing. Additionally the clode is cleaner and will take less time to alter then next time we touch it.
From there you will have hard statistics and you can start to code more.
Basically your story seems to be the same as mine.
No time to do things.
Mistakes happen.
Rush to fix it (taking more time)
Go to 1
You need to stop the rot.
Code reviews
Enable Stylecop that will force you to write readable, standardised and manageable code
We use code reviews. Additionally there are some single task: changing a diagram, installing some stuff...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm dealing with an issue with my current employer that has seriously made me consider seeking employment elsewhere. They are under the impression that 100% of custom development should be eliminated and replaced with COTS products, such as SharePoint. While I realize that this is not a realistic expectation, I've found it impossible to argue my points with the people in management that share these views. Their argument usually involves something along the lines of a feature already existing in SharePoint that covers feature X, therefore there is less risk involved and testing doesn't have to be done against it.
Case in point, we have a situation where a SharePoint list is completely incapable of meeting customer expectations and requirements. Saving this data in a SQL database, however, would easily satisfy the requirements. Any time our development team suggests going outside of the boundaries of SharePoint, however, management goes up in flames about how every line of code adds to the complexity of the project and increases risk. While this is certainly true in some situations, it's not always the case. Their argument, however, is that since SharePoint provides a mechanism for storing data, that we should use it 100% of the time. Regardless of if it meets customer requirements, or not.
I've gotten to the point that I hate coming to work because I'm constantly forced into doing things that I know (with 100% certainty) are not right and that could be made right by doing custom development. It's simply what seems to be an impossible argument where I work, however.
Have any of you experienced a similar situation? If so, what have you done to work through these challenges?
If you don't share the vision of the company and if you can't enlighten them then sure, it is a good time to start looking.
Have you pointed out that there is risk in forcing a "solution" on a client that does not help them or is missing functionality or is unusable?
Perhaps come up with plans to address and mitigate their perceived risks.
You document your concerns and let those above you know them, and then you do as they ask. If it doesn't work, you have documentation that you brought the concerns up. But try to make it work their way, so it doesn't look like you're trying to undermine their plans. They're taking the greater risk, and thus they get the greater responsibility. Try your best to make it work their way, and quit worrying about it.
This may sound bad and may not be the answer you want. There is a little known division in my office called "The Skunk Works." People, on their own accord (usually during lunch breaks or compile time) decide to write little programs that help the company. The fun things about this is the result doesn't "cost" the company anything.
The conversation usually goes like this:
"We need to buy this software" -Boss
"But, we have had that thing for months. John, wrote that back in the day" -Programmer
"?" -Boss
A lot of times the developers see a decision as being bad and just create a parallel process that happens automatically. Then, when the stuff hits the fan and the customers are frustrated, the alternate solution is ALREADY in place.
I have an example of an auto release machine. Developers used to create these custom reports. As our customers increased, the developer's workload increased. The problem was "In order for the customer to get the custom report developer had to be involved." So, while the company was looking into hiring someone to do reports full time or to find ways to have the customers do them, I wrote an auto release machine that looks for report changes and releases them directly to the customer. I also wrote a utility that allows anybody to make changes to the reports that was easier to use than what the developer has. When the Boss made the announcement of trying to find a solution, I told him that it was already in place and that even he could make changes to reports and get them released. Now, everybody can change reports, usually it is management and customer support who make these changes. The fun side is that developers arn't involved anymore.
Just do it. If you're going to quit anyways, might as well try.
Does someone in management own stock in SharePoint? Was the system developed by the CEO's younger brother?
If they are that resilient to change, you should find out the real reason before trying to argue with them. They may claim that there is added complexity, difficulty testing, etc, but if you can counter every argument with one that shows their position, with all due respect, to be misinformed, and they still won't discuss, then you may be arguing the wrong point.
If they are locked into the technology because of a non-technical reason, such as someone once read that SharePoint is the ultimate in any technical situation (and, of course, had no clue what the article was talking about other than SharePoint = good) then you shouldn't bother trying to argue and save your energy. For the job hunt.
Prove it to them. When the requirements ask for a list that can handle 100,000 items with a multi-column sort - write a script that adds 100,000 test items into a sharepoint list and let them try it, preferrably with the "customer" requesting the list watching. :-)
I would definitely get my resume out and into the open if I were you. Not only is the experience that you are currently having frustrating, it can really hurt your career development over the long haul. Just think about it. While you are languishing with your current employer in your current position, other developers are adopting new technologies and expanding their experience.
There is such a thing as ideological differences between developers and what a company's idea of a role for a developer is. If open discussion and candor get you nowhere, you will not be faulted for a lack of effort. Loyalty to a company is a good thing, but the relationship needs to be a two-way street.
Sadly, the will eventually probably come to realize that they are wrong in their assumptions - but you can not wait for that day to come. Sometimes it never comes. In particular (and don't get me wrong, I love SharePoint when it is used for what it is intended for), SharePoint is become the next Access, in that people who read management magazines see enough of it thrown around to call it the messiah.
I find that there is typically no way of 'winning' these debates through talk alone. Many managers form an opinion of a product or solution through reading management oriented articles. See if you can find some counter-articles.
If you can cite examples of things which SharePoint is incapable of doing, and show examples of how you can cost effectively solve these problems through custom development then you are well on your way.
The mistake is to try and make this a conversation about technology, it's not, its about efficiency, cost effectiveness and maintainability - those are the mantras and metrics which will sway non-technical managers into considering alternatives.
If you can put together a proof of concept for some of these issues so much the better, eye candy really helps to sell outside of technical teams.
Finally, good luck :)
I am doing the same thing at my current job, there is no easy way to deal with this kind of situation. All I have been able to do is swallow my arguments, cause they have gotten me no where, and do as required by my management. This off course will go against your basic programmer nature of using the best solution for the task at hand, and maybe getting to build something cool in the process, but since they are the boss it is really your only solution. You could try to site cases, with evidence, where it makes more sense to use custom solutions. But if you boss is anything like mine, it won't get very far before the screaming match begins. The only other solution is dusting off that resume and finding a new job.
I have faced the same kind of challenges right from day one. Management have a natural reluctance to add custom code to the solution. However in most cases it has been posible to explain than the right solution for the customer would include some custom code.
Remember, if you argue that you can include the custom code in the common codebase, then the boss might approve the idea.
I really feel your pain.
If it was me I would use my spare time to collect information that proves my point and document it in a easy to understand way.
If they only understand money, talk money, if they only understand fear (doing "this" because they are scared of "that"), use the fear, finding scary thing for them in "their" solution.
Document every new implementation, the time, money and problem that arises. And document what your solution would be instead.
They probably doesn't see the problem in their solution, because they focus on not having problems in "your" solution.
I have worked in a place where management were not constructive in their approach, not quite as bad as you describe, but bad enough.
There are a couple of options. One is to go ahead and do what needs to be done for the client with the best "value for money" option you can. You will probably have to get the developers together as a team to make this "civil disobedience" work.
A more forceful approach that will really make the shit hit the fan is to go to the client (don't do this if it is an external client or if you wish to keep your job) and lay out what is going to happen to this project if X and Y. This is pretty much telling tales out of school and is going to be bad, but entertaining.
A slightly better way is to go up the chain and get a sponsor who can make shit happen for you. Essentially go behind your boss(es) back. This may work, but it is going to have predictable results for your relationship with your management.
Last and hardest is to identify the person who holds the view that any custom code is bad and engage them in conversation to find out where they got the belief and counter that with examples. Emphasis on conversation as you will have to listen to and understand their underlying concerns (which won't be about custom code per se) and only address them after you gain that persons trust.
I cannot tell you which way of doing things is going to work best because it depends so much on the individuals involved. All I do know is that you cannot change people and in my experience the best way to solve the problem so far has been to leave and work with people who are not so...
how about not calling it custom code. If instead you call it 'anticipated SharePoint user extensions' or something it may soften the misconception surrounding a specific term.
also, as has been said, there may be other hidden from you reasons that management is pushing this agenda. It is probably best to not second guess these too quickly, as many would be valid.
Finally, there are alot of places that need development. it doesnt hurt to look for a better match.
good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have had a few development managers who don't seem to understand or appreciate the difficulties of software design and implementation.
Such managers believe that processes and methodologies completely solve the problem and I have a tough time explaining to them that it is not so and that you cannot read a book on the latest process fad and hope to get results by applying them as is.
The latest frustration I have is to convince my manager to
(a) Give me requirements not piece-meal but a larger set as far as possible.
(b) Give my team lead time to think about how to design, thrash out a few alternatives, work out an implementation sketch, to plan out the tasks etc.
The frustrations are compounded because of Agile methodology and the interpretation of it that says not to do up-front design (as against BIG up-front design in Waterfall), product owner can change requirements at any time and so son.
So far I haven't had much success and have to put up with the resulting frustrations.
Can you give me some arguments that can convince such managers?
EDIT-1:
Retrospectives are done, though not always at the end of every sprint, and the problems are brought up. But as I mentioned, my manager doesn't appreciate the need for design lead time and the frustrations with piece-meal requirements.
EDIT-2
I don't have a problem with changing requirements. I understand that it will be so, but imagine this: You want a small feature to begin with and then you keep adding more around it. After a few iterations, the design cannot handle it anymore and a redesign (not refactoring) is required. This could have been solved better with an upfront design in the first place, had the related features been investigated together. Its not BDUF, its the natural way of doing it (what I call software engineering common sense).
My manager doesn't understand why I ask for time to redesign (a few times I just call it refactoring so that it fits the Agile way of doing it, but it really is redesign) and not developing and demoing new features.
Every time requirements are changed (or increased) so should
the estimate to complete and,
the assessment of risk
Start giving updated estimates (even if you have to guess) and lists of risks every time you get an updated or new requirement. This will help your manager make the connection.
Try to do this in a spirit of helpfulness--"for planning purposes"--so that you aren't perceived as obstructive or lacking "can-do attitude." Remember that estimates can (in theory) come down, and risks can be reduced.
Business requirements are going to change no matter where you work. It's not your fault, it's not your boss's fault, it's not anybody's fault. The entire point of taking the requirements on piecemeal is to encourage you to think about the problem at hand, not some other problem that you might or might not need to solve. It's quite liberating once you get into the rhythm of it.
Think of upfront design as premature optimization. You may not need it, and even if you know you need it, you'll know more about your design two weeks from now than you know about it today. It'll help you solve your engineering problem with the best possible knowledge about the state of your code.
That having been said, edg is absolutely right. When you add more requirements, the estimate changes. This isn't the fault of the developers or anyone else; more work means more work no matter how you square it. If your boss doesn't realize that adding requirements will result in a larger estimate for the project you need to explain to him that Agile isn't a magic bullet that allows you to add more features without paying anything for them.
Agile Simple Design doesn't mean don't do ANY design/architecture up front.
It means do the minimal design up front, so that you will not pay a horrible price for reasonable change requests.
Scott Ambler talks about Change Cases - http://www.agilemodeling.com/artifacts/changeCase.htm
James Coplien talks about Agile Architecture - http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
http://blog.jaoo.dk/2009/03/04/handling-architecture-in-the-agile-world/
The art/craft in all of this is in how to slice the architecture in a way that allows:
relatively fast convergence on overall architecture/infrastructure - on the order of days per months of estimated development time.
developing "just enough" architecture/infrastructure per each feature/requirement
doing the right balance of preparations for the future compared to focus on the features of today.
Its important that your Product Owner is aware of all of this balancing act as well, and you work collaboratively. He should understand that if you disregard all thinking for the future, each change will be very costly. There is a price to be paid for flexibility.
Its btw very similar to investment in QA and test automation. You pay something now, that will pay off only after X times you test the code. if the code never changes it was a waste of effort. but everyone knows that most code changes...
Buy your manager this book. That's what I did, and it worked great :)
First of all this issue seems quite sensitive, so all I wrote below is just my personal opinion, and not necessarily a wise thing to do.
In my opinion you cannot make software if you do not know what problem it should solve. If requirements come in small parts that are too small to oversee the problem, then I would just fire questions about the parts that seem to be missing. Like: "okay so the software should do X, but does that also mean Y or otherwise maybe Z? Because if it is Y then ... but if it is Z then ..." Of course if the manager is in the middle of extracting the requirements then he cannot answer, but at least he knows that there are still open issues that influence development.
About no lead time for design: design and development are an iterative process that could go hand in hand. It is just how you name the thing. If the manager wants to see some code at the end of the day, okay then I would just use the first half of the day to design and the second half of the day to make some code based on that design. If the manager does not want to see the design, fine with me then I'll just show the code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
A couple of years ago the media was rife with all sorts of articles on
how the idea of code reuse was a simple way to improve productivity
and code quality.
From the blogs and sites I check on a regular basis it seems as though
the idea of "code reuse" has gone out of fashion. Perhaps the 'code
reuse' advocates have all joined the SOA crowd instead? :-)
Interestingly enough, when you search for 'code reuse' in Google the
second result is titled:
"Internal Code Reuse Considered Dangerous"!
To me the idea of code reuse is just common sense, after all look at
the success of the apache commons project!
What I want to know is:
Do you or your company try and reuse code?
If so how and at what level, i.e. low level api, components or
shared business logic? How do you or your company reuse code?
Does it work?
Discuss?
I am fully aware that there are many open source libs available and that anyone who has used .NET or the Java has reused code in some form. That is common sense!
I was referring more to code reuse within an organizations rather than across a community via a shared lib etc.
I originally asked;
Do you or your company try and reuse code?
If so how and at what level, i.e. low level api, components or shared business logic? How do you or your company reuse code?
From where I sit I see very few example of companies trying to reuse code internally?
If you have a piece of code which could potentially be shared across a medium size organization how would you go about informing other members of the company that this lib/api/etc existed and could be of benefit?
The title of the article you are referring to is misleading, and is actually a very good read. Code reuse is very beneficial, but there are downsides with everything. Basically, if I remember correctly, the gist of the article is that you are sealing the code in a black box and not revisiting it, so as the original developers leave you lose the knowledge. While I see the point, I don't necessarily agree with it - at least not to a "sky is falling" regard.
We actually group code reuse into more than just reusable classes, we look at the entire enterprise. Things that are more like framework enhancement or address cross-cutting concerns are put into a development framework that all of our applications use (think things like pre- and post-validation, logging, etc.). We also have business logic that is applicable to more than one application, so those sort of things get moved to a BAL core that is accessible anywhere.
I think that the important thing is not to promote things for reuse if they are not going to really be reused. They should be well documented, so that new developers can have a resource to help them come up to speed, as well. Chances are, if the knowledge isn't shared, the code will eventually be reinvented somewhere else and will lead to duplication if you are not rigorous in documentation and knowledge sharing.
We reuse code - in fact, our developers specifically write code that can be reused in other projects. This has paid off quite nicely - we're able to start new projects quickly, and we iteratively harden our core libraries.
But one can't just write code and expect it to be re-used; code reuse requires communication among team members and other users so people know what code is available, and how to use it.
The following things are needed for code reuse to work effectively:
The code or library itself
Demand for the code across multiple projects or efforts
Communication of the code's features/capabilities
Instructions on how to use the code
A commitment to maintaining and improving the code over time
Code reuse is essential. I find that it also forces me to generalize as much as possible, also making code more adaptable to varying situations. Ideally, almost every lower level library you write should be able to adapt to a new set of requirements for a different application.
I think code reuse is being done through open source projects for the most part. Anything that can be reused or extended is being done via libraries. Java has an amazing number of open source libraries available for doing a large number of things. Compare that to C++, and how early on everything would have to be implemented from scratch using MFC or the Win32 API.
We reuse code.
On a small scale we try to avoid code duplication as much as posible. And we have a complete library with a lot of frequently used code.
Normally code is developed for one application. And if it is generic enough, it is promoted to the library. This works excelent.
The idea of code reuse is no longer a novel idea...hence the apparent lack of interest. But it is still very much a good idea. The entire .NET framework and the Java API are good examples of code reuse in action.
We have grown accustomed to developing OO libraries of code for our projects and reusing them in other projects. Its a part of the natural life cycle of an idea. It is hotly debated for a while and then everyone accepts and there is no reason for further discussion.
Of course we reuse code.
There are a near infinite amount of packages, libraries and shared objects available for all languages, with whole communities of developers behing them supporting and updating.
I think the lack of "media attention" is due to the fact that everyone is doing it, so it's no longer worth writing about. I don't hear as many people raising awareness of Object-Oriented Programming and Unit Testing as I used to either. Everyone is already aware of these concepts (whether they use them or not).
Level of media attention to an issue has little to do with its importance, whether we're talking software development or politics! It's important to avoid wasting development effort by reinventing (or re-maintaining!) the wheel, but this is so well-known by now that an editor probably isn't going to get excited by another article on the subject.
Rather than looking at the number of current articles and blog posts as a measure of importance (or urgency) look at the concepts and buzz-phrases that have become classics or entered the jargon (another form of reuse!) For example, Google for uses of the DRY acronym for good discussion on the many forms of redundancy that can be eliminated in software and development processes.
There's also a role for mature judgment regarding costs of reuse vs. where the benefits are achieved. Some writers advocate waiting to worry about reuse until a second or third use actually emerges, rather than spending effort to generalize bit of code the first time it is written.
My personal view, based on the practise in my company:
Do you or your company try and reuse code?
Obviously, if we have another piece of code that already fits our needs we will reuse it. We don't go out of our way to use square pegs in round holes though.
If so how and at what level, i.e. low level api, components or shared business logic? How do you or your company reuse code?
At every level. It is written into our coding standards that developers should always assume their code will be reused - even if in reality that is highly unlikely. See below
If your OO model is good, your API probably reflects your business domain, so reusable classes probably equates to reusable business logic without additional effort.
For actual reuse, one key point is knowing what code is already available. We resolve this by having everything documented in a central location. We just need a little discipline to ensure that the documentation is up-to-date and searchable in a meaningful way.
Does it work?
Yes, but not because of the potential or actual reuse! In reality, beyond a few core libraries and UI components, there isn't a large amount of reuse.
In my personal opinion, the real value is in making the code reusable. In doing so, aside from a hopefully cleaner API, the code will (a) be documented sufficiently for another developer to use it without trawling the source code, and (b) it will also be replaceable. These points are a great benefit to on-going software maintenance.
Do you or your company try and reuse code? If so how and at what
level, i.e. low level api, components or shared business logic? How do
you or your company reuse code?
I used to work in a codebase with uber code reuse, but it was difficult to maintain because the reused code was unstable. It was prone to design changes and deprecation in ways that cascaded to everything using it. Before that I worked in a codebase with no code reuse where the seniors actually encouraged copying and pasting as a way to reuse even application-specific code, so I got to see the two extremities and I have to say that one isn't necessarily much better than the other when taken to the extremes.
And I used to be an uber bottom-up kind of programmer. You ask me to build something specific and I end up building generalized tools. Then using those tools, I build more complex generalized tools, then start building DIP abstractions to express the design requirements for the lower-level tools, then I build even more complex tools and repeat, and at some point I start writing code that actually does what you want me to do. And as counter-productive as that sounded, I was pretty fast at it and could ship complex products in ways that really surprised people.
Problem was the maintenance over the months, years! After I built layers and layers of these generalized libraries and reused the hell out of them, each one wanted to serve a much greater purpose than what you asked me to do. Each layer wanted to solve the world's hunger needs. So each one was very ambitious: a math library that wants to be amazing and solve the world's hunger needs. Then something built on top of the math library like a geometry library that wants to be amazing and solve the world's hunger needs. You know something's wrong when you're trying to ship a product but your mind is mulling over how well your uber-generalized geometry library works for rendering and modeling when you're supposed to be working on animation because the animation code you're working on needs a few new geometry functions.
Balancing Everyone's Needs
I found in designing these uber-generalized libraries that I had to become obsessed with the needs of every single team member, and I had to learn how raytracing worked, how fluids dynamics worked, how the mesh engine worked, how inverse kinematics worked, how character animation worked, etc. etc. etc. I had to learn how to do pretty much everyone's job on the team because I was balancing all of their specific needs in the design of these uber generalized libraries I left behind while walking a tightrope balancing act of design compromises from all the code reuse (trying to make things better for Bob working on raytracing who is using one of the libraries but without hurting John too much who is working on physics who is also using it but without complicating the design of the library too much to make them both happy).
It got to a point where I was trying to parametrize bounding boxes with policy classes so that they could be stored either as center and half-size as one person wanted or min/max extents as someone else wanted, and the implementation was getting convoluted really fast trying to frantically keep up with everyone's needs.
Design By Committee
And because each layer was trying to serve such a wide range of needs (much wider than we actually needed), they found many reasons to require design changes, sometimes by committee-requested designs (which are usually kind of gross). And then those design changes would cascade upwards and affect all the higher-level code using it, and maintenance of such code started to become a real PITA.
I think you can potentially share more code in a like-minded team. Ours wasn't like-minded at all. These are not real names but I'd have Bill here who is a high-level GUI programmer and scripter who creates nice user-end designs but questionable code with lots of hacks, but it tends to be okay for that type of code. I got Bob here who is an old timer who has been programming since the punch card era who likes to write 10,000 line functions with gotos in them and still doesn't get the point of object-oriented programming. I got Joe here who is like a mathematical wizard but writes code no one else can understand and always make suggestions which are mathematically aligned but not necessarily so efficient from a computational standpoint. Then I got Mike here who is in outer space who wants us to port the software to iPhones and thinks we should all follow Apple's conventions and engineering standards.
Trying to satisfy everyone's needs here while coming up with a decent design was, probably in retrospect, impossible. And in everyone trying to share each other's code, I think we became counter-productive. Each person was competent in an area but trying to come up with designs and standards which everyone is happy with just lead to all kinds of instability and slowed everyone down.
Trade-Offs
So these days I've found the balance is to avoid code reuse for the lowest-level things. I use a top-down approach from the mid-level, perhaps (something not too far divorced from what you asked me to do), and build some independent library there which I can still do in a short amount of time, but the library doesn't intend to produce mini-libs that try to solve the world's hunger needs. Usually such libraries are a little more narrow in purpose than the lower-level ones (ex: a physics library as opposed to a generalized geometry-intersection library).
YMMV, but if there's anything I've learned over the years in the hardest ways possible, it's that there might be a balancing act and a point where we might want to deliberately avoid code reuse in a team setting at some granular level, abandoning some generality for the lowest-level code in favor of decoupling, having malleable code we can better shape to serve more specific rather than generalized needs, and so forth -- maybe even just letting everyone have a little more freedom to do things their own way. But of course all of this is with the aim of still producing a very reusable, generalized library, but the difference is that the library might not decompose into the teeniest generalized libraries, because I found that crossing a certain threshold and trying to make too many teeny, generalized libraries starts to actually become an extremely counter-productive endeavor in the long term -- not in the short term, but in the long run and broad scheme of things.
If you have a piece of code which could potentially be shared across a
medium size organization how would you go about informing other
members of the company that this lib/api/etc existed and could be of
benefit?
I actually am more reluctant these days and find it more forgivable if colleagues do some redundant work because I would want to make sure that code does something fairly useful and non-trivial and is also really well-tested and designed before I try to share it with people and accumulate a bunch of dependencies to it. The design should have very, very few reasons to require any changes from that point onwards if I share it with the rest of the team.
Otherwise it could cause more grief than it actually saves.
I used to be so intolerant of redundancy (in code or efforts) because it appeared to translate to a product that was very buggy and explosive in memory use. But I zoomed in too much on redundancy as the key problem, when really the real problem was poor quality, hastily-written code, and a lack of solid testing. Well-tested, reliable, efficient code wouldn't suffer that problem to nearly as great of a degree even if some people duplicate, say, some math functions here and there.
One of the common sense things to look at and remember that I didn't at the time is how we don't mind some redundancy when we use a very solid third party library. Chances are that you guys use a third party library or two that has some redundant work with what your team is doing. But we don't mind in those cases because the third party library is great and well-tested. I recommend applying that same mindset to your own internal code. The goal should be to create something awesome and well-tested, not to fuss over a little bit of redundancy here and there as I mistakenly did long ago.
So these days I've shifted my intolerance towards a lack of testing instead. Instead of getting upset over redundant efforts, I find it much more productive to get upset over other people's lack of unit and integration testing! :-D
While I think code reuse is valuable, I can see where this sentiment is rooted. I've worked on a lot of projects where much extra care was taken to create re-usable code that was then never reused. Of course reuse is much preferable to duplicate code, but I have seen a lot of very extenisve object models created with the goal of using the objects across the enterprise in multiple projects (kind of the way the same service in SOA can be used in different apps) but have never seen the objects actually used more than once. Maybe I just haven't been part of organizations taking good advantage of the principle of reuse.
The two software projects I've worked on have both been long term development. One is about 10 years old, the other has been around for over 30 years, rewritten in a couple versions of Fortran along the way. Both make extensive reuse of code, but both rely very little on external tools or code libraries. DRY is a big mantra on the newer project, which is in C++ and lends itself more easily to doing that in practice.
Maybe the better question is when do we NOT reuse code these days? We are either in a state on building using someone elses observed "best practices" or prediscovered "design patterns" or just actually building on legacy code, libraries, or copying.
It seems the degree to which code A is reused to make code B is often based around how much the ideas in code A taken to code B are abstracted into design patterns/idioms/books/fleeting thoughts/actual code/libraries. The hard part is in applying all those good ideas to your actual code.
Non-technical types get overzealous about the reuse thing. They don't understand why everything can't be copy-pasted. They don't understand why the greemelfarm needs a special adapter to communicate the same information that it used to to the old system to the new system, and that, unfortunately we can't change either due to a bazillion other reasons.
I think techies have been reusing from day 1 in the same way musicians have been reusing from day 1. Its an ongoing organic evolution and sythesis that will keep ongoing.
Code reuse is an extremely important issue - where code is not reused, projects take longer and are harder for new team members to get into.
However, writing reusable code takes longer.
Personally, I try to write all my code in a reusable way, this takes longer, but it results in the fact that most of my code has become official infrastructures in my organization and that new projects based on these infrastructures take significantly less time.
The danger in reusing code, is if the reused code is not written as an infrastructure - in a general and encapsulated manner with as few as possible assumptions and as much as possible documentation and unit testing, that the code can end up doing unexpected things.
Also, if bugs are found and fixed, or features added, these changes are rarely returned to the source code, resulting in different versions of the reused code, that no one knows of or understands.
The solution is:
1. To design and write the code with not only one project in mind, but to think of future requirements and try to make the design flexible enough to cover them with minimal code change.
2. To enclose the code within libraries that are to be used as-is and not modified within using projects.
3. To allow users to view and modify the code of of the library withing its solution (not within the using project's solution).
4. To design future projects to be based on the existing infrastructures, making changes to the infrastructures as necessary.
5. To charge maintaining the infrastructure to all projects, thus keeping the infrastructure funded.
Maven has solved code reuse. I'm completely serious.